No, vim jen o jedine knihovne: v clanku zminenem OpenGL Performeru (http://www.sgi.com/software/performer/). Demo-verze je tam ke stazeni.
Lepsi reseni by ale asi bylo napsat aplikaci v c a pro nezbytny stik s Inventorem si napsat wrapper. Tim si zachovame vsechny vyhody c-cka a wrapper by mel byt dost stupidni na to, aby byl take prenositelny.
Jinak me uz nic nenapada,
John
Prominte, asi pomaleji chapu, ale proc se material pro ten kuzel vklada do celeho (SoSeparator *)root a ne jen pro (SoCone *)? Co se stane, kdyz do (SoSeparator *)root vlozim vice materalu? A jak se potom budou nastavovat vlasnosti toho svetla? Taky v (SoSeparator *)root? Prijde mi to hrozne nekoncepcni, ale mozna jsem neco prehledl.
A jeste, proc je na konci provedena delalokace delete RenderArea;, kdyz jak autor pise, se ten kod nikdy neprovede?
Nemuzu si pomoct, ale tento system mi pripada hrozne neprehledny {stejny pocit jsem mel u Qt, ten se tady vyuziva taky :) ), na rozdil od knihovny glut, ktera je jednoduse prehledna, tak jako cele OpenGL (i slozite veci se tam delaji jednoduse, kdyz uz clovek konecne pochopi system :) ).
> Prominte, asi pomaleji chapu [...]
Detailni rozbor designu a koncepcnich navrhu Inventoru jsem schvalne neuvadel v prvnim dile, ale pridrzel jsem se konceptu pouzivanych v nekterych knihach, kde se zacina jednoduchymi priklady, a nekdy az prilis nudna teorie se uvadi pozdeji.
> Proc se material pro ten kuzel vklada do celeho (SoSeparator *)root a ne jen pro (SoCone *)?
V Inventoru existuji tri zakladni prvky: nody, akce a elementy, odvozeny od zakladnich trid SoNode, SoAction a SoElement. Nody jsme si uz predstavili a ukazali jsme si, jak z nich stavet sceny. Akce zde zmineny nebyly, ale nevedomky jsme je pouzivali pri kazdem renderovani sceny. SoGLRenderAction prochazi cely graf sceny "in-order". Pricemz kazdy nod, kterym se prochazi muze zpusobit napriklad vyrenderovani nejakeho objektu nebo zmenit aktualni "stav" uchovavany v elementech. Tyto elementy casto reprezentuji stavove promenne OpenGL. Aktualni stav v techto elementech se zachovava pri sestupu hloubeji do grafu, avsak pri vystupu zpet nahoru, tedy pokud je nadrazeny nod typu SoSeparator nebo jeho potomek, se obnovuje stav do podoby, nez jsme vstoupili do tohoto podgrafu.
> Nemuzu si pomoct, ale tento system mi pripada hrozne neprehledny, na rozdil od glut a OpenGL.
Toto, co se zda slozite, je ve skutecnosti velmi jednoducha myslenka. Inventor ve skutecnosti skvele stavi na nekterych konceptech OpenGL a dotahuje je do dusledku.
> A jeste, proc je na konci provedena delalokace delete RenderArea.
"Opravdovi" programatori, tak jako ze nikdy nepisou komentare ani dokumentaci :), a pisou sebemodifikujici kod i pro vnejsi smycky sveho algoritmu, taky nemuzou snest, aby jejich kod, ktery alokoval pamet, neobsahoval kod i pro jejich dealokaci, byt by nikdy nedostal moznost provest se :-) .
Je to nadbytecny kod, klidne ho smazte. Jedine jeho vyuziti je pri zmene mainLoop za mainLoopWithExit, a pak muzeme hledat diry v pameti.
Ach jo, jeste nedavno to fungovalo. Pomalu zacinam mit strach, ze ta kniha uz prestava byt volne ke stazeni na netu - jako by na ni zacal mit nekdo copyright. V kazdem pripade jsem snad pred rokem ci kdy stahl od SGI i pdf verzi, kterou jsem nedavno uspesne nasel mezi svymi dokumenty. Docasne jsem ji umistil na http://www.fit.vutbr.cz/~peciva/Mentor.pdf .
Cele odpoledne jsem se pokousel zkompilovat ukazku z prvniho dilu, ale jako bohuzel... Problemy jsou se SoQt - nektere verze neslo ani zkompilovat (RH 9), u CVS verze se to sice povedlo, ale pri kompilaci ukazky to na me chrli spousty hlasek o chybach v souboru SoQt.h (a to primo parse error, dal tam jsou 3 duplicate member SoQt::QWidget a korunuje to HelloCone.cpp:18: `SoQt::init' cannot be used as a function).