As the topic suggests ... vad ca au fost foarte putine jocuri facute cu el si totusi oamenii in continuare il dezvolta si updateaza ...

Daca esti in stare sa-l pornesti

E mai bun decat Irrlicht dupa parerea mea.

Eu unul am inceput sa-l folosesc de curand si mi se pare foarte bun. Nu comentez structura lui sau modul de a face diferite chestii insa sunt multumit de viteza lui si de features.

Comunitatea e mare si dezvolta o gramada de lucruri interesante:

Caelum
Hydrax
Planet rendering engine
Paged Geometry

si multe altele.

Jocuri cu el nu stiu daca au iesit foarte multe, dar cu siguranta astea sunt printre cele mai interesante:

KartSim
ZeroGear
Aftershock
MOTORM4X

Si btw, nu e greu de pornit

Eu il folosesc la proiectul al care lucrez acum, insa mai am cateva probleme cu pipeline-ul din MAX/Blender in OGRE.

Eu zic ca merita sa-l incerci. Mai bun decat Irrlicht sigur e. E si mai rapid, doar ca e ceva mai complicat.

Eu zic sa-l intrebi pe raicuandi, pentru ca el e "long time user" de ogre si l-am vazut atat ridicandu-l in slavi cat si injurandu-l, deci iti poate spune ce i-a placut si ce nu.

De pornit nu e problema, l-am pornit si am si facut un DEMO cu el. Insa asta am facut cam in 2-3 ore pana m-am prins care e spielul cu el. Faza e ca acelasi demo il faceam in DarkBasic muuult mai rapid.

Ca in orice, sunt chestii si pro si contra.

Ogre e foarte usor de "pornit". Daca te multumesti cu setari implicite si cu un dialog cu sigla Ogre care te intreaba ce rezolutia samd., initializezi Ogre in 2 linii. Cand vrei sa treci sa initializezi totul de mana, e tot destul de usor, vre-o 50 de linii sau asa ceva. Singura faza e sa stii ordinea in care trebuie sa faci lucrurile. Un pic de research, nici io nu le stiu pe de rost. (de ex, trebuie sa setezi umbrele inainte sa incarci un mesh, sa incarci pluginul de render system inainte sa creezi o fereastra samd.)

Ogre ca idee e destul de misto, e foarte folositor, si ce face face destul de bine. Insa e prea "general purpose", e ca si cum ai folosi liste pt toate structurile de date din programul tau: merge frumos, dar pana la urma te saturi, daca intelegi ce vreau sa spun.

Cand vrei sa faci ceva mai concret, si complex, atunci Ogre, si probabil orice alt engine din asta "general purpose", o sa te cam enerveze. In cele din urma o sa ai un layer un pic ambiguu, care nu stii daca separa restul jocului de Ogre, sau Ogre de restul jocului. Din nou, se poate face un joc cu Ogre (dupa cum ai vazut), si e misto ca se ocupa de multe chestii plicticoase, insa nu te astepta sa poti ceva de calitate AAA cu Ogre. Decat sa devii "maestru Ogre", mai bine controlezi totul. (Direct3D)

Ogre 2.x o sa adreseze cateva probleme, dar mai e pana atunci.


Ogre asta iti face viata foarte usuara pt prototipuri, proof of concept's, sau jocuri "modeste", dar uite cateva exemple de chestii care Ogre le face prost:
* tinde sa iti faca un vertex buffer separat pt fiecare componenta (position, normal, uv etc.). Dark mi-a dat "tip" ca ar putea fi de la exportor, dar asta e doar o scuza problema e tot acolo.
* daca vrei sa te ocupi personal de transparenta, poti sa iti pui pofta in cui... (eu am avut probleme cu asta, si a trebuit sa recurg la hack-uri neortodoxe, pana la urma m-am lasat pagubas)
* o hierarchie de noduri, depinde de joc si de complexitatea jocului, pana la urma o sa se dovedeasca ineficient, insa cum esti obligat sa-l folosesti, o sa iti cam stea in cale atunci cand vrei sa faci structura ta proprie a scenei. De exemplu daca ai metoda ta acolo de a reprezenta lumea 'fizica' (aia care dicteaza ce sa randezi), probabil nu o sa fie un tree de noduri cum e in Ogre, asa ca o sa ai o anumita structura pt logica jocului, si ceva complet diferit pt ce se randeaza. (iar daca nu mentii o structura balansata pt nodurile de randat, atunci Ogre o sa stea jumate din timp doar parcurgand si facand culling prin ce e defapt o lista de noduri, nu un tree, adica O(n))

