Nejde delat prime zobrazovani objemovych dat tak, ze se proste vezmou jako posloupnost otexturovanych odbelniku s ruznou souradnici Z a ta se zobrazi pomoci soucasnych grafickych akceleratoru? Pripadne jde to delat nejak chytreji?
Jde to dělat přesně jak říkáš. Chytřeji k tomu lze pomocí shaderů v +/- reálném čase počítat normálové vektory a stínování pro každý bod textury. Fragment shadery lze použít pro raycasting.
Jde, ale v případě, že se takovým předmětem rotuje, vznikají nežádoucí jevy. Pokud se na ty obdélníky (v podstatě řezy) díváte z úhlu, který je na ně skoro kolmý, není problém, u úhlu blížícího se k 45 stupňům je to už horší. Nejlepší je představit si voxelové těleso jako kostku složenou z malých kostiček. Pokud se díváte kolmo (či skoro kolmo) na jednu ze stěn kostky, není problém - řezy lze dělat ve všech třech osách, při pootočení se potom musí volit, kterou ze skupiny tří řezů zvolit.
Samozřejmě je možnost to řezání na otexturované obdélníky provádět nikoli po vrstvách, ale v libovolném směru, to ovšem znamená po každém pootočení provést přepočet řezů a následně je co nejrychleji nastrkat do grafického akcelerátoru. Rychlost těsně na hraně použitelnosti při SW řešení.
Pokud by byl zájem, můžu se o této problematice víc rozepsat (ale mimo POV-Ray), dělali jsme pro volume rendering i jeden vlastní akcelerátor.
Ono je možné sadu řezů vždy prohodit za "nejvíce kolmé", ale vždy se zobrazení na chvíli sekne (no dnes při běžných 256-512MB RAM na grafice problém nebude). Co se týká kolmých řezů, dají se na to využít objemové textury a trilineární interpolaci zvládne grafika. Problém je, že řezů je potřeba celkem dost (řádově stovky) jinak vznikají artefakty viditelné zvlášť na ostrých hranách v datech, takže kvalita vs. je kompromis.
Máš pravdu, ale to "nejvíce kolmé" je při pohledu na kostku z úhlu 45 stupňů trošku problém, nejhorší případ nastane tehdy, když se uživatel dívá přímo na jeden z rohů kostky. Řešit se to dá, ale vizuální chyba narůstá, je vidět "překrývání" jednotlivých otexturovaných obdélníků, jak správně píšeš kvalita vs rychlost. Při velikosti voxelového objektu:
256x256x256 voxelů se dostáváme ke kapacitě:
256 textur o rozlišení 256x256 = 16 MB
x 3 (pohledy) = 48 MB, což je v pohodě (počítám s tím, že každý voxel je na 8 bitů, ne 12)
512x512x512 voxelů je už na hraně:
512 textur o rozlišení 512x512 = 128 MB
x 3 = 384 MB, takže toto lze na dnešních grafikách považovat za limit (ono taky zpracování 384 MB textur něco trvá i akcerátoru)
Kupodivu čistě SW řešení vychází taky docela rychle.