[3d/zbuffer] lelijke randjes met zbuffer

[MisterData]

Echt een duidelijke topictitel is het niet, maar ik zal proberen het toch uit te leggen. Ik ben bezig de 3D-engine van Peter Walser (te vinden op www.idx3d.ch) te porten naar C++. Ik ben al een heel eind (dwz texturing enzo zit erin, lighting nog niet), en ik heb al wat werkend. Nou heb ik een voorbeeldje draaiend waarin ik twee 'donuts' heb gemaakt. Dat ziet er nu zo uit:



Je ziet hier duidelijk de randjes die worden veroorzaakt omdat er op die plek een hoop triangles elkaar snijden/achter elkaar liggen. De Z-buffer doet hier netjes z'n werk, maar het wordt er niet mooier op. Wie heeft er een ideetje over hoe ik dit wel mooi kan krijgen?

_{En ja, 6 FPS is niet echt veel.... maar er moet nog een hoop gebeuren}

edit:

Als er nog mensen zijn met leuke ideetjes over hoe anti-aliasing te implementeren hoor ik het ook graag

[ Voor 9% gewijzigd door MisterData op 17-02-2003 14:28 ]

[Zoijar]

is het een software zbuffer? Denk er wel aan dat je 1/z moet interpoleren dan, en niet z zelf. Je camera space is namelijk niet linear.

[.oisyn]

MisterData schreef op 17 February 2003 @ 14:25:
Nou heb ik een voorbeeldje draaiend waarin ik twee 'donuts' heb gemaakt. Dat ziet er nu zo uit:

dat noemen ze een torus
maar ik haal het niet helemaal uit het plaatje.. dat zijn er 2 door elkaar zei je?

Goed, interpoleer je 1/z waarden zoals Zoijar al aangaf? En gebruik je wel genoeg precisie voor die 1/z coordinaten? 16 bit int-waarden (65536/z dus) geven over het algemeen vrij brakke resultaten: dan krijg je bij z-waarden van rond de 400 al afrondingsfouten

Als er nog mensen zijn met leuke ideetjes over hoe anti-aliasing te implementeren hoor ik het ook graag

het makkelijkst is om het hele plaatje te renderen op een 4x zo grote resolutie, en dan downscalen door voor elke 4 pixels het gemiddelde te nemen

zie trouwens ook deze topic: [rml][ 3d] Zelf een Z-Buffer bakken (?)[/rml]
daar staat ook een hoop info in

[ Voor 7% gewijzigd door .oisyn op 17-02-2003 14:48 ]

[MPAnnihilator]

idd , z-buffer precisie vergroten lijkt mij , ...

[Soultaker]

Hoewel ik ook de donuts (ja, die dingen heten donuts, .oisyn ) niet herken, ziet het er ook voor mij uit alsof je Z-buffer niet nauwkeurig genoeg is (zoals anderen ook al opmerkten). Zet je clipping planes eens wat dichter om je mesh heen en kijk of 't dan beter gaat.

[ Voor 9% gewijzigd door Soultaker op 17-02-2003 14:56 ]

[.oisyn]

Heh, ik wilde net een verhaal gaan typen over w-coordinaten ipv z-coordinaten, blijkt dat het goed aansluit op Soultaker's post (torus, ketter! )

Het interpoleren van w-coordinaten ipv z-coordinaten is over het algemeen beter omdat de w-coordinaten altijd lopen van 0 naar 1, waarbij 0 op de near clip plane liggen en 1 op de far clip plane. Dit in tegenstelling tot z-coordinaten, die altijd uitgaan vanuit het viewpoint van de camera. Maar goed, aangezien je vermoedelijk z-coordinaten gebruikt heeft de clip-plane opmerking van Soultaker geen nut, aangezien dat niets aan de z-coordinaten verandert

[MisterData]

.oisyn schreef op 17 February 2003 @ 14:47:

[...]


dat noemen ze een torus

Hmm ik dacht altijd dat dat zo'n knoop was.... er is dus blijkbaar nog verschil tussen een torus en een torus knot

maar ik haal het niet helemaal uit het plaatje.. dat zijn er 2 door elkaar zei je?

Ja, precies hetzelfde, alleen eentje is een paar graden geroteerd over de x-as.

Goed, interpoleer je 1/z waarden zoals Zoijar al aangaf? En gebruik je wel genoeg precisie voor die 1/z coordinaten? 16 bit int-waarden (65536/z dus) geven over het algemeen vrij brakke resultaten: dan krijg je bij z-waarden van rond de 400 al afrondingsfouten.

Dan denk ik dat dat het probleem is..... ik zal er zo eens mee gaan klooien

[...]


het makkelijkst is om het hele plaatje te renderen op een 4x zo grote resolutie, en dan downscalen door voor elke 4 pixels het gemiddelde te nemen

supersampling ken ik ja... maar dat wordt zo traag

zie trouwens ook deze topic: [rml][ 3d] Zelf een Z-Buffer bakken (?)[/rml]
daar staat ook een hoop info in

Heb ik ook gelezen ja, staat zelfs in m'n bookmarks

[MisterData]

Zoijar schreef op 17 February 2003 @ 14:38:
is het een software zbuffer? Denk er wel aan dat je 1/z moet interpoleren dan, en niet z zelf. Je camera space is namelijk niet linear.

Ik snap niet helemaal wat je bedoeld.... ik sla nu gewoon z-waardes op en haal ze eruit.. Is de z kleiner dan de opgeslagen z dan wordt er niets getekend

[Zoijar]

MisterData schreef op 17 February 2003 @ 15:04:

Ik snap niet helemaal wat je bedoeld.... ik sla nu gewoon z-waardes op en haal ze eruit.. Is de z kleiner dan de opgeslagen z dan wordt er niets getekend

Maar hoe bepaal je dan de Z waarde voor een scherm pixel? Over een triangle moet je de van de hoekpunten de 1/z waarde nemen en die dan liniear interpoleren over de traingle. Als je gewoon de Z waarde neemt zoals bij x en y, dan lukt het niet (goed).

[MisterData]

Zoijar schreef op 17 February 2003 @ 15:08:
[...]


Maar hoe bepaal je dan de Z waarde voor een scherm pixel? Over een triangle moet je de van de hoekpunten de 1/z waarde nemen en die dan liniear interpoleren over de traingle. Als je gewoon de Z waarde neemt zoals bij x en y, dan lukt het niet (goed).

Ik geloof dat dat per scanline gaat.... je kunt het nakijken in de rasterizer-source, dat is duidelijker dan dat ik hier een verhaal ga typen denk ik: http://www.idx3d.ch/idx3d/source/idx3d/idx3d_Rasterizer.java

Ik vind de originele source trouwens heel vies.... maarja daarom port ik 'em ook

[Zoijar]

MisterData schreef op 17 February 2003 @ 15:11:
[...]


Ik geloof dat dat per scanline gaat.... je kunt het nakijken in de rasterizer-source, dat is duidelijker dan dat ik hier een verhaal ga typen denk ik: http://www.idx3d.ch/idx3d/source/idx3d/idx3d_Rasterizer.java

Ik vind de originele source trouwens heel vies.... maarja daarom port ik 'em ook

Nou, ik ga dat natuurlijk niet nakijken in de source

Zal wel goed zitten dan als je het port. Is wel een van de mogelijke oorzaken van "lelijke randjes". Waarschijnlijk de precisie dan.

Ok toch even gekeken. Het lijkt erop alsof dat fout zit in de source. In die 5 minuten dat ik er doorheen heb gezocht zag ik in ieder geval verbazingwekkend weinig keren 1/z

Zbuffer is ook zo gedefinieerd: int[] zBuffer; dat kan dan al nooit erg precies zijn.

[ Voor 22% gewijzigd door Zoijar op 17-02-2003 15:24 ]

[MisterData]

Nee, daarom vond ik het al zo vreemd Kan ik gewoon iedere keer dat er iets met de zbuffer wordt gedaan dat aanpassen? Heb je ergens een docje waar dat in staat (dan werk ik het zelf wel even door)?

[.oisyn]

Zoijar schreef op 17 February 2003 @ 15:15:
Zbuffer is ook zo gedefinieerd: int[] zBuffer; dat kan dan al nooit erg precies zijn.

een 32 bits z-buffer werkt prima, check ook mijn 3d applet: http://www.xs4all.nl/~oisyn/applets/homeboxx3d.html

Van die 32 bits worden er maar 30 echt gebruikt (negatieve z-waarden kan immers niet, en je kunt 2³¹ niet gebruiken voor de deling omdat dat buiten de signed int range valt, dus ik gebruik 2³⁰)

[MisterData]

.oisyn schreef op 17 februari 2003 @ 15:31:

[...]


een 32 bits z-buffer werkt prima, check ook mijn 3d applet: http://www.xs4all.nl/~oisyn/applets/homeboxx3d.html

Van die 32 bits worden er maar 30 echt gebruikt (negatieve z-waarden kan immers niet, en je kunt 2³¹ niet gebruiken voor de deling omdat dat buiten de signed int range valt, dus ik gebruik 2³⁰)

Hoe heb je dat dan geflikt? Ik had ook al ergens gelezen dat het slim is om zowel negatieve als positieve waarden te gebruiken om te zorgen dat je de zbuffer niet leeg hoeft te halen (als je in frame 1 negatieve en in frame 2 positieve waarden gebruikt)... Dat scheelt ook nog wat

[MisterData]

Zoijar schreef op 17 February 2003 @ 15:15:
[...]

Zbuffer is ook zo gedefinieerd: int[] zBuffer; dat kan dan al nooit erg precies zijn.

Wat moet ik volgens jou dan gebruiken? Volgens mij is int het snelste kwa processortijd enzo (immers een register is net zo groot als een int toch, daarom is een double en een float toch ook trager?) en .oisyn zegt hier net dat het op zich best kan

[EfBe]

In principe is de Z in 3D space lineair en een Z-buffer op basis van lineariteit kan wel degelijk, immers je kunt niet een ray afschieten vanaf een virtual punt voor het scherm, door een pixel P waarbij je een object raakt dat fysiek achter een ander object zit, maar door de projectie op die pixel terecht is gekomen. Het enige dat je moet bewerkstelligen is een Z-buffer waarbij je maximale Z in 3D space ook je maximale value kan zijn in je Z-buffer. Dus bij een interval voor Z van [0,100], en een z-buffer van 10.001 elementen, mapt 100 dus op 10.000. Die mapping zorgt voor precisievergroting. Men verschuift de mapping wel eens naar een non-lineaire schaal om meer precisie dicht bij de camera te krijgen ten koste van vertices die verder van de camera afliggen (en waarbij artifacts niet zo zichtbaar zijn, ookal omdat je dan veelal met mipmaps al niet bijster gedetailleerd bent) en 1/z is een leuke schaal daarvoor, maar nodig is het niet. Overigens gebruikt 3D hw de W-buffer techniek, al door oisyn uitgelegd.

[Wirf]

MisterData schreef op 17 februari 2003 @ 15:01:
[supersampling ken ik ja... maar dat wordt zo traag

Je kunt ook AA doen met de Acumulation buffer, maar dat is _erg_ langzaam op kaarten die dat niet ondersteunen. (mijn Geforce SDR haalt 20sec./frame met 8x AA en een simpele scene)

Ik gok het erop dat je al weet hoe een accumulation buffer werkt, maar zoniet, zet hier dan ff een berichtje, dan leg ik het nog ff kort uit.

[.oisyn]

MisterData schreef op 17 February 2003 @ 15:38:
[...]


Hoe heb je dat dan geflikt? Ik had ook al ergens gelezen dat het slim is om zowel negatieve als positieve waarden te gebruiken om te zorgen dat je de zbuffer niet leeg hoeft te halen (als je in frame 1 negatieve en in frame 2 positieve waarden gebruikt)... Dat scheelt ook nog wat

Ik interpoleer daar gewoon 2³⁰/z waarden

[ Voor 82% gewijzigd door .oisyn op 17-02-2003 15:41 ]

[EfBe]

MisterData schreef op 17 February 2003 @ 15:40:
Wat moet ik volgens jou dan gebruiken? Volgens mij is int het snelste kwa processortijd enzo (immers een register is net zo groot als een int toch, daarom is een double en een float toch ook trager?) en .oisyn zegt hier net dat het op zich best kan

Wat gebruik je nu voor je fracties? Integer artimetic voor vertices is wel aardig, maar levert veelal kieren op tussen je polys. Shift je nu de fractie de int in of kap je die er gewoon af? Waar het om gaat is dat je zorgen moet dat vertex A op Z=100.1 ook gezien wordt als zijnde liggend VOOR vertex B op Z=100.11. Als je fracties eraf jetst, dan liggen ze beide op Z=100 en krijg je crap.

[.oisyn]

EfBe schreef op 17 februari 2003 @ 15:41:
1/z is een leuke schaal daarvoor, maar nodig is het niet. Overigens gebruikt 3D hw de W-buffer techniek, al door oisyn uitgelegd.

1/z is zeker wel nodig, omdat je anders niet goed kunt interpoleren. Ok, je hebt gelijk dat als je simpelweg een straal schiet je dan gewoon de z-coordinaat van een punt kan gebruiken, en die in de z-buffer kan gooien. Maar bij het tekenen van polygonen schiet je geen stralen, je interpoleert van een bepaald punt in de 3d ruimte naar een ander punt in de 3d ruimte. Op zich ook geen probleem, maar je interpoleert scherm-coordinaten, waarbij de x en de y coordinaten dus gedeeld zijn door de z-coordineten.

Om de juiste z-coordinaten terug te krijgen op dat geinterpoleerde lijnstuk, zul je de 1/z waarden moeten interpoleren.

Natuurlijk kun je die z-coordinaten voor je ze in de z-buffer stopt weer terug zetten, maar dat is per pixel natuurlijk een enorme performance-hit, dus kun je ze net zo goed in 1/z laten staan. Immers: (a < b) == (1/a > 1/b). En die vergelijking gaat het je om, niet de actuele z-waarden

[MisterData]

Ik snap echt maar de helft van wat hier wordt gezegd..... misschien kan er iemand even met een stukje pseudo-code ofzo replyen? Dan wordt het al wat duidelijker....

En trouwens Wirf: dit is software rendered, en dus zonder gebruik van 3D-hardware Verder weet ik niet waar je het over hebt, dus als het ook voor software te gebruiken is dan mag je het wel uitleggen

[MisterData]

.oisyn schreef op 17 February 2003 @ 15:47:

[...]


1/z is zeker wel nodig, omdat je anders niet goed kunt interpoleren. Ok, je hebt gelijk dat als je simpelweg een straal schiet je dan gewoon de z-coordinaat van een punt kan gebruiken, en die in de z-buffer kan gooien. Maar bij het tekenen van polygonen schiet je geen stralen, je interpoleert van een bepaald punt in de 3d ruimte naar een ander punt in de 3d ruimte. Op zich ook geen probleem, maar je interpoleert scherm-coordinaten, waarbij de x en de y coordinaten dus gedeeld zijn door de z-coordineten.

Om de juiste z-coordinaten terug te krijgen op dat geinterpoleerde lijnstuk, zul je de 1/z waarden moeten interpoleren.

Natuurlijk kun je die z-coordinaten voor je ze in de z-buffer stopt weer terug zetten, maar dat is per pixel natuurlijk een enorme performance-hit, dus kun je ze net zo goed in 1/z laten staan. Immers: (a < b) == (1/a > 1/b). En die vergelijking gaat het je om, niet de actuele z-waarden

Dus, stel ik pas nu de rasterizer zo aan dat 'ie steeds 1/zbuffer->Get(x,y): doet, in plaats van zbuffer->Get(x,y), en dan ook zbuffer->Put(x,y,1/z), dan komt het goed?

[Wirf]

MisterData schreef op 17 February 2003 @ 15:50:
En trouwens Wirf: dit is software rendered, en dus zonder gebruik van 3D-hardware Verder weet ik niet waar je het over hebt, dus als het ook voor software te gebruiken is dan mag je het wel uitleggen

Ah ok, dan kun je ook wel een accumulation buffer in software bouwen.

een accumulation buffer werkt ongeveer zo:

1) Je cleared de accumulation buffer
for (int i = 0; i < FSAA-level; i++) {
2) je rendert de scene
3) je deelt de pixelwaardes van het gerenderde plaatje door de fsaa-level en telt dat op bij de accumulation buffer
4) je verplaatst de camera (en view-volume) met een waarde kleiner dan 1 pixel (SGI heeft een jitter.h header file met goede waardes voor AA tot 66x)
}
5) plaats wat in de accumulation buffer is op het scherm.