Mai sunt alte lucruri, dintre care unele obscure si ciudate (de exemplu daca din greseala pui intr-un material un pixel shader in locul unui vertex shader, Ogre nu se plange ci continua fericit, desi stie care shader de care tip e (nu te gandi la ce greseala stupida am facut eu ca eram beat, ci la ce timp ti-ar pierde tie cand faci vre-o greseala la nimereala, foarte posibil pt ca nu stii pe din afara cum functioneaza Ogre))


Cu toate astea, at the end of the day, tot as folosi Ogre pt proiecte 3D mici - medii. Insa nu l-as folosi pt un proiect decent, comercial. Si oricum exista chestii mult mai simple care sporesc productivitatea mult mai mult decat sa folosesti un engine gata gatit. Personal, dupa ce am trecut de stadiul de vorbaraie si la facut cateva proiecte intr-o echipa, mi sa schimbat mult opinia despre Ogre, si despre rolul unui astfel de engine intr-o joc. (mult mai insemnificant; fata de la inceput, acum 2-3 ani, cand credeam ca ceva gen Ogre este 'centrul' jocului, si restul e doar boilerplate code)


Numai bine, si bine ai venit pe GDro

Salutare la toata lumea.
Sunt nou pe forum, dar nu sunt deloc nefamiliar cu Ogre3D.
De fapt il stiu de cam 3-4 ani si m-am chinuit cu el de atat timp .
Inainte am facut cunostinta cu Irrlicht, un rendering engine f tanar, WIP dar cu un API foarte usor de invatat, mai usor decat cel din Ogre.
API ul lui Irrlicht este mai streight-forward dar mai putin "profesional"
Insa ambele isi au limitare de a fi Rendering Engines.
Acum eu m-am apucat de ceva timp sa creez un 3D Game Engine inchegat, folosindu-ma de experienta mea cu aceste 2 enginuri, incercand sa refactorizez tot ce pot din Ogre pt a avea un cod asemanator ca si Proiectare a codului cu el dar incercand in acelasi timp sa am un API foarte "curat" bine ierarhizat si cu cat mai putine interedependente alambicate si multe inutile.
Enginul de numeste K_Game, este scris de la 0 bucata cu bucata, avand ca "inspiratie" Ogre3d, Irrlicht, NeoEngine, Horde3D. Este scris doar de mine si mai am fff mult de lucru la el , insa progresele se fac simtite si am deja un core, input, math, platform, un pic de script si o baza "primitiva" de rendering bine structurate pana acum.
Ii multumesc Ogre-ului, pt ca are o strustura f buna. Insa isi are limitarile sale si din punctul meu de vedere unele derivari multiple sunt cam inutile.
Puteti vedea enginul meu aici:
http://k-game.sourceforge.net/
si il putei download-a usor de pe SVN unde veti putea vedea ultima versiune in lucru unde am renuntat la Lua in favorea la Angelscript scapand implicit de dependetele cu boos pe care personal nu le agream.
Am ca si Irrlicht propria librarie de "STL": list, array, string, map cu un cod frumos cum doar la Liceu se invata la orele de Informatica , nu ca acel cod "urat" din STL.

Ca sa mai adaug la acest topic:
Ogre ar fi extrem de greu de refactorizat pt a fi extins Din Interior la un Game Engine (de aceea si enginul meu a fost scris de la 0), pt ca exista in el anumite derivari care de cam impiedica ca faci asta prea usor.
ex:
SceneNode : public Node
Node : public Renderable
Mesh: public Resource contine SubMesh-uri
Entity: public MovableObject contine SubEntity-uri
SubEntity: public Renderable

Pt ca putea defini Sound si al atasa la un SceneNode asa cum se poate atasa si un Mesh,Light,Camera ar cam tr sa scapam de ideea de Node ca fiind Renderable insa asta poate/are side-efects in RenderingSystem.
Eu am mers altfel in K_Game separand logic elementele principare ale unui Game Engine : rendering,sound,physics, for fi separate de scene.
Momentan nu am implementat sunetul si fizica, dar randerea este implemnatata conform planului acesta si restul va fi f usor de adaugat.

