Vlákno názorů k článku Grafické algoritmy implementované v 3D akcelerátoru Voodoo 1 od kvr kvr - Ten hlavní klad není ani tak v lepším pokrytí...

Ten hlavní klad není ani tak v lepším pokrytí (ono je to diskutabilní – 1/x při větších x nemá zrovna vhodný průběh, i když u větších x je to zde samozřejmě méně podstatné).
Primárně jde ale o to, že při promítnutí (horizontální) čáry je vzdálenost mezi dvěma body 1/lineární, tedy při jejím vykreslení stačí spočítat z0 a z1 (vzdálenost začátku, konce), inverse_zstep = (1/z1–1/z0)/pixel_cnt a s každým pixelem pouze přičítat postupně inverse_zstep a vyhnout se tak náročnému dělení.

Nevím, zda tím byl myšlen onen „konstantní krok mezi vzdálenostmi“, takže pro jistotu pro vyjasnění :)

ono jde hlavně o to, že s celočíselným Z se uživateli zdá, že Z je hrubý pro blízké objekty a jemný pro vzdálené objekty. Při reálném Z je ten průběh takový, že blízké objekty mají detalněji odstupńovaný Z, než vzdálenější.

Ono je to dvousečný, protože při tomhle způsobu práce se Z mají vzdálenější objekty znatelný Z alias, který může být rušivějšá, než alias u blízkých objektů, který nemusí být až tak hrubý, jako u toho převráceného způsobu zápisu. Všechny tyhle problémy efektivně řeší 32-bitový Z buffer, který má 65536× jemnější vzorkování a kde volba formátu už nehraje takovou roli (DEPTH-BUFFER vs Z-BUFFER v D3D terminologii)

Pravda, 32bitovy Z-buffer (nejlepe w-buffer resp. jak pises DEPTH-BUFFER) uz je dostatecny, pokud tedy programator nenastavi uplne nesmyslne hodnoty do transformacnich ma­tic.

Problem s Voodoo 1 spocival v tomto pripade v tom, ze texturovaci DRAM byla oddelena od framebufferu, takze programator proste nemel moznost si napriklad pro CAD aplikace (objekty bez textur) naalokovat 32bitovy Z-buffer nebo zvetsit rozliseni a naopak, pokud potreboval vic texturovaci pameti (a ozelel napriklad Z-buffer, protoze sortil scenu), taky s tim nemohl nic moc delat.