[Alg] Hoe werkt projectie 3D op 2D?

[Verwijderd]

Ik zou een kleine 3D engine willen bouwen voor wat primitieven.

Weet er iemand goede sites waar men aandacht schenkt aan het wiskundig aspect van projectie, alsook eventuele code?

Zelf heb ik een hoop sites gevonden, maar die gaan meestal over matrix transformaties voor rotaties en dergelijke, waar ik voorlopig niet veel mee ben.


Thank You

[Verwijderd]

Hier staat iets in Java. Misschien heb je er wat aan.

http://www.thesystemis.com/napier/3d_proj/3d_v1/

Het wiskundige aspect van 3d-->2d staat 100% zeker in Getal en Ruimte (ruimtemeetkunde) voor 6vwo.

[ Voor 3% gewijzigd door Verwijderd op 04-03-2003 03:13 ]

[TaXaN]

Hier heb je een PDF'je met uitleg over de verschillende coördinatentransformaties (volgens OpenGL model). Ook de matrices voor rotatie en translatie en dergelijke staan erin.
Zou je flink op weg moeten helpen voor je kleine engine (en ik spreek uit ervaring want dit was zowat het enige wat wij kregen voor ons practicum voor het vak Computergraphics")

[Knutselsmurf]

Verwijderd schreef op 04 maart 2003 @ 03:01:
Ik zou een kleine 3D engine willen bouwen voor wat primitieven.

Weet er iemand goede sites waar men aandacht schenkt aan het wiskundig aspect van projectie, alsook eventuele code?

Zelf heb ik een hoop sites gevonden, maar die gaan meestal over matrix transformaties voor rotaties en dergelijke, waar ik voorlopig niet veel mee ben.


Thank You

Ik ben bang dat je je toch in die matrix-transformaties zult moeten verdiepen. Dat is namelijk wel de basis van een 3D-engine. Zolang je in het achterhoofd houdt dat het slechts een notatie-afspraak is, omdat wiskundigen van nature lui zijn. Probeer dus eerst toch die matrices te begrijpen. Iets anders zul je eigenlijk nooit aantreffen.

[PipoDeClown]

code is te vinden op http://sf.net

[Ganja-Cape]

Hier heb je een Tutorial van Peroxide, deze tutorial legt de basis uit (zonder matrix math). Bevat ook source voor Turbo Pascal

[beany]

Ondanks dat ze zich voornamelijk bezig houden met het ontwikkelen van spelletjes, komt een 3D engine ook uitgebreid aan bod, omdat dit een essentieel onderdeel is van de meeste spelletjes:

www.gamedev.net
www.flipcode.com

Hier zijn bergen tutorials te vinden, ook over matrices die onmisbaar zijn voor een 3D engine!

Misschien dat het interessant is om naar OpenGL of DirectX te kijken? Ook al wordt het een kleine engine, het kan toch interessant zijn.

Bekijk ook de forums van die 2 sites, daar worden vele vragen beantwoord!

[Nexopheus]

zie ook [rml][ 2D theorie] rotatie figuur X en Y as[/rml]
gaat op een gegeven moment ook over 3D!

[Janoz]

Knutselsmurf schreef op 04 March 2003 @ 03:23:
[...]

Ik ben bang dat je je toch in die matrix-transformaties zult moeten verdiepen. Dat is namelijk wel de basis van een 3D-engine. Zolang je in het achterhoofd houdt dat het slechts een notatie-afspraak is, omdat wiskundigen van nature lui zijn. Probeer dus eerst toch die matrices te begrijpen. Iets anders zul je eigenlijk nooit aantreffen.

de matrix an sich is niet de basis van een 3d-engine. Het is slechts een (hele sterke) optimalisatie.

Hier ( [rml]Janoz in "[ 3d] Zelf een Z-Buffer bakken (?)"[/rml] ) heb ik ff wat dingen over 3d transformaties uitgelegd en geef ik ook aan waarom een matrix hiervoor gebruikt word.

ff terugkomen op topic titel

Het projecteren van 3D op 2D kan op vele manieren. De meest simpele is gewoon het negeren van de z coordinaat (behalve bij occlusion natuurlijk. Iets wat verder weg is staat wel achter iets dat dichterbij is ). Dat klinkt misschien wat suf, maar voor mijn laatste project heb ik het ook gebruikt. Hierdoor kun je namelijk veel makkelijker aannames maken. In mijn laatste project ging het om een direct volume renderer (je hebt N³ aan data, zet het maar op het scherm). Doordat geen perspectief gebruikt werd werd elk databunt op dezelfde oppervlakte afgebeeld waardoor ik dezelfde footprint kon gebruiken (voor meer info, hoofdstuk 3)

Maar wat jij waarschijnlijk wilt is een perspectief correcte projectie. Persoonlijk vond ik het heel handig om het ff uit te tekenen op een papiertje. Gewoon vanaf de zijkant er ff tegenaan kijken. Aan het ene uiteinde teken je je oog en aan het andere uiteinde je object. Vervolgens teken je in het midden een verticale lijn die het beeldvlak voor moet stellen. Door nu een lijn van de hoekpunten van het object naar je oog te tekenen zie je precies waar de punten op het beeld terecht zouden moeten komen. Vervolgens is met een beetje ruimte meetkunde (d'r zitten een heleboel gelijkvormige driehoeken in!) zo uitterekenen hoe de positie op het scherm afhangt van de positie in de ruimte (en de positie van je oog).

[MisterData]

Als je van 3D naar 2D wilt transformeren, dan ben je waarschijnlijk het beste af met zogenaamde 'matrices'. Een matrix is eigenlijk een soort tabelletje met waarden erin die beschrijven hoe je een 3d object wilt roteren/schalen/verschuiven. Door die matrix te vermenigvuldigen met een 'vector' die de positie van dit object aangeeft kom je aan de scherm x- en y- coordinaten (en een z-coordinaat voor de z-buffer). Je zou eens kunnen kijken in de source van deze software 3d engine (ik ben em zelf aan het porten naar C++, origineel is Java). Hierin is alles vrij overzichtelijk geordend. Kijk vooral naar de files idx3d_Vertex.java en idX3d_Triangle (en eventueel idx3d_Object en Scene). Als je hier je wat in verdiept dan zul je zien dat in deze engine matrices met elkaar worden vermenigvuldigd (dus stel, je zegt roteer object A met 90 graden, en je zegt roteer de hele scene met 90 graden,dan zal object B 90graden zijn gedraaid en object A 180, omdat je de scene matrix met de object matrix kunt vermenigvuldigen)

Duidelijk zo?


Kijk anders ook even hier: http://tfpsly.planet-d.net/Docs/3dIca/3dica.htm . Deze tut is echt geweldig, er wordt stap voor stap uitgelegd hoe matrices en vectoren werken en aan het einde kun je zelf phong-shading doen maar begin maar es bij hoofdstuk 1

[ Voor 12% gewijzigd door MisterData op 04-03-2003 12:17 ]

[.oisyn]

in plaats van te kijken naar matrices die een perspective transormatie voor je doen is het misschien handiger als je kijkt naar wat die transformatie precies is. Anders snap je er nog niets van

[Janoz]

.oisyn schreef op 04 maart 2003 @ 12:22:
in plaats van te kijken naar matrices die een perspective transormatie voor je doen is het misschien handiger als je kijkt naar wat die transformatie precies is. Anders snap je er nog niets van

Dat zeg ik ..

[.oisyn]

in je hok jij, ik reageerde op MisterData

[Sponge]

Overigens staan in de DirectX7-8 SDK documentation ook erg veel van transformation pipelines tot matrices, tot clipping (alles ongeveer )


Deze docs zijn volgens mij te vinden op http://msdn.microsoft.com/directx

[Tomatoman]

Jouw vraag is ongeveer: 'ik wil een auto gaan bouwen. Kan iemand mij uitleggen hoe ik een motor bouw?'

Ik ben bang dat jouw ambities een beetje te hoog gegrepen zijn. Een kleine 3D engine schrijven is nauwelijks mogelijk, maar wat is er op tegen om een bestaande engine te bouwen? Dan hoef je het wiel niet opnieuw uit te vinden en het bespaart je bovendien een paar duizend uur werk.

[.oisyn]

tomatoman: ben ik het niet mee eens. Waarom kan het niet interessant zijn om te onderzoeken hoe een engine werkt? Ik vind het "het wiel opnieuw uitvinden"-argument sowieso meestal een non-argument. Natuurlijk is iemand je al voorgeweest, maar dat betekent nog niet dat je er niet van kunt leren als je het nadoet, of dat het dan niet interessant is.

Bovendien is een "3d engine" bouwen met een beetje kennis van zake ook niet echt supermoeilijk ofzo

[Verwijderd]

x2d=(x3d*p)/(Z3d+p)+0.5*schermbreedte
y2d=(y3d*p)/(Z3d+p)+0.5*schermhoogte

en p is je perspectief verhouding, neem iets van 128 ofzo, kun je met shifts vemenigvuldigen.

Kheb vroeger een aantel 3d engines gebouwd in asm en eentijdje geleden 1tje in c++ met openGL, OpenGL regelt trouwens het omzetten van 3d naar 2d automatisch.

[.oisyn]

jona: dat geldt alleen als de hoogte en breedte van je view gelijk zijn, anders krijg je een vertekening in perspectief. Overigens is berekening wel krom. Normaal is dit:

x' = f * x / z
y' = f * y / z

Waarbij f de field of view factor is. Deze waarde is gelijk aan tan (FOV/2), waarbij FOV natuurlijk de hoek van de field of view is. Bij een fov van 90 graden is f dus 0.5

Let wel dat dit view space coordinaten oplevert die tussen -1 en 1 liggen. Die moet je dus nog vermenigvuldigen met de helft van de breedte of hoogte van je view in pixels.

[Verwijderd]

.oisyn schreef op 05 maart 2003 @ 16:20:
jona: dat geldt alleen als de hoogte en breedte van je view gelijk zijn, anders krijg je een vertekening in perspectief. Overigens is berekening wel krom. Normaal is dit:

x' = f * x / z
y' = f * y / z

Waarbij f de field of view factor is. Deze waarde is gelijk aan tan (FOV/2), waarbij FOV natuurlijk de hoek van de field of view is. Bij een fov van 90 graden is f dus 0.5

Let wel dat dit view space coordinaten oplevert die tussen -1 en 1 liggen. Die moet je dus nog vermenigvuldigen met de helft van de breedte of hoogte van je view in pixels.

nee, die +p in (z+p) hoort er wel degelijk bij (ook al zie je het verschiel niet echt), en wel hierdoor


--------------|----------------------Vy
--------------|----------------------
--------------q---------------------
--------------|----------------------
c-------------s---------------------vZ

c=je oog
s=scherm (stel hier even een vertikale lijn voor)
Vy=Y coord van de vertex
Vz=Z coord van de vertex

q=snijpunt lijn c-Vy (en is de 2d coordinaat)

afstand tussen c en s is p

c-vy-vz en c-q-s zijn 2 3hoeken met gelijke verhoudingen dus kun je dit stellen:

q/Vy=p/(vZ+p)

and aangezien je q wilt weten schrijf je em om naar

q=(P*Vy)/(vZ+p)

en aangezien het midden van je scherm als middelpunt wilt hebben ipv 0,0 zul je er de helft van je schermhoogte/breedte bij de x en y moeten optellen.

En die waarde ligt helemaal niet tussen 1 en -1 (wel in Open Gl maar niet als je de formule zo los gebruikt)

En nog iets, die vertekening waar je het over hebt treed zo niet op, wel als je hem zou vermenigvuldigen met de schermbreedte/hoogte zoals jij voorstelt.

[ Voor 14% gewijzigd door Verwijderd op 05-03-2003 17:07 ]

[Janoz]

Jona, als je ff kijkt naar de door .oisyn gepresenteerde formules en vervolgens naar je eigen kijkt en daar de volgende 2 dingen bij bedenkt:

- Laat z=0 nu eens niet gelijk vallen met het scherm, maar met je oog.
- Bedenk dat de afstand tot het scherm eigenlijk dezelfde functie heeft als de FOV. Alleen geeft de afstand tot het scherm de afstand tussen je oog en het scherm aan, en de FOV de hoek tussen de twee lijnen van je oog naar beide randen van het scherm. In principe is jou p hetzelfde getal als de door .oisyns gebruikte f, met het verschil dat .oisyns versie resolutie onafhankelijk is.

In principe schrijven jullie dan allebei dezelfde formule neer, met het verschil dat:
- .oisyns versie wat simpeler is en makkelijker om te zetten is in een matrix (1 bewerking)
- fov wat duidelijker is en de f dus onderbouwt is (ipv 'neem maar 128';) )
- werken van -1 naar +1 resolutie onafhankelijk is (de p van jou is dat immers wel)
- de uiteindelijke schaling naar schermresolutie niet in de perspectief berekening wordt meegenomen.

[ Voor 10% gewijzigd door Janoz op 05-03-2003 17:08 ]

[.oisyn]

jij verwart de z-coordinaat met de w-coordinaat

z is de dieptecoordinaat gezien vanaf het oogpunt, w is de afstand gezien tot de near plane

[Verwijderd]

nou vroeger in ASM werkte het prima zo Het idee van mij is idd niet resolutie onafhankelijk.

edit:

maar die van mij is wiskundig correct en die van .oisyn niet

[ Voor 33% gewijzigd door Verwijderd op 05-03-2003 17:17 ]

[Janoz]

jona, jullie formules zijn HETZELFDE!!

Het enige verschil zijn de volgende factoren

p_jona = schermbreedte * f_.oisyn

z_.oisyn = p_jona + z_jona

en het feit dat .oisyn de boel nog naar scherm posities moet schalen.

[Verwijderd]

Janoz schreef op 05 March 2003 @ 17:20:
jona, jullie formules zijn HETZELFDE!!

Het enige verschil zijn de volgende factoren

p_jona = schermbreedte * f_.oisyn

z_.oisyn = p_jona + z_jona

en het feit dat .oisyn de boel nog naar scherm posities moet schalen.

ja ik zat ook net te kijken, en idd zijn z is mij z+p

[.oisyn]

Janoz: ze zijn niet hetzelfde. Jona gaat uit dat het oorsprong op het geprojecteerde vlak ligt, die van mij dat de oorsprong op het oogpunt ligt. Boeit op zich niet, aangezien jona dat oplost door een waarde bij de z op te tellen

Immers, als het vlak op afstand 1 van het oogpunt ligt, dan is p dus 1. Een z_vlak van 0 betekent dus een z_oogpunt van 1.

Maar nu komt het: rotaties werken met het oogpunt als middelpunt, en niet het vlak waar je op projecteert. Dit heeft niet echt een zichtbaar effect, maar maakt wel uit. Neem bijvoorbeeld skyboxes, waar het van belang is dat het oog zich altijd in het midden van de skybox bevindt. Je kunt dan 6 renders doen voor elk vlak van de kubus, en dan gewoon roteren zonder dat het beeld vervormd. Als het oogpunt zich op een ander punt dan in het midden bevindt, dan vervormd de skybox, en klopt het dus niet meer.

Ook voor reflecties e.d. is het van belang uit te gaan van het oogpunt, en niet van het vlak waarop geprojecteerd wordt (dit vlak boeit helemaal niet, je kunt het in principe vrij naar voren en achteren bewegen zonder dat het geprojecteerde beeld daarop verandert)

[Janoz]

Owh.. maar we hadden het nu toch alleen nog maar over de 3d naar 2d projectie?

Zoals ik idd al zij kiezen jullie beiden een andere oorsprong en idd is het niet alleen handig om de oorsprong in het oog te leggen om efficiency redenen, maar idd ook voor al die andere dingetjes.

[Tomatoman]

.oisyn schreef op 05 March 2003 @ 13:16:
tomatoman: ben ik het niet mee eens. Waarom kan het niet interessant zijn om te onderzoeken hoe een engine werkt? Ik vind het "het wiel opnieuw uitvinden"-argument sowieso meestal een non-argument. Natuurlijk is iemand je al voorgeweest, maar dat betekent nog niet dat je er niet van kunt leren als je het nadoet, of dat het dan niet interessant is.

Dat hangt er helemaal vanaf wat je doel is. Als het erom gaat om iets te leren, ben ik het helemaal met je eens. Als het er daarentegen om gaat om productie te draaien, is het gebruik van een reeds bestaande engine de enige realistische oplossing.

Bovendien is een "3d engine" bouwen met een beetje kennis van zake ook niet echt supermoeilijk ofzo

Eens. Probleempje: de topicstarter geeft zelf aan dat hij niet zoveel kennis van zaken heeft.

gabberatski, in principe zijn er twee universele frameworks om 3D tekeningen en animaties te maken: DirectX en OpenGL. Over DirectX hebben andere posters al het een en ander gemeld. Voor OpenGL is er een uitgebreide, open-source collectie van componenten: GLScene. Er zijn voor GLScene heel veel voorbeelden, waarvan een flink aantal erg eenvoudig is. GLScene vind ik een uitstekend startpunt om de basics van 3D te leren, maar ook om geavanceerde programma's te bouwen.

[.oisyn]

tomatoman schreef op 05 March 2003 @ 17:48:
[...]
Dat hangt er helemaal vanaf wat je doel is. Als het erom gaat om iets te leren, ben ik het helemaal met je eens. Als het er daarentegen om gaat om productie te draaien, is het gebruik van een reeds bestaande engine de enige realistische oplossing.

ben ik het ook mee eens, maar de TS heeft aangegeven dat ie een kleine "3d engine" wilt bouwen, en interesse heeft in het wiskundige aspect van projectie. Dan lijkt het me niet dat ie een bestaande 3d engine nodig heeft, anders had hij daar wel naar gevraagd, of naar opengl/direct3d docs