Cu respect.
Catalin.

Din ce vad, visibilitatea tuturor obiectelor care pot fi atasate de un SceneNode e controlabila si se face cu setVisible()&prietenii, deci nu vad de ce ar putea afecta RenderingSystem-ul (whatever that is). Ai incercat si nu colaboreaza?

Dar dece un Node este de tip Renderable?

Asta pt ca se folosesc de SceneNodes pt a Randa scene si nu de o lista cu Mesh-uri.



Dece adauga in RenderQueue un SceneNode* de tip Node de tip Renderable?
Nu vi se pare o derivare inutila?
Mie da.
Eu consider ca tr sa pastreze o lisata cu Toate obiectele Renderable intr-un
RenderManager si de acolo sa le trimita la pipeline-ul de randare.
Iar SceneNode-urile sa fie folosite doar pt a lega toate tipurile de "Obiecte" care pot aparea intr-o sacena si sa le "menajeze" pozitile lor in acea scena.
Astfle:
"Renderable" <--- RenderManager
"Solid"<----------- PhysicsManager
"Audible"<-------- SoundManager
"Renderable"<----|
"Solid"<----------- |--SceneNode <------SceneManager
"Audibl"e <--------|
InputDevice <----InputManager
Script <-----------ScriptManager

RenderManager <----|
PhysicsManager <----|
SoundManager <-----|-----GameManager
SceneManager <-----|
InputManager <------|
ScriptManager <-----|

Cam asa cred eu ca ar tr sa fie structurat logic un Game Engine si asta incer sa implementez in K_Game pastrand anumite "forme" care se ragasesc atat in Ogre3D cat si spre surprinderea mea si in alte enginuri 3d.

Mi se pare mie sau te referi la a face subclasa la nod pt alte chestii?
Daca vrei, de exemplu, sa faci un sunet sa se tina dupa un nod in Ogre, ori il faci subclasa la MovableObject si dai myNode->attach... (varianta proasta, pt ca MovableObject e relativ mare, si trebuie sa te ocupi de implementare, adica MovableObject e subclasa la ShadowCaster spre exemplu), ori faci ca tot omul, asa ceva:



Din nou, te lovesti un pic de managementul nodurilor, insa daca intradevar intelegi C++, nu e problema. (ex: daca lifetime-u unei surse depinde de parinte, sa zicem, un tanc in joc ce produce sunetul, iar tancul isi tine singur lista de sunete, atunci ai rezolvat (asa ca atunci cand distrugi tancul, distruge asta singur si sursele de sunete))

A mai fost discutie despre chestii din astea pe forumul lor, da un search.[/code]

Tocmai asta incerc eu sa experimentez prin enginul meu: sa elimint astfel de interdependenteanevoioase.
Tocmai astfel de probleme pe care le-am avut cu Ogre m-au determinat sa pornesc un proiect ca al meu.
Si sa nu credeti ce e cine stie ce, INCA, e doar un engine experimental momentan, dar cu posibilitati marete si f serioase.
Ca o gluma serioasa: Incerc sa rezolve acele probleme de design/proiectare pe care nimeni nu le-a rezolvat in Ogre pana acum si sa extind designul la un game engine.

Tu cind ai pomenit de RenderSystem si side-effects credeam ca te referi la ceva practic deoarece in teorie n-are cum sa aiba side-effects. Si in practica poti sa faci ce ai spus tu, setind nodul sa nu fie vizibil si la revedere, te pisi pe OOP-ul lui.
Pe tine de fapt te deranjeaza manifestul OOP a lui Ogre si modul in care n-au inteles nimic si au abstractizat totul cu copy/paste de prin 3dsmax (o alta oaza de inteligenta la capitolul API si OOP).

jos8cal:

Exact.

Salut raicuandi

Foarte bine zis, ca aceste engine-uri sunt foarte generalizate iar daca trebuie sa faci un anumit lucru in cel mai bun caz e mai complicat iar in cel mai rau caz trebuie sa faci hack-uri neortodoxe. M-am jucat si eu un pic cu Ogre3D pentru proiecte mici e interesant insa m-am lovit la aceeasi problema, ierarhizarile intr-o scena si gruparea nodurilor. Pana la urma tot la Direct3D ajungi :p