De Accumulation buffer heeft meestal een hogere precisie dan het renderproces zelf (40 bits per pixel is niet ongewoon zover ik weet) omdat het accumulation buffer meerdere malen gebruikt word per frame en 1 afrondingsfout kan dus grote gevolgen hebben.

Is het zo een beetje duidelijk?

[MisterData]

Wirf schreef op 17 februari 2003 @ 16:14:
[...]


Ah ok, dan kun je ook wel een accumulation buffer in software bouwen.

een accumulation buffer werkt ongeveer zo:

1) Je cleared de accumulation buffer
for (int i = 0; i < FSAA-level; i++) {
2) je rendert de scene
3) je deelt de pixelwaardes van het gerenderde plaatje door de fsaa-level en telt dat op bij de accumulation buffer
4) je verplaatst de camera (en view-volume) met een waarde kleiner dan 1 pixel (SGI heeft een jitter.h header file met goede waardes voor AA tot 66x)
}
5) plaats wat in de accumulation buffer is op het scherm.

De Accumulation buffer heeft meestal een hogere precisie dan het renderproces zelf (40 bits per pixel is niet ongewoon zover ik weet) omdat het accumulation buffer meerdere malen gebruikt word per frame en 1 afrondingsfout kan dus grote gevolgen hebben.

Is het zo een beetje duidelijk?

Als ik dit zo lees dan is het ongeveer het volgende:
• Render 4x (of meer) per frame, steeds met een iets andere camerapositie
• Pixelwaardes worden opgeslagen en na de 4 renders gemiddeld

Eerlijk gezegd denk ik dat dit nogal traag wordt

[Wirf]

MisterData schreef op 17 februari 2003 @ 16:17:
Als ik dit zo lees dan is het ongeveer het volgende:
• Render 4x (of meer) per frame, steeds met een iets andere camerapositie
• Pixelwaardes worden opgeslagen en na de 4 renders gemiddeld

klopt

Eerlijk gezegd denk ik dat dit nogal traag wordt

Daarom is het ook fijn als je er hardware ondersteuning voor hebt

Anti-aliasing is hoe je het went of keert een traag proces.

[EfBe]

.oisyn schreef op 17 February 2003 @ 15:47:
1/z is zeker wel nodig, omdat je anders niet goed kunt interpoleren. Ok, je hebt gelijk dat als je simpelweg een straal schiet je dan gewoon de z-coordinaat van een punt kan gebruiken, en die in de z-buffer kan gooien. Maar bij het tekenen van polygonen schiet je geen stralen, je interpoleert van een bepaald punt in de 3d ruimte naar een ander punt in de 3d ruimte. Op zich ook geen probleem, maar je interpoleert scherm-coordinaten, waarbij de x en de y coordinaten dus gedeeld zijn door de z-coordineten.
Om de juiste z-coordinaten terug te krijgen op dat geinterpoleerde lijnstuk, zul je de 1/z waarden moeten interpoleren.

Oja natuurlijk Helemaal niet bij stilgestaan, idd bij het fillen van die polys zit je met interpolated X, Y en Z's en niet met 3D space coords. Dan heb je idd alleen maar wat aan een Zbuffer vol met 1/z values. Ik zat nog met mn hoofd bij OpenGL, maar dat is dom natuurlijk, want daar wordt de z-buffer al voor je geregeld

[Zoijar]

.oisyn schreef op 17 februari 2003 @ 15:47:
Natuurlijk kun je die z-coordinaten voor je ze in de z-buffer stopt weer terug zetten, maar dat is per pixel natuurlijk een enorme performance-hit, dus kun je ze net zo goed in 1/z laten staan. Immers: (a < b) == (1/a > 1/b). En die vergelijking gaat het je om, niet de actuele z-waarden

Precies. En vandaar dat perspective correct texture mapping ook zo "duur" is in software. Daar heb je namelijk WEL de "echte" u,v waardes nodig, dus moet je voor elke pixel die die deling maken. Quake was een van de eerste engines die dit deed, mbv het overlappen van de FPU div instructie en CPU ops om de triangle te tekenen.

Overigens geldt dit dus niet alleen voor de z-buffer, maar voor alles wat lineair is in de ruimte en je interpoleert in scherm coordinaten. Dus texture mapping, gouraud shading, etc.

Het is ook wel logisch als je bedenkt dat je de coordinaten x/z en y/z interpoleert. Verder is die 'w' in homogene coordinaten die hardware interpoleert eigenlijk min of meer hetzelfde als 1/z; maar daar ga ik nu niet op in.

[EfBe]

Over Quake's software renderer: http://www.bluesnews.com/abrash/abrash.pdf(artikel van Mike Abrash, een van de techneuten achter de Quake 3D engine en nu werkzaam bij MS). Wel erg leuk om te lezen hoe ze echt alles uitgeknepen hebben voor die ene extra frame Vooral de texten over spans

[ Voor 10% gewijzigd door EfBe op 17-02-2003 17:31 ]

[.oisyn]

Zoijar schreef op 17 February 2003 @ 17:17:
Precies. En vandaar dat perspective correct texture mapping ook zo "duur" is in software. Daar heb je namelijk WEL de "echte" u,v waardes nodig, dus moet je voor elke pixel die die deling maken. Quake was een van de eerste engines die dit deed, mbv het overlappen van de FPU div instructie en CPU ops om de triangle te tekenen.

let wel dat quake standaard een subdivision scheme toepaste, waarbij de perspective correction om de 16 pixels werd gedaan (kon je instellen door r_subdiv16 op 1 of 0 te zetten als ik me niet vergis), en daartussen werd wel lineair geinterpoleerd.

Maar idd, met die subdivision uit was het nog retesnel

[MisterData]

Nou volg ik het helemaal niet meer..... kan iemand even antwoorden op de vraag die ik hierboven stelde?

[EfBe]

MisterData schreef op 17 February 2003 @ 18:40:
Nou volg ik het helemaal niet meer..... kan iemand even antwoorden op de vraag die ik hierboven stelde?

Lees die pdf eens door die ik gelinkt heb. Abrash legt het heel simpel uit mbt zbuffer. hij gaat ook dieper in op optimalisaties die mogelijk zijn op dat thema, zoals spans, maar dat is wel heel erg advanced

[MisterData]

Maar dat probleem van die randjes is dus op te lossen door 1/z te gebruiken?

[EfBe]

krek

[.oisyn]

MisterData schreef op 18 februari 2003 @ 08:10:
Maar dat probleem van die randjes is dus op te lossen door 1/z te gebruiken?

uhm, dat stond dus al in de 1e reactie van deze thread

[MisterData]

EfBe schreef op 18 februari 2003 @ 08:58:
krek

Bedankt voor deze nuttige bijdrage

.oisyn schreef op 18 februari 2003 @ 10:00:

[...]


uhm, dat stond dus al in de 1e reactie van deze thread

Ja, maar het was mij niet echt duidelijk of dat nou de goede manier was of niet Ik ga het iig proberen.