[disc] Voxels: sleutel tot realisme?

[Sanity11]

Laatst voerde ik een discussie in een ander forum over realisme van de nieuwe generatie games. Sommigen beweerde dat nieuwe grafische engines al voor 90% realisme op het scherm weten te toveren. Andere (waaronder ik) beweerde dat dat nog niet eens 30% is. Ook waren erbij die zijden dat de voxel engine (Outcast, Deltaforce) weer eens uit de kast gehaald moest worden omdat deze beter geschikt was om echt realistische graphics te kunnen maken. Hoe denken jullie over dit onderwerp?

[Pelle]

Ik denk dat het in het verkeerde forum staat, ik ben er alleen nog niet over uit of dit naar P&W moet (waar de OpenGL en D3D proggers zitten) of naar Spielerij.. zal es overleggen

[et36s]

P&W daar zul je meer mensen hebben met verstand van zaken die dus ook hun standpunt degelijk kunnen onderbouwen.

[drm]

mja, even dicht voor overleg

edit:
En weer open

[ Voor 32% gewijzigd door drm op 07-01-2004 14:04 ]

[Soultaker]

Het probleem met voxel engines is dat de voxels alleen maar een representatie zijn van hoe de wereld er uiteindelijk uit komt te zien en je er dus niets aan hebt om een geloofwaardige wereld te modelleren. Voxels zijn dus een vrij low-level modelleringstechniek en daardoor, denk ik, niet toereikend om een min of meer fysisch correcte wereld mee te modelleren.

Je kunt voxels vergelijken met de pixels in een foto. Je kunt een fotorealistisch plaatje opbouwen uit pixels, maar de pixels zelf helpen je niet om dat plaatje tot stand te brengen: de foto bestond al en de pixels gebruik je alleen maar om een representatie van de foto op te bouwen. Wat dat betreft zijn voxels en pixels dus uitermate statisch: je kunt ze alleen gebruiken om een beeld vorm te geven dat je al ergens anders vandaan gehaald hebt; maar hoe genereer je een realistische foto als je die niet toevallig al had (ingescanned ofzo)?

De meeste grafisch ontwerpers zullen wel weten dat als je een wat meer 'dynamisch' plaatje wil maken, je veel meer hebt aan lijnen en curven; die kun je met behoud van beeldkwaliteit transformeren (roteren, schalen, verplaatsen). Als je dus een animatie wil maken heb je veel meer aan curven dan aan pixels. Er bestaat een simpele analogie in 3 dimensies: als je een dynamische wereld wil maken, heb je veel meer aan polygonen dan aan voxels. De polygoon-representatie is in theorie om te zetten naar een benadering in een voxel-representatie, maar in de praktijk wordt die stap natuurlijk overgeslagen omdat het 3D beeld uiteindelijk toch op een 2D vlak wordt geprojecteerd.

Kort samengevat denk ik dus niet dat voxel engines veel te bieden heeft als het gaat om het modelleren van een realistische wereld. De huidige technieken met het renderen van polygonen heeft ook zo z'n problemen (voornamelijk het ontbreken van volume) maar ik zie dan meer heil in modelleertechnieken van hoger nivo zoals CSG, die uiteindelijk terug kunnen vallen op het tekenen polygonen voor het renderen van de wereld. In de praktijk zie je nu ook al dat op polygonen gebaseerde engines allerlei trucjes met bounding boxes en dergelijke gebruiken om objecten nog een beetje volume te geven. Hoewel voxels dat volume al uit zichzelf hebben, is dat ook eigenlijk hun enige voordeel.

[D4Skunk]

Voxel engines zijn eigenlijk niet echt nodig, gezien de huidige trend met displacement mapping. (=voxels op polys)

Ik ken eigenlijk maar 1 3D-voxel-engine (redelijk experimenteel) :
voxlap
Recentste versie voxlap

[ Voor 15% gewijzigd door D4Skunk op 07-01-2004 14:18 . Reden: link naar laatste versie engine ]

[.oisyn]

Mja, ik denk dat je hedendaagse hardware onderschat. Voxels zijn op zich een mooi concept, maar een beetje achterhaald. True, je kunt er mooi gevormde landschappen mee maken, maar het heeft ook zo z'n beperkingen. Plus het feit dat het een stuk meer geheugen inneemt, maar dat is tegenwoordig niet echt een issue meer

Voxels zijn namelijk best lelijk, zeker de stukjes die dichtbij liggen. Enorme pixels voor op je scherm, dat kan toch niet meer tegenwoordig? En dan nog, je landschappen met voxels zijn enorm gelimiteerd, het is namelijk een heightfeild, dus overhellende stukken kunnen al niet meer. Daar is wel met wat hacks omheen te werken, maar de vraag is of je er de moeite voor wilt doen, aangezien je met een goede landscape engine op hedendaagse hardware veel mooiere dingen kunt bereiken.

Dus nee, ik denk dat ze voxels maar achterwegen moeten laten. In ieder geval totdat we het punt bereikt hebben dat realtime raytracers hun opmars maken, hoewel ik betwijfel of dat ooit zal gaan gebeuren


voxels in deltaforce:


polygonen in halo:

[Sanity11]

Soultaker schreef op 07 januari 2004 @ 14:07:
Het probleem met voxel engines is dat de voxels alleen maar een representatie zijn van hoe de wereld er uiteindelijk uit komt te zien en je er dus niets aan hebt om een geloofwaardige wereld te modelleren. Voxels zijn dus een vrij low-level modelleringstechniek en daardoor, denk ik, niet toereikend om een min of meer fysisch correcte wereld mee te modelleren.

Je kunt voxels vergelijken met de pixels in een foto. Je kunt een fotorealistisch plaatje opbouwen uit pixels, maar de pixels zelf helpen je niet om dat plaatje tot stand te brengen: de foto bestond al en de pixels gebruik je alleen maar om een representatie van de foto op te bouwen. Wat dat betreft zijn voxels en pixels dus uitermate statisch: je kunt ze alleen gebruiken om een beeld vorm te geven dat je al ergens anders vandaan gehaald hebt; maar hoe genereer je een realistische foto als je die niet toevallig al had (ingescanned ofzo)?

De meeste grafisch ontwerpers zullen wel weten dat als je een wat meer 'dynamisch' plaatje wil maken, je veel meer hebt aan lijnen en curven; die kun je met behoud van beeldkwaliteit transformeren (roteren, schalen, verplaatsen). Als je dus een animatie wil maken heb je veel meer aan curven dan aan pixels. Er bestaat een simpele analogie in 3 dimensies: als je een dynamische wereld wil maken, heb je veel meer aan polygonen dan aan voxels. De polygoon-representatie is in theorie om te zetten naar een benadering in een voxel-representatie, maar in de praktijk wordt die stap natuurlijk overgeslagen omdat het 3D beeld uiteindelijk toch op een 2D vlak wordt geprojecteerd.

Kort samengevat denk ik dus niet dat voxel engines veel te bieden heeft als het gaat om het modelleren van een realistische wereld. De huidige technieken met het renderen van polygonen heeft ook zo z'n problemen (voornamelijk het ontbreken van volume) maar ik zie dan meer heil in modelleertechnieken van hoger nivo zoals CSG, die uiteindelijk terug kunnen vallen op het tekenen polygonen voor het renderen van de wereld. In de praktijk zie je nu ook al dat op polygonen gebaseerde engines allerlei trucjes met bounding boxes en dergelijke gebruiken om objecten nog een beetje volume te geven. Hoewel voxels dat volume al uit zichzelf hebben, is dat ook eigenlijk hun enige voordeel.

Hmm ja dat klinkt aannemelijk. De reden dat dat gezegd werd is dat de werkelijke wereld ook uit een soort voxel engine bestaat (molecuulen). maar wanneer het 3d beeld op een 2d vlak geprojecteerd word gaat dat dus niet op.

[Verwijderd]

Voxels zijn een vorm van volume rendering toch?

In dat geval kan je er inderdaad hele mooie plaatjes mee maken, zeker als je de voxels ook een transparency waarde geeft en de juiste blending functie gebruikt.

Ik heb ook al voorbeelden gezien van volume rendering geaccelereert door middel van moderne GPU technieken (pixel shaders)

Maar ik zie nog niet echt toepassingen hiervoor voor games. Je kan mooi een realistisch plaatje maken van een rontgen-scan; van een mens, of van een skelet. Bijvoorbeeld op een resolutie van xyz 512x512x4096. Dit neemt an sich al een enorme berg ruimte in (oke, er zijn trucjes dit terug te brengen door middel van compressie en weglaten van onzichtbare vertices) Echter, als je dit ook nog eens wilt animeren.. tel uit je verlies :-)
Verder heb je inderdaad het dynamische aspect dat niet mogeljk is (buigen van gewrichten in een ai script ed), zoals hierboven al genoemd.

edit: dat plaatje van deltaforce is dus een voorbeeld van hoe het NIET moet Maar ik vrees dat het niet veel gedetailleerder/hogere resolutie kan met hedendaagse hardware.

[ Voor 9% gewijzigd door Verwijderd op 07-01-2004 14:21 ]

[.oisyn]

Soultaker schreef op 07 januari 2004 @ 14:07:
Je kunt voxels vergelijken met de pixels in een foto. Je kunt een fotorealistisch plaatje opbouwen uit pixels, maar de pixels zelf helpen je niet om dat plaatje tot stand te brengen: de foto bestond al en de pixels gebruik je alleen maar om een representatie van de foto op te bouwen. Wat dat betreft zijn voxels en pixels dus uitermate statisch: je kunt ze alleen gebruiken om een beeld vorm te geven dat je al ergens anders vandaan gehaald hebt; maar hoe genereer je een realistische foto als je die niet toevallig al had (ingescanned ofzo)?

ik ben het niet helemaal eens met je vergelijking. Landschappen zijn namelijk enorm goed te genereren, zelfs fotorealistische landschappen.

In de praktijk zie je nu ook al dat op polygonen gebaseerde engines allerlei trucjes met bounding boxes en dergelijke gebruiken om objecten nog een beetje volume te geven. Hoewel voxels dat volume al uit zichzelf hebben, is dat ook eigenlijk hun enige voordeel.

ik begrijp je niet goed, kun je daar een voorbeeld van geven?

[.oisyn]

Verwijderd schreef op 07 januari 2004 @ 14:18:
Voxels zijn een vorm van volume rendering toch?

voxels zijn idd in feite "3d pixels", maar in games wordt het vooral toegepast als heightfields. Dan heb je dus een 2d array met hoogte-waarden, dat op een snelle manier te renderen is.

Ik heb overigens wel ooit eens een demo gezien op flipcode van iemand die een echte 3d voxel wereld gebruikte, maar het geheugengebruik van zo'n wereld is enorm. Als je 1024 bij 1024 bij 1024 units hebt dan zit je al aan 1G aan voxels, om nog maar te zwijgen over hoe je kleur-informatie op gaat slaan

[drm]

Ik heb overigens wel ooit eens een demo gezien op flipcode van iemand die een echte 3d voxel wereld gebruikte, maar het geheugengebruik van zo'n wereld is enorm. Als je 1024 bij 1024 bij 1024 units hebt dan zit je al aan 1G aan voxels, om nog maar te zwijgen over hoe je kleur-informatie op gaat slaan

Wat dat betreft is het misschien wel het best te vergelijken met bitmaps versus vector-bestanden in de 2D wereld, als ik het goed begrijp...

Overigens: is het dan niet zo dat er een punt moet zijn waar de gulden middenweg ligt? Ik kan me voorstellen dat voor gezichten bijvoorbeeld een voxel-representatie mooier uit de verf komt dan met polygonen, zoals je bijvoorbeeld gewoon bitmap-foto's in drukwerk zult gebruiken terwijl je voor het logo vectors gebruikt (even kort door de bocht).

Is het niet te combineren? Of is dat uberhaupt onzin?

[Verwijderd]

Er zijn veel methoden die kleur informatie op te slaan. X*Y*Z is inderdaad de upper bound. Sparse arrays, RLE, fractal representations en ga zo maar door. Echter, het is maar net hoeveel render snelheid je op wilt offeren voor geheugenruimte.

Trouwens; heightfields render je toch meestal als mesh? Daar hebben voxels naar mijn idee weinig mee te maken. Doe je dat dmv volume rendering is het wel een handige manier om elke optimalisatie te omzeilen :-)

Gezichten zijn weer beter met een wiskundige surface-benadering (splines/patches) te benaderen dan met voxels of platte polygonen. Zeker van dichtbij zie je niet zo graag het hoekige gezicht dat voxels met 'normale' resolutie opleveren.
Indien je per object zou kunnen kiezen tussen de verschillende benaderingen zou het inderdaad ideaal zijn. Het probleem is dat sommige rendering methoden elkaar binnen een scene uitsluiten.

[Dark_M]

Ik denk dat je niet alleen moet kijken naar het grote visuele verschil tussen voxels en polygonen.. Mooi voorbeeldje is Worms 3D: De Worms 3D engine maakt gebruik van een engine welke Voxels en Polygonen combineerd.
De volgens quote van de website van W3D zegt eigenlijk al wel genoeg denk ik.

http://www.worms3d.com/about.html?area=tech
Worms 3D uses a proprietary, all-new deformable polygon/voxel landscape engine that allows the player to destroy any part or ALL of the landscape, from any direction.

Shoot through the floor, make a hole and shoot at the player below you on a plateau!

Tunnel your way through the hillside! Blast your way through! Watch as the landscape crumbles, sinks and deforms as you use progressively more powerful weapons!

Unlike other engines, the technology allows you to explode any part of the land, create holes, tunnels, cliffs, caves and emulates the way the game played in 2D. We're pretty pleased with it.

Een dergelijke manier van aanpasbaarheid van het landschap wat dus bereikt kan worden door het gebruik van voxels heeft qua realisme wat mij betreft een hogere prioriteit dan het visuele aspect.

/edit
Natuurlijk is Worms 3D niet bepaald het beste voorbeeld van realisme maar ik neem aan dat wel begrepen wordt wat ik precies bedoel.

[ Voor 10% gewijzigd door Dark_M op 07-01-2004 21:59 ]

[curry684]

.oisyn schreef op 07 januari 2004 @ 14:23:
[...]
Ik heb overigens wel ooit eens een demo gezien op flipcode van iemand die een echte 3d voxel wereld gebruikte, maar het geheugengebruik van zo'n wereld is enorm. Als je 1024 bij 1024 bij 1024 units hebt dan zit je al aan 1G aan voxels, om nog maar te zwijgen over hoe je kleur-informatie op gaat slaan

Ik heb thuis nog ergens wat interessante linkjes van Flipcode/Angelcode e.d., waar oa. ook een echt subliem uitziende wereld gepresenteerd werd die heel vriendelijk was in het geheugengebruik omdat ie een heel grove map gebruikte, die bij de rendering realtime werd geinterpoleerd om dichtbij meer polygonen te produceren. Dit gaf fantastisch resultaat en is met de CPU's van tegenwoordig nauwelijks merkbare overhead. Tevens kun je met de multipass texturing van tegenwoordig geniale landschapsovergangen creeren zonder voor iedere scheet een nieuwe texture nodig te hebben.

Voxels zijn volgens mij nog lang niet dood, maar je moet ze weten te gebruiken, oftewel goed combineren met 'advanced scenes' waar je true 3D er seamless in mixt om bijvoorbeeld een grot in te kunnen gaan.

[.oisyn]

Verwijderd schreef op 07 januari 2004 @ 14:32:
Er zijn veel methoden die kleur informatie op te slaan. X*Y*Z is inderdaad de upper bound. Sparse arrays, RLE, fractal representations en ga zo maar door. Echter, het is maar net hoeveel render snelheid je op wilt offeren voor geheugenruimte.

Dat zijn de traditionele voxels ja, we hebben het nu over de toepassing van voxels in games

Trouwens; heightfields render je toch meestal als mesh? Daar hebben voxels naar mijn idee weinig mee te maken. Doe je dat dmv volume rendering is het wel een handige manier om elke optimalisatie te omzeilen :-)

Nee, heightfeilds hoef je niet per se te renderen met een mesh. Met voxels kan het ook op een supersnelle manier (door een soort van raycasting techniek toe te passen om zo alle verticale beeldlijnen af te gaan en over het landschap te scannen)

---

DarK_M: dat kan ook met tradiotionele polygoon-engines, kijk bijvoorbeeld eens naar red faction waar je muren e.d. op kunt blazen om je zo een weg ergens doorheen te tunnelen

[Verwijderd]

Maar om zijn realisme en fysisch correctheid staat worms niet bekend..
Zo had je in worms 2d al losse vliegende pixels en plateaus, dit kan je nu met voxels verwachten.

Je kan 'schade' heel goed simuleren door voxels uit te wissen. Echter, physics (alles dat dynamisch beweegt) is moeilijker.

Edit:

Nee, heightfeilds hoef je niet per se te renderen met een mesh. Met voxels kan het ook op een supersnelle manier (door een soort van raycasting techniek toe te passen om zo alle verticale beeldlijnen af te gaan en over het landschap te scannen)

Verticale beeldlijnen... huh? Dit werkt dus niet als je naar links of rechts overhelt? Of van boven naar het landschap kijkt?

[ Voor 42% gewijzigd door Verwijderd op 07-01-2004 14:47 ]

[Soultaker]

.oisyn schreef op 07 januari 2004 @ 14:19:
ik ben het niet helemaal eens met je vergelijking. Landschappen zijn namelijk enorm goed te genereren, zelfs fotorealistische landschappen.

Dat klopt, maar gebeurt dat dan ook op basis van voxels? De enige methode die ik ken is met iteratieve subdivisie waarbij je uiteindelijk een height map overhoudt. Die height map moet daarna weer omgezet worden in (naar keuze) een voxel of polygoon representatie.

ik begrijp je niet goed, kun je daar een voorbeeld van geven?

Het voordeel van een volumetrisch model van de wereld, bedoel je? DarK_M gaf daar al een mooi voorbeeld van met Worms 3D: je kunt in een wereld van voxels goed tunnels graven en kraters slaan (wat natuurlijk hoort in een Worms-wereld ); je haalt dan immers gewoon materie (voxels) uit de wereld. Met een landschap dat bestaat uit polygonen is dat lastiger, aangezien de polygonen alleen de 'schil' van een object vormen en het object zelf dus niet direct een volume heeft. Als je een gat maakt in een polygoon-landschap is niet direct duidelijk hoe dat gat gerenderd moet worden (waar haal je bijvoorbeeld je textures vandaan?), terwijl dat in een voxel wereld direct duidelijk is.

Verwijderd schreef op 07 januari 2004 @ 14:43:
Maar om zijn realisme en fysisch correctheid staat worms niet bekend..
Zo had je in worms 2d al losse vliegende pixels en plateaus, dit kan je nu met voxels verwachten.

Je kan 'schade' heel goed simuleren door voxels uit te wissen. Echter, physics (alles dat dynamisch beweegt) is moeilijker.

Dit was exact mijn punt, eigenlijk, maar dan wat korter verwoord.

drm schreef op 07 januari 2004 @ 14:29:
Overigens: is het dan niet zo dat er een punt moet zijn waar de gulden middenweg ligt? Ik kan me voorstellen dat voor gezichten bijvoorbeeld een voxel-representatie mooier uit de verf komt dan met polygonen, zoals je bijvoorbeeld gewoon bitmap-foto's in drukwerk zult gebruiken terwijl je voor het logo vectors gebruikt (even kort door de bocht).

Als je mensen realistisch wilt renderen dan kun je niet volstaan met een 'statisch' gezicht; gezichtsanimatie moet mogelijk zijn. Met voxels is dat ontzettend moeilijk (net zoals het ontzettend moeilijk is om een bitmap foto te 'animeren'). Voor iets als een gezicht heb je dus juist veel meer aan hoger nivo beschrijving; een polygon mesh is nog relatief goed te deformeren om iets van gezichtsanimatie te krijgen. Als je die mesh vervolgens mooi smooth rendert lijkt het resultaat me veel beter dan wanneer je het op moet bouwen uit voxels.

[ Voor 39% gewijzigd door Soultaker op 07-01-2004 14:53 ]

[.oisyn]

curry684 schreef op 07 januari 2004 @ 14:41:
[...]

Ik heb thuis nog ergens wat interessante linkjes van Flipcode/Angelcode e.d., waar oa. ook een echt subliem uitziende wereld gepresenteerd werd die heel vriendelijk was in het geheugengebruik omdat ie een heel grove map gebruikte,

volgens mij niet hetzelfde, maar ik vond deze terug:


klik om naar de betreffende flipcode pagina te gaan

[.oisyn]

Soultaker schreef op 07 januari 2004 @ 14:48:
[...]

Dat klopt, maar gebeurt dat dan ook op basis van voxels? De enige methode die ik ken is met iteratieve subdivisie waarbij je uiteindelijk een height map overhoudt. Die height map moet daarna weer omgezet worden in (naar keuze) een voxel of polygoon representatie.


[...]

Het voordeel van een volumetrisch model van de wereld, bedoel je?

nee, het gebruik van bounding boxes om volume weer te geven
Ik neem aan dat je dat grafisch bedoelt, en niet voor bij dingen als in je collision detection e.d. (want dan is het natuurlijk logisch, maar dat is ook nog steeds het geval bij voxels)

Dit was exact mijn punt, eigenlijk, maar dan wat korter verwoord.

ah ja, het meer traditionele gebruik van voxels dus

[Opi]

curry684 schreef op 07 januari 2004 @ 14:41:
[...]

Ik heb thuis nog ergens wat interessante linkjes van Flipcode/Angelcode e.d., waar oa. ook een echt subliem uitziende wereld gepresenteerd werd die heel vriendelijk was in het geheugengebruik omdat ie een heel grove map gebruikte, die bij de rendering realtime werd geinterpoleerd om dichtbij meer polygonen te produceren.

Zou je deze linkjes misschien een keertje willen posten?

Verwijderd schreef op 07 januari 2004 @ 14:43:
Je kan 'schade' heel goed simuleren door voxels uit te wissen. Echter, physics (alles dat dynamisch beweegt) is moeilijker.

Waarom is dynamica moeilijker te gebruiken met voxels? Je zou namelijk denken dat je makkelijker dingen als impuls, snelheid en dergelijke kan berekenen mbv massa/volume/traagheidsmomenten die naar mijn idee eenvoudiger te bepalen zijn.

[.oisyn]

Verwijderd schreef op 07 januari 2004 @ 14:43:
Verticale beeldlijnen... huh? Dit werkt dus niet als je naar links of rechts overhelt? Of van boven naar het landschap kijkt?

idd, dat was hoe ze "vroeger" gerenderd werden (remember de mars demo? Ik heb hier ook nog zoiets liggen, ooit gemaakt in DJGPP, wil ik wel online zetten evt.). Geen idee wat ze tegenwoordig doen, maar als ik de screens van deltaforce bekijk dan is de camera-oriëntatie altijd horizontaal (net als in de oude spellen als Comanche). Maar daar is imho wel wat aan te doen met een paar hacks

.edit: http://www.xs4all.nl/~oisyn/files/foxel.exe
vrij oud demootje wat ik ooit heb gemaakt. Zie trouwens hoe ik de verkeerde z-waarden gebruikt heb. Ik gebruikte namelijk de afstand van het huidige punt in het landschap tot de viewer (feitelijk gebruikte ik de vector (cos(angle), sin(angle)) om te scannen, en verhoogde ik z steeds met 1 Vandaar dat als je naar links kijkt, het beeld puur lijkt te scrollen, je krijgt dus geen perspectief verstoring zoals dat in de werkelijkheid zou gebeuren

[ Voor 30% gewijzigd door .oisyn op 07-01-2004 15:00 ]

[Verwijderd]

OpifexMaximus schreef op 07 januari 2004 @ 14:53:
Waarom is dynamica moeilijker te gebruiken met voxels? Je zou namelijk denken dat je makkelijker dingen als impuls, snelheid en dergelijke kan berekenen mbv massa/volume/traagheidsmomenten die naar mijn idee eenvoudiger te bepalen zijn.

In theorie wel ja. Dan zou je elke voxel zijn eigen massa geven, bindingen, impuls, versnelling. Een molekulaire simulatie.
Maar dan krijg je meer particle physics dan voxels. Dit wordt al gebruikt om bijvoorbeeld een fontein van deeltjes te simuleren. Particles hebben een reele x,y en z coordinaat, die voxels moeten op een plek in de discrete kubus matrix geplaatst worden. Een verschil dus. (en geeft een stuk 'statischer' effecten)

[Soultaker]

.oisyn schreef op 07 januari 2004 @ 14:52:
nee, het gebruik van bounding boxes om volume weer te geven
Ik neem aan dat je dat grafisch bedoelt, en niet voor bij dingen als in je collision detection e.d. (want dan is het natuurlijk logisch, maar dat is ook nog steeds het geval bij voxels)

Oh, dat. Ik bedoelde wél het gebruik van bounding boxes bij collission detection en dergelijke. Ik begon al met het stellen dat voor een realistisch model van de wereld je iets van natuurkundige wetten moet hebben. In een op polygonen gebaseerde wereld is dat vervelend op dat je geen echte materie hebt en dus moet je allerlei hacks verzinnen zoals bounding volumes die een beetje aangeven wat het volume van een object ongeveer is (en waar je dingen als het zwaartepunt moet vinden).

In theorie kun je natuurlijk ook wel clipping en collision detection op polygonen alleen doen maar dat is nauwelijks praktisch te noemen (en dan nog werk je meestal alleen met de 'schil' van polygonen en niet met het impliciete volume van een object).

[Sanity11]

En hoever zijn we tegenwoordig al met realisme denken jullie? En dan heb ik het alleen over het grafische gedeelte van een game. Moeten we echt al denken dat wel de top aan berijken zijn of dat nog lang niet?

[.oisyn]

Maar collision detection op voxels is ronduit evil, en bovendien erg traag. Tenzij je puur gaat voor een detectie natuurlijk, maar dan nog. Overigens zijn tegenwoordig wel veel collision detection routines uiteindelijk polygoon-polygoon hoor, of iig een versimpeld polygonaal model van wat je ziet. Bounding volumes worden natuurlijk nog steeds gebruikt om early-out tests te doen

En in principe zijn CSG volumes wel solid (hence de S ), dus daar zijn niet per se voxels voor nodig

[curry684]

Verwijderd schreef op 07 januari 2004 @ 14:43:
Verticale beeldlijnen... huh? Dit werkt dus niet als je naar links of rechts overhelt? Of van boven naar het landschap kijkt?

Voxels zijn per definitie height-map based, en dus alleen geschikt voor horizontale hoogteverschillen. Dat dekt echter het concept 'landschappen' perfect af. Vroegah werden ze per verticale beeldlijn gerenderd omdat de CPU daarmee enorm ontlast werd: ik heb het hier echter over de tijd van de 7.14Mhz Amiga 500 zonder FPU die op die manier een 320x240 50fps voxellandscape perfect realtime kon renderen. Tegenwoordig heb je CPU's die letterlijk 1000 keer sneller zijn op integer-werk, en 5000 keer op floating point werk, en dan kun je dus met verdomd simpel rekenwerk die verticale beeldlijnen kantelen zodat je full-3D werelden eruit kunt trekken. De CPU voelt het ook niet zo hard omdat je rendert richting een grafische kaart die juist perfect geschikt is om die 3D-translations te maken. Moderne voxel-engines maken dan ook geen problemen van kantelen en omhoog/omlaag kijken.

Wat betreft realisme van karakters e.d.: voxels gebruiken voor meer dan het landschap zelf is gewoon stupide. Alle niet-landscape objecten moet je gewoon als meshes ertussen renderen.

[Soultaker]

Tja, hoe bepaal je realisme in een percentage? Ik vind mensen in spelletjes nog nergens op lijken, eerlijk gezegd. Landschappen en gebouwen en dergelijke gaan al heel aardig, maar het verschil met filmbeelden is meestal nog steeds goed merkbaar. Sommige spellen hebben daar meer last van dan anderen; realistische racespellen zien er naar mijn mening heel goed uit.

Het wordt pas echt wat als de spelwereld eruit ziet alsof het een film is. Daarvoor is echter meer nodig dan het grafische deel alleen; een groot deel van realisme komt ook van het realistisch gedrag van objecten in de wereld.

.oisyn schreef op 07 januari 2004 @ 15:03:En in principe zijn CSG volumes wel solid (hence de S ), dus daar zijn niet per se voxels voor nodig

Maar voor zover ik weet bestaan er geen algoritmen om CSG objecten te renderen. Die moeten dan eerst omgezet worden naar een polygoon- of voxelrepresentatie. Het tweede is vermoedelijk makkelijker, maar ook lomper (en mogelijk minder nauwkeurig, als er gebogen vlakken en dergelijke bij komen kijken).

[ Voor 31% gewijzigd door Soultaker op 07-01-2004 15:08 ]

[.oisyn]

Sanity11 schreef op 07 januari 2004 @ 15:02:
En hoever zijn we tegenwoordig al met realisme denken jullie? En dan heb ik het alleen over het grafische gedeelte van een game. Moeten we echt al denken dat wel de top aan berijken zijn of dat nog lang niet?

top zullen we nooit bereiken, en realisme is ook geen goed streven. Realistisch blijkt namelijk niet realistisch in games

Als een game het realisme benadert, dan ga je je als speler veel meer ergeren aan dingen die niet kloppen, terwijl als een game totaal niet realistisch is je daar helemaal geen ergen in hebt.
Ook hebben we bepaalde verwachtingen. Als we iets in het echt zien dan gaan we er gelijk vanuit dat het klopt. Als we echter weten dat een beeld gegenereerd is dan gaan we op zoek naar fouten. Soms zie je wel eens van die realistische renders van bepaalde 3d paketten, en dan zie je hoe het licht soms raar valt. Aanvankelijk denk je dat het niet klopt, maar als je dezelfde situatie in het echt nabootst dan zie je dat het wel degelijk klopt.

Realisme is dus een vrij relatief begrip, en ik denk dat je sowieso niet die kant op moet gaan in games

[.oisyn]

curry684 schreef op 07 januari 2004 @ 15:04:
De CPU voelt het ook niet zo hard omdat je rendert richting een grafische kaart die juist perfect geschikt is om die 3D-translations te maken. Moderne voxel-engines maken dan ook geen problemen van kantelen en omhoog/omlaag kijken.

Als je zelf rendert naar je video device (de framebuffer), dan zul je alle transformaties zelf moeten doen. Het is niet zo dat je videokaart een zooi dingen voor je kan transformeren, en dat jij daar dan weer mee verder kunt. De AGP bus is ervoor bedoelt om snel te zijn voor data van CPU naar videokaart, niet andersom

[Verwijderd]

Zoals ik eerder al zei, als je rechtstreeks gaat renderen naar de framebuffer dan gooi je alle mogelijke optimalisaties van je hardware weg..

[.oisyn]

Soultaker schreef op 07 januari 2004 @ 15:05:
Maar voor zover ik weet bestaan er geen algoritmen om CSG objecten te renderen. Die moeten dan eerst omgezet worden naar een polygoon- of voxelrepresentatie. Het tweede is vermoedelijk makkelijker, maar ook lomper (en mogelijk minder nauwkeurig, als er gebogen vlakken en dergelijke bij komen kijken).

CSG volumes zijn heel makkelijk om te zetten naar polygonen. Dit doen de levelcompilers van quake en unreal bijvoorbeeld Maar het is sowieso handig om aparte representaties van je object te hebben in view-space en in collision-space, om het zo maar even te noemen. Dat zul je met voxels ook hebben

[.oisyn]

wumpus: ik had trouwens mijn post nog geedit, misschien dat je er overheen hebt gelezen:

.oisyn schreef op 07 januari 2004 @ 14:55:
.edit: http://www.xs4all.nl/~oisyn/files/foxel.exe
vrij oud demootje wat ik ooit heb gemaakt. Zie trouwens hoe ik de verkeerde z-waarden gebruikt heb. Ik gebruikte namelijk de afstand van het huidige punt in het landschap tot de viewer (feitelijk gebruikte ik de vector (cos(angle), sin(angle)) om te scannen, en verhoogde ik z steeds met 1 Vandaar dat als je naar links kijkt, het beeld puur lijkt te scrollen, je krijgt dus geen perspectief verstoring zoals dat in de werkelijkheid zou gebeuren

geeft een idee hoe het in elkaar steekt

[curry684]

Voxel landscape in OpenGL:


Zelfde test-engine (!) verder uitwerkt:


Complete tutorial @ FlipCode

Voorbeeldcode andere tutorial

Nog een leuke demo:


Continous Level of Detail Terrain Meshing <- interessante materie

[curry684]

.oisyn schreef op 07 januari 2004 @ 15:08:
[...]
Als je zelf rendert naar je video device (de framebuffer), dan zul je alle transformaties zelf moeten doen. Het is niet zo dat je videokaart een zooi dingen voor je kan transformeren, en dat jij daar dan weer mee verder kunt. De AGP bus is ervoor bedoelt om snel te zijn voor data van CPU naar videokaart, niet andersom

Je bent ook idioot als je recht naar je framebuffer gaat renderen, als je uit de heightmap-data ook gewoon direct polygonen kunt isoleren en de T&L engine al het werk kunt laten doen

[Verwijderd]

.oisyn schreef op 07 januari 2004 @ 15:17:
wumpus: ik had trouwens mijn post nog geedit, misschien dat je er overheen hebt gelezen:

Ahh even kijken

Nu begint me iets te dagen.. op die manier kan je inderdaad ook een landschap van voxels maken, al heb je in je representatie meer te maken met 'staven' van voxels dan losse voxels. Met behulp van een plasma fractal kon je op die manier grappige landschappen maken inderdaad.
Dat was heel mooi in de tijd dat je elke pixel zelf moest pushen naar de kaart. Of het nog hedendaagse toepassingen heeft weet ik niet

curry684: dat is zo duidelijk een mesh! zie die driehoekjes.. dat zijn polygons, geen voxels!

[ Voor 12% gewijzigd door Verwijderd op 07-01-2004 15:24 ]

[Soultaker]

curry684 schreef op 07 januari 2004 @ 15:17:
Voxel landscape in OpenGL:
[afbeelding]

Hmm, is dit niet gewoon ray casting op een height map? Ik zie de voxels er niet echt in terug.

Verwijderd schreef op 07 januari 2004 @ 15:23:
curry684: dat is zo duidelijk een mesh! zie die driehoekjes.. dat zijn polygons, geen voxels!

Dat is dan weer wat kort door de bocht; het is geen polygon mesh die gerenderd wordt; kijk maar goed. Er worden wel (2D) triangle strips gebruikt om de scene te renderen maar de coordinaten daarvan worden (volgens de begeleinde tekst) met raycasting bepaald.

Als het terein zelf als een polygon mesh gerepresenteerd zou worden en direct gerenderd dan zouden die lijntjes tussen polygonen er heel anders uitzien. (Ik zal eens kijken of ik een voorbeeldje kan vinden).

edit:
Hier bijvoorbeeld:

De polygonen die gerenderd worden hebben als vertices de punten in de height map.

[ Voor 65% gewijzigd door Soultaker op 07-01-2004 15:28 ]

[.oisyn]

curry684 schreef op 07 januari 2004 @ 15:20:
[...]

Je bent ook idioot als je recht naar je framebuffer gaat renderen, als je uit de heightmap-data ook gewoon direct polygonen kunt isoleren en de T&L engine al het werk kunt laten doen

ja uh dan zijn het dus al geen voxels meer, maar een gewone reguliere heightmap
.edit: oh idd, ik moet mijn mening ook bijstellen

Ik vraag me af hoe deltaforce het doet, volgens mij renderen die wel gewoon naar de framebuffer (of iig naar een texture, renderen naar de frontbuffer wil niet altijd )
Zie een screenshot die ik hier postte: [rml].oisyn in "[ disc] Voxels: sleutel tot realisme?"[/rml]
Dat zijn duidelijk geen polygonen

[ Voor 34% gewijzigd door .oisyn op 07-01-2004 15:34 ]

[Verwijderd]

Het is inderdaad geen 3d mesh, dat had ik verkeerd gezien..

Edit: maar als je het als 2D mesh rendered, hoe combineer je het dan bijvoorbeeld met een vliegende helicopter, die niet in dit algoritme past?

[ Voor 56% gewijzigd door Verwijderd op 07-01-2004 15:34 ]

[Soultaker]

Hmz, geen idee. Misschien kun je wel de Z-buffer vullen? (Je hebt de diepte-informatie toch al). Dan kun je daarna de helikopter er gewoon overheen renderen (zoals toch al gebruikelijk is met game engines). Of andersom natuurlijk: eerst de 3D objecten renderen met Z-buffer en daarna de info in de Z-buffer gebruiken om het landschap erachter (en waar nodig eroverheen) te renderen.

[ Voor 30% gewijzigd door Soultaker op 07-01-2004 15:38 ]

[curry684]

Soultaker schreef op 07 januari 2004 @ 15:24:
[...]
Hmm, is dit niet gewoon ray casting op een height map? Ik zie de voxels er niet echt in terug.

Vat even in 2 regels samen wat een voxel-engine meer zou zijn dan raycasting op een height map?

Dat is dan weer wat kort door de bocht; het is geen polygon mesh die gerenderd wordt; kijk maar goed. Er worden wel (2D) triangle strips gebruikt om de scene te renderen maar de coordinaten daarvan worden (volgens de begeleinde tekst) met raycasting bepaald.

Oh wacht dat doe je zelf al

[.oisyn]

Soultaker: dat kan niet zomaar, zbuffers hoeven namelijk niet per se lockable te zijn. Als ik de screens van deltaforce goed bekijk vermoed ik dat ze gewoon quads aan het tekenen zijn met de 3d hardware. Het lijkt ook een wat rommelige pixelbrei daar aan de voorkant

[Soultaker]

curry684 schreef op 07 januari 2004 @ 15:40:
Vat even in 2 regels samen wat een voxel-engine meer zou zijn dan raycasting op een height map?

In een echte voxelwereld bestaat je hele universum uit voxels (tenminste in principe). Dat zie je bijvoorbeeld in de screenshots van .oysin ook goed terug. De voxel wereld is dan veel meer dan een heightmap alleen (maar ook weer veel moeilijker te renderen).

.oisyn schreef op 07 januari 2004 @ 15:40:
Soultaker: dat kan niet zomaar, zbuffers hoeven namelijk niet per se lockable te zijn.

Lockable? Wa's dat

[ Voor 18% gewijzigd door Soultaker op 07-01-2004 15:48 ]

[Verwijderd]

.oisyn schreef op 07 januari 2004 @ 15:40:
Soultaker: dat kan niet zomaar, zbuffers hoeven namelijk niet per se lockable te zijn.

Op zich een goed idee van die z-waarden. Je hoeft ook niet percee handmatig in die buffer te schrijven (ik raad het zelfs zwaar af omdat dat vel CPU->GPU traffic per frame oplevert), er is vast wel een trucje om de GPU die dieptes te laten interpoleren.

[.oisyn]

Soultaker: dat je een pointertje kan krijgen naar de betreffende buffer op je video hardware

wumpus: niet alleen teveel traffic, maar denk eens aan de onchip caching die de gpu doet. De z-buffer wordt in de praktijk gecompressed. Als je in direct3d (in opengl kan het niet eens) een z-buffer wilt kunnen locken dan moet de hardware dat ten eerste ondersteunen, en ten tweede moet je je buffer met bepaalde flags creëren. Als je die buffer dan lockt, dan moet alles geflushed worden, wat natuurlijk zorgt voor enorme delays. Dus idd, het is behoorlijk af te raden.

Hoe bedoel je, de dieptes interpoleren? In principe kun je tegenwoordig wel veel, maar dat is pas sinds de komst van vertex en pixelshaders. Anders moet je een soort van beeldvullend mesh maken met diepte-informatie, maar dan is de methode die curry aandraagt denk ik in het algemeen een stukje makkelijker (en bovendien mooier). Als ik kijk naar de screenshots van deltaforce denk ik echt dat ze gewoon allemaal vierkantjes tekenen met de graphics hardware

[ Voor 85% gewijzigd door .oisyn op 07-01-2004 15:56 ]

[Soultaker]

.oisyn schreef op 07 januari 2004 @ 15:51:
euh, dat je een pointertje kan krijgen naar de betreffende buffer op je video hardware

Ah ok. Ik heb geen praktijkervaring op dit gebied, maar ik ging er toch stiekum een beetje vanuit dat je ook wel 2D polygonen in de Z-buffer kan tekenen, zodat de videokaart alle interpolatie kan doen (zoals wumpus al aangaf). Of is het onmogelijk om de vertices van die 2D polygonen bij het renderen een Z-waarde mee te geven?

[ Voor 11% gewijzigd door Soultaker op 07-01-2004 15:54 ]

[.oisyn]

Dat kan natuurlijk wel, zie de laatste alinea van mijn reactie hierboven. Maar dan zit je dus eerst met het pixelen van een texture, en vervolgens die texture op een beeldvullende mesh plakken met diepte-informatie. Lijkt me een beetje omslachtige methode eerlijk gezegd

[Soultaker]

Je bedoelt, laat dan direct de GPU die polygon mesh renderen en ga met de CPU wat nuttigs doen? Of ga ik dan te snel?

[curry684]

Soultaker schreef op 07 januari 2004 @ 15:47:
[...]
In een echte voxelwereld bestaat je hele universum uit voxels (tenminste in principe). Dat zie je bijvoorbeeld in de screenshots van .oysin ook goed terug. De voxel wereld is dan veel meer dan een heightmap alleen (maar ook weer veel moeilijker te renderen).

Voxels lenen zich niet voor bomen, meshes lenen zich niet voor hele provincies. Combineer en profiteer, render de heightmaps middels raycasting eenvoudig naar polygon strips, en terwijl je dat aan het doen bent heb je een mooie voortschrijdende afstand vanaf de camera..... waarmee je perfect op het goede moment de presorted objecten die zich in je frustum bevinden ertussen kunt renderen.

* curry684 vraagt zich nog steeds af welk boek/artikel hier nu zo interessant over was, want ik heb hier echt fantastische materie over gelezen en die kan ik niet terug vinden

Iig nog hele interessante site met leuke screenshots: http://www.base-sixteen.com/terraVox/Shots.shtml

4.5FPS op een P2, maar okee ondertussen zijn grafische kaarten en CPU's 10 keer sneller gelukkig

[ Voor 10% gewijzigd door curry684 op 07-01-2004 16:15 ]

[.oisyn]

curry684 schreef op 07 januari 2004 @ 15:17:
Nog een leuke demo:
[afbeelding]

dit heeft trouwens niets met voxels te maken, dat is gewoon het renderen van een heightmap met adaptive tesselation.
Dat is wat ik hier ook doe

.edit: NEEE GVD ##$@$@#
had een hele lange reactie gepost, maar nog niet op gesubmit geklikt. Toen ging ik de laatste reacties nog een keer doorlezen, en toen quotte ik curry. Post weg

note to self: keylogger bouwen

[ Voor 21% gewijzigd door .oisyn op 07-01-2004 16:17 ]

[-=bas=-]

Het zal altijd wel een combinatie van methodieken blijven want niet 1 is er bijzonder geschikt voor alle mogelijke toepassingen.
Je zit ook met het feit dat hardware-support voor sommige technieken eigenlijk deze technieken op de voorgrond zet, terwijl voor sommige situaties andere technieken beter zouden voldoen (maar vanwege het ontbreken van hardware-support eigenlijk afvallen).

Zoals ik eerder al zei, als je rechtstreeks gaat renderen naar de framebuffer dan gooi je alle mogelijke optimalisaties van je hardware weg..

Sommige zaken kan je mbv de CPU echt een stuk beter omdat de videokaarten nog steeds bepaalde beperkingen hebben. Ook hier is het weer slim gebruik maken van de mogelijkheden van de videokaart-hardware in combinatie met de CPU.

[Soultaker]

offtopic:
Ik kwam er bij mijn eerste bericht achter dat React tegenwoordig wel netjes je bericht laat zien als je een heel verhaal hebt getypt en het topic ondertussen gesloten wordt; mijn eerste bericht was namelijk ook behoorlijk lang en 'vroeger' zou je het dan allemaal kwijt zijn geweest.

[Verwijderd]

_bas_ schreef op 07 januari 2004 @ 16:21:
Sommige zaken kan je mbv de CPU echt een stuk beter omdat de videokaarten nog steeds bepaalde beperkingen hebben. Ook hier is het weer slim gebruik maken van de mogelijkheden van de videokaart-hardware in combinatie met de CPU.

Die beperkingen zijn tegenwoordig wel heel klein, als je ziet dat sommige mensen zelfs al non-GPU related dingen op hun GPU draaien.
Maar ik ben het wel met je eens dat je de CPU-GPU combinatie zo slim en efficient mogelijk moet gebruiken. Maar dat betekent vaak wel 'zoveel mogelijk op de GPU'. En eigenlijk nooit 'direct naar de framebuffer schrijven'.
Direct naar de framebuffer schrijven zouden ze boeten op moeten zetten IMO

[curry684]

Verwijderd schreef op 07 januari 2004 @ 17:23:
[...]
Die beperkingen zijn tegenwoordig wel heel klein, als je ziet dat sommige mensen zelfs al non-GPU related dingen op hun GPU draaien.

Mythe en onzin. Helaas was het recente frontpage-newsitem hierover niet echt duidelijk, maar nee je kunt (voorlopig nog) geen niet-GPU-related dingen draaien op je GPU

Maar ik ben het wel met je eens dat je de CPU-GPU combinatie zo slim en efficient mogelijk moet gebruiken. Maar dat betekent vaak wel 'zoveel mogelijk op de GPU'. En eigenlijk nooit 'direct naar de framebuffer schrijven'.
Direct naar de framebuffer schrijven zouden ze boeten op moeten zetten IMO

Oh? Ik zei straks dan wel dat je idioot bent als je recht op de framebuffer schrijft om te renderen, maar er zijn tig andere redenen hoor (zoals bijvoorbeeld de Z-buffer preparen zodat ie een hard-rendered stuk niet gaat gebruiken voor polygonen, etc.)

[Verwijderd]

offtopic:
Dat is zeker geen mythe.
Met de compiler BrookGPU kan je op recente videokaarten (Radeon 9600+, NVidia ??) een soort van C programma's (met extensies voor parallelisme) draaien.
Er wordt een floating point render target gebruikt voor de tussenwaarden, parameters en uitvoer.

[.oisyn]

curry684: zoals ik in een aantal posts hierboven al aangaf is een lock op je z-buffer zo goed als niet te krijgen voor efficiente applicaties

[Infinitive]

Mythe en onzin. Helaas was het recente frontpage-newsitem hierover niet echt duidelijk, maar nee je kunt (voorlopig nog) geen niet-GPU-related dingen draaien op je GPU

Berekening van sqrt via GPU

[curry684]

Verwijderd schreef op 07 januari 2004 @ 17:37:

offtopic:
Dat is zeker geen mythe.
Met de compiler BrookGPU kan je op recente videokaarten (Radeon 9600+, NVidia ??) een soort van C programma's (met extensies voor parallelisme) draaien.
Er wordt een floating point render target gebruikt voor de tussenwaarden, parameters en uitvoer.

Lees http://www.tweakers.net/r...n=Posting&ParentID=925120 eens

.oisyn schreef op 07 januari 2004 @ 17:40:
curry684: zoals ik in een aantal posts hierboven al aangaf is een lock op je z-buffer zo goed als niet te krijgen voor efficiente applicaties

Volgens mij valt het best mee als je het maar linea recta na de BeginScene() doet, oftewel een lege buffer hebt, die prepareert zodat je de helft niet hoeft te tekenen, en dat dan terugschuift. De renderbonus weegt dan ruim af tegen de kosten.

Dit is overigens hearsay, meen ik in een boek opgepikt te hebben

[.oisyn]

curry684 schreef op 07 januari 2004 @ 20:54:
Volgens mij valt het best mee als je het maar linea recta na de BeginScene() doet, oftewel een lege buffer hebt, die prepareert zodat je de helft niet hoeft te tekenen, en dat dan terugschuift. De renderbonus weegt dan ruim af tegen de kosten.

Dit is overigens hearsay, meen ik in een boek opgepikt te hebben

moet je maar net de hardware hebben die locks op je z-buffer toelaten, want dat hoeft ook niet per se (en een device als de PowerVR/Kyro heeft niet eens een z-buffer, want dan? )

[SG]

De Grafische hardware markt heeft voor polygonen gekozen en Voxel richting links laten liggen.

Als Voxels hardware matig ondersteuned waren of 'n mix van die werelden dan was het weer een ander verhaal.

De huidige populaire methode doet het in software ook veel minder krachtig dan in hardware er is duidelijk verschil.

De Voxel engines van novalogic waren daarom wat meer CPU dependend doordat de Voxel engine een software matige oplossing is en niet in Grafische hardware wordt ondersteund.

'n GPU met T&L VS &PS engine en Programmebla Voxel Units zou lekker zijn

Ook flexible gebruik zoals 'n hybride opllossing in hardware zou gewenst zijn.
Aangezien beide hun voor en nadelen hebben zoals de ener laaste delta force game.

Gezien de PS unit steeds flexibler worden kunnen die daarvoor misschien gebruikt worden Op een of andere manier?

[ Voor 3% gewijzigd door SG op 08-01-2004 22:52 ]

[.oisyn]

allereerst, zou je wat minder vaak op enter willen rammen? Dit leest wat irritant

SuperG schreef op 08 januari 2004 @ 22:51:
De Grafische hardware markt heeft voor polygonen gekozen en Voxel richting links laten liggen. Als Voxels hardware matig ondersteuned waren of 'n mix van die werelden dan was het weer een ander verhaal.

zoals curry reeds heeft aangetoond zijn voxels ook prima hardwarematig te renderen dmv triangle strips. Het idee is dat je geen spatial subdivision oid meer nodig hebt, en dat de polygonen niet vast staan. Dat is toch essentieel anders dan dat je een vaste set poly's hebt je je gewoon draait adhv de stand van de camera, oid

Gezien de PS unit steeds flexibler worden kunnen die daarvoor misschien gebruikt worden Op een of andere manier?

Nee, met vertex en pixelshaders kun je nog altijd niet zelf bepalen waar je een pixel zet, je kunt hooguit bepalen wat voor kleur die pixel moet worden. Je zult dus moeten bepalen welke voxel bij welke pixel hoort, ipv andersom, wat niet echt te doen is.

Je kunt met een PS3 loopje waarschijnlijk wel een heightmap afscannen, maar echt snel zal het niet zijn (en vereist sowieso een texture lookup elke iteratie, dat is echt een dooddoener)

[curry684]

.oisyn schreef op 08 januari 2004 @ 22:02:
[...]


moet je maar net de hardware hebben die locks op je z-buffer toelaten, want dat hoeft ook niet per se (en een device als de PowerVR/Kyro heeft niet eens een z-buffer, want dan? )

Via DirectX kun je alle capacities waaronder 'Lock Z Buffer' opvragen

[.oisyn]

duh, wat ik bedoel is dat je daar geen game op kunt bouwen, omdat er hardware rondloopt waarbij het niet kan. En ja, dat is natuurlijk bij wel meer features van directx9 zo, maar de zbuffer moet je gewoon niet eens willen locken, dat is het hele punt wat ik duidelijk probeer te maken

(en een lockable z-buffer betekent automatisch al een uncompressed z-buffer, wat performancewise gewoon kut is)

[ Voor 17% gewijzigd door .oisyn op 09-01-2004 00:49 ]