znaméná to tedy, že do budoucna normal mapy ani podporovat nebude?

imho... moc sa v tom síce nevyznám (v luxe), ale myslím, že implementácia normálových máp je primitívna záležitost a ak tam zatiaľ nie je, mali by sa čoskoro objaviť...

lux zobere RGB farbu ktoru do neho tlacis a musi si ju prekonvertovat do celeho spektra a potom s tymto spektrom dalej pocita, konverzia neni 100% presna aj ked sa snazia mocne

tzn. ze na obycajnych farebnych mapach to moc nezbadas... ale na texture ktora ti v RGB hodnote drzi natocenie normaly toho pixelu po konverzii tejto hodnoty do spektra moze nastat nejaka odchylka ktora uz bude videtelna ako (nezelana) deformacia toho povrchu
lux vo svojich vypoctoch vobec nepracuje s RGB

takze suhrn - podpora normal map je mozna, ale v tomto pripade rozhodne nie primitivna ani jednoducha

..a kedze vyvojari pracuju na mnohych 100x potrebnejsich features, tak sa podpora normalmap odsuva do nedefinovatelnej buducnosti

otazka je - naco pouzivat normal mapy vo fyzikalne presnom render engine.. to uz treba riesit fakt displacement
jedinu vyhodu by to malo vtedy ak fakt niekto potrebuje usetrit RT a nezalezi mu na kvalite, resp. si chce prerenderovat nejake realtime modely (a v tomto pripade ak si ich robil sam tak si vzdy mozes baknut displacement mapu a pozuit v luxe tu).. lenze v oboch pripadoch na to postacuje blender internal renderer

a inac - lux je open source, ak chces novu feature a ocividne na nej nikto nerobi tak zober zdrojak, mrkni sa na to a implementuj to...

prečo používať normal mapu a nie displacement je prosté. sú momenty, kedy normal mapa stačí (keď nie sú deformované hrany). a z časových dôvodov môže byť pri schopnej implementáicí dokonca rýchlejšia ako štandardný normal smoothing. ako som sa dnes docital v clanku vo vrbovni alebo v novinkach:
lux render je postaveny na openGL.
openGl funguje takto v smooth móde:
-vyšlem lúč z kamery na povrch
-dostanem bod objektu, ktorý som trafil

-vezmem normály verticlov pripadajúcich facu, ktorý som trafil, urobím vážený priemer a vrátim výsledok normály, normujem ho na jedničku
s normal mapou tento bod vyzerá takto:
-vermem UV koordinaty, pozriem sa na textúru a z jej RGB mi výjde normovaná normála

-a potom už máme všetky dáta o bode a ide vyhodnocovanie lúčov a fotónov a tak...

imho je to jednoduchšie a ak je dobre implementovaná správa bitmáp, bude to výpočetne jednoduchšie.
preto ak je objekt statický, je z optimalizačného hľadiska lepšie použiť normal mapu, než pre každý frame počítať normály nanovo...

ale teraz k otázke:
ako myslíš, že RGB sa konvertuje na spektrum? predstavujem si to ako prevod na HSV, je to tak? Ale konvertuje to takto automaticky aj akýkoľvek obrazový vstup? pretože by bolo proti logike, keby sa to robilo v jednom pipeline aj s načítaním...
na študovanie kódu jaksi nemám v súčastnosti čas, ale celkom ma zaujíma, čo vravíš...

zial nie som programator a ani programator teoretik takze taketo detailne diskusie nedokazem dalej rozvyjat..

pokial viem tak sa konvertuje vsetko RGB ktore je na vstupe, pocita sa v spektre a potom sa vystup zase konvertuje na RGB aby sa dal zobrazit (presnu pipeline ti ale nepoviem)
kedze sa jedna o simulator svetla tak pocitanie v RGB by bolo velmi kratkozrake a postacuje iba renderom 'klasickej konstrukcie'

pokial to chapem spravne tak ano je to podobny proces ako konvertovat RGB na HSV a pod, ale s tym rozdielom ze v spektre je vacsie mnozstvo odtienov tak preto nemoze byt ta normala dostana zo spektra totozna s normalou dostanou z RGB a nastane tam nejaka odchylka

mozno by sa dal tento problem riesit nejakym sub-enginom na RGB ktory by riesil len vyhodnocovanie normal z normalmap.. ale asi by to nebolo vonco, pridali by sa komplikacie a mozno aj dlhsi RT, ktovie, viem len ze vyvojari velmi oslavovali ked sa zbavili ostatkov RGB v jadre luxu

pre upresnenie lux neni postaveny na openGL (iba GUI - teda framebuffer a dokonca aj tam sa da openGL vypnut pri nejakych zlych ovladacoch a pod.)
je to normalne pisane v C/C++

momentalne sa vyvyja komponent (kniznica) luxrays ktora umoznuje akcelerovat raytracing cez openCL, luxrays sa dokonca da pouzit aj v inych rendereroch (dufam ze ked to bude stabilne uvidime implementaciu pre blender internal renderer)

inac z luxrender wiki: