Vlákno názorů k článku Open Inventor: Knihovna pro realtimovou 3D grafiku od Tomas Crhonek - Prominte, asi pomaleji chapu, ale proc se material...

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.