[directx] Game design. wie beweegt? camera of wereld?

[Verwijderd]

Ik ben op dit moment de eerste stapjes aan het zetten in de wereld van geme development en kwam daarbij iets tegen waarvan ik me af vroeg wat het beste is.

In een boek die ik door aan het werken was lieten ze de wereld om de 'player' heen draaien en dus de player op (0,0,0) met de camera er stil achter. Is dit efficienter/beter dan de wereld stil laten staan en de player en camera van plaats laten veranderen?

het leek mij logischer om gewoon de wereld stil te zetten en de 'player' te laten bewegen.

[Janoz]

Waarom lijkt je dat logischer? Uiteindelijk zul je toch alles naar camera space moeten transformeren, en daarbij ligt (afhankelijk van de gekozen viewport) 0,0,0 gewoon precies in het midden van je scherm.

[.oisyn]

Wat enorm onpraktisch, en ik vraag me af of jij het wel goed interpreteert . Natuurlijk zijn het gewoon coördinatenstelsels en doet het er in essentie weinig toe welke je gebruikt. Echter, als alles relatief is aan de orientatie van de player kan je code ook geen vectoren en coordinaten etc. opslaan zonder dat elke frame te moeten transformeren. Dat is niet alleen inefficient, het is ook nog eens onhandig. World coordinates zijn statisch en dus veel beter om mee te werken.

Welk boek ben je aan het lezen als ik vragen mag?

[ Voor 4% gewijzigd door .oisyn op 02-03-2007 11:30 ]

[Janoz]

Is het niet zo dat er hier 2 dingen door elkaar gehaald worden? In principe heb je natuurlijk world space en camera space. Alle niet grafische interactie doe je uiteraard in worldspace. Verplaatsen van objecten en de interactie tussen die objecten. Bij het renderen zelf transformeer je naar camera space.

[.oisyn]

Dat bedoelde ik ook met mijn vraag of ie het niet verkeerd interpreteerde . Maar zoals ik het lees is de hele game erop gebouwd dat het relatief aan de player is (met de camera daar achter, en dus ook niet relatief aan de camera zoals je renderd)

[beany]

Ik heb het ook wel eens uitgelegd gezien dat alles om 0,0,0 heen draait met als volgende redenering:

Als persoon die zich in een wereld bevind(in het eggie, niet virtueel) draait alles om die persoon, vanuit die persoon gezien dan. Dat is zijn/haar beleving. Dus waarom dit niet in een 3D engine?

Dus dat er websites/boeken zijn die dit zo uitleggen en aanleren kan kloppen...

[Janoz]

Een erg belangrijke reden om dit niet in een 3D engine te doen is omdat de wereld om de player heen niet stil staat. Zoals .oisyn al aangeeft wordt het erg lastig om NPC door de level heen te laten wandelen. Ze bewegen tov de wereld, en niet tov de speler.

[.oisyn]

beany schreef op vrijdag 02 maart 2007 @ 11:44:
Dus dat er websites/boeken zijn die dit zo uitleggen en aanleren kan kloppen...

Dan hebben die schrijvers vrijwel geen ervaring met het schrijven van eigen 3d engines en dus kun je je afvragen hoe waardevol hun mening is bij het maken van jouw eigen game

[ Voor 4% gewijzigd door .oisyn op 02-03-2007 12:02 ]

[Verwijderd]

ik bedoelde idd puur voor het renderen. Dus idd die camera space. dat liet ik even niet duidelijk weten.

C#:

//eenmalig aanroepen:
device.Transform.View = Matrix.LookAtLH(new Vector3(0, -2f, 0.4f), new Vector3(0, 0, 0), new Vector3(0, 0, 1));

//volgende regel iedere keer aanroepen bij 'drawen' van de wereld
device.Transform.World = Matrix.Translation(-(float)playermeshposition.X, -(float)playermeshposition.Y, -(float)playermeshposition.Z) * Matrix.RotationYawPitchRoll((float)playermeshangles.X, (float)playermeshangles.Y, (float)playermeshangles.Z);            

dat is dus hoe het nu is. de andere manier die mij logisch leek was om steeds bij drawen van de player de camera te verplaatsen. dus de eerste regel met een variabele aan te passen en steeds weer uit te voeren en de translation enzo doen bij het renderen van de player

[beany]

.oisyn schreef op vrijdag 02 maart 2007 @ 12:02:
[...]

Dan hebben die schrijvers vrijwel geen ervaring met het schrijven van eigen 3d engines en dus kun je je afvragen hoe waardevol hun mening is bij het maken van jouw eigen game

Precies mijn mening. Alleen jammer dat mensen die hier aan beginnen op dit soort websites terecht komen. Ik ben er zelf ooit ook terecht gekomen, maar na wat gerotzooi en denk werk en redelijk wat 'he?' momenten geconcludeerd dat het toch niet de oplossing was. Ik hoop dat iedereen dat heeft

[Zerora]

Ik denk dat het puur afhangt van het type spel.
Bijv. bij een spel als Monkey Ball is het juist leuk element dat de wereld draait ipv het balletje. maar bijv. een schietspel is dit niet handig voor.
Daarnaast is het bewegen van een poppetje binnen de wereld veel minder zwaar (performance) dan dat je de wereld om het poppetje zou bewegen.

[.oisyn]

Verwijderd schreef op vrijdag 02 maart 2007 @ 12:04:
ik bedoelde idd puur voor het renderen. Dus idd die camera space. dat liet ik even niet duidelijk weten.

Aha, dat verklaart een hoop

C#:

//eenmalig aanroepen:
device.Transform.View = Matrix.LookAtLH(new Vector3(0, -2f, 0.4f), new Vector3(0, 0, 0), new Vector3(0, 0, 1));

//volgende regel iedere keer aanroepen bij 'drawen' van de wereld
device.Transform.World = Matrix.Translation(-(float)playermeshposition.X, -(float)playermeshposition.Y, -(float)playermeshposition.Z) * Matrix.RotationYawPitchRoll((float)playermeshangles.X, (float)playermeshangles.Y, (float)playermeshangles.Z);            

dat is dus hoe het nu is. de andere manier die mij logisch leek was om steeds bij drawen van de player de camera te verplaatsen. dus de eerste regel met een variabele aan te passen en steeds weer uit te voeren en de translation enzo doen bij het renderen van de player

Mja, zo zou ik het ook niet aanpakken. De view transformation is doorgaans voor world->view, en de world transformation is voor object->world. Op de manier zoals in jouw codevoorbeeld moet je zelf nog de object->world->player transformatie doen, terwijl een object typisch een object->world transformatie in zich heeft. Handiger is dus om die matrix gewoon als Transform.World in te stellen. De View is dan world->view, oftewel de inverse matrix van de orientatie/positie van de camera in de wereld. En die kun je weer makkelijk berekenen adhv de transformatie van de player.

Overigens is nog een nadeel van jouw methode dat de camera nogal erg vast aan de player hangt. In games beweegt hij vloeiend mee, en dit is veel makkelijker te maken door de camerapositie en orientatie in world-coordinates te hebben.

Zerora schreef op vrijdag 02 maart 2007 @ 12:07:
Daarnaast is het bewegen van een poppetje binnen de wereld veel minder zwaar (performance) dan dat je de wereld om het poppetje zou bewegen.

Onzin . Alles moet hoe dan ook getransformeerd worden, want de hardware verwacht de coordinaten in device space. En al die matrices kun je met elkaar vermenigvuldigen voordat je de vertices gaat transformeren, dus elke vert in de game wordt sowieso met 1 matrix vermenigvuldig (of meer afhankelijk van wat je verder nog wilt doen vertex shader - zoals bone skinning)

[Zerora]

.oisyn schreef op vrijdag 02 maart 2007 @ 12:17:
[...]

Onzin . Alles moet hoe dan ook getransformeerd worden, want de hardware verwacht de coordinaten in device space. En al die matrices kun je met elkaar vermenigvuldigen voordat je de vertices gaat transformeren, dus elke vert in de game wordt sowieso met 1 matrix vermenigvuldig (of meer afhankelijk van wat je verder nog wilt doen vertex shader - zoals bone skinning)

Ah ok. Ik dacht dat verplaatsen van een grote wereld om een poppetje heen juist voor zoveel rekenkracht zorgde dat het trager zou zijn, maar dat een poppetje in een wereld bewegen lichter zou zijn.

[.oisyn]

Maar denk er eens aan: stel je transformeert alleen de player en niet de wereld. Om die wereld op je scherm te renderen blijft die dan ook altijd op dezelfde plek, namelijk gezien vanuit (0, 0, 0) en recht naar voren kijkend. Maar als je echt door de wereld heen wilt lopen, dan zie je op je scherm de wereld op je af komen - dus dan wordt alles getransformeerd.

[Zerora]

Ik geloof dat ik dat transformeer verhaal niet helemaal snap. Waarvoor moet er getransformeerd worden?

[.oisyn]

Om het beeld te renderen . Stel jij hebt een polygoon op een vaste plek op de wereld. Als die heel ver van de camera is, dan is ie klein op je scherm. Als ie dichtbij de camera is, dan is ie groot op je scherm. Als je naar links kijkt, beweegt de polygoon naar rechts op je scherm. Dus de vertices van de polygoon bewegen aan de hand van de positie en orientatie van de camera. Ofwel: de vertices ondergaan een transformatie.

De hardware rendert polygonen op je scherm, daarom moeten wereldcoordinaten eerst naar schermcoordinaten omgezet worden. De view transformation (3d coordinaten relatief aan de camera), view projection (3d coordinaten worden geprojecteerd op een 2d vlak, je scherm loopt van -1 tot +1) en viewport transformation (die -1..+1 range omzetten in pixelcoordinaten) zorgen hiervoor.

[ Voor 4% gewijzigd door .oisyn op 02-03-2007 13:09 ]

[Zerora]

Ah, ok. Renderen is dus transformeren. Het verhaal wordt al duidelijker.

Dan heb ik al die tijd gewoon verkeerd gedacht en is mijn post dus eigenlijk nutteloos.

Laat maar, ik snap er niks van. sla mn post maar over

[ Voor 17% gewijzigd door Zerora op 02-03-2007 13:23 ]

[LDenninger]

Zerora schreef op vrijdag 02 maart 2007 @ 13:14:
Ah, ok. Renderen is dus transformeren. Het verhaal wordt al duidelijker.

Dan heb ik al die tijd gewoon verkeerd gedacht en is mijn post dus eigenlijk nutteloos.

Renderen is niet transformeren, maar om de wereld te kunnen renderen moet je wel de vertices transformeren


Als je niks transformeert verandert er niks.
Als je wilt dat er iets op het beeldscherm veranderd wordt, zul je iets aan de input-data moeten veranderen.
Dus verander je een matrix, en hoppa - er verandert wat op scherm.

[ Voor 22% gewijzigd door LDenninger op 02-03-2007 13:23 ]

[Not Pingu]

Zerora schreef op vrijdag 02 maart 2007 @ 13:14:
Ah, ok. Renderen is dus transformeren. Het verhaal wordt al duidelijker.

Dan heb ik al die tijd gewoon verkeerd gedacht en is mijn post dus eigenlijk nutteloos.

offtopic:
Je gebruikt in een 3D engine matrixtransformaties om lokale coordinatenstelsels te transformeren naar world coordinates.
Een model van bijv. een NPC heeft zijn eigen coordinatenstelsel en zijn eigen origin (0,0,0) binnen dat model. Doordat de positie, rotatie, schaal etc. van de NPC in de worldspace wordt onthouden, kun je dmv. matrixtransformaties alle lokale coordinaten in het model transformeren naar coordinaten in worldspace. Zo kun je meerdere instanties van hetzelfde model op verschillende plaatsen en in verschillende richtingen renderen.

[.oisyn]

LDenninger schreef op vrijdag 02 maart 2007 @ 13:21:
Dus verander je een matrix, en hoppa - er verandert wat op scherm.

Was alles maar zo simpel

[CodeCaster]

Mag ik ook vragen welk boek je aan het lezen bent? Ik heb zelf een hele tijd met DirectX8 en Visual Basic gewerkt, maar omdat toen ik e.e.a. eindelijk doorhad, DirectX9 uitkwam ben ik maar gestopt, omdat dat niet ondersteund werd door Visual Basic.

En nu ben ik binnenkort wel weer aan een programmeeruitdaging toe, dus wil ik wel C# oid leren, en dan daar bovenop DirectX9, of zelfs 10.

[Verwijderd]

ik lees nu meerdere boeken. het nadeel is dat er eigenlijk maar weinig 3d game boeken zijn met c# als basis aangezien dit nog relatief nieuw is. maar als je een beetje ervaring hebt met c# en je weet hoe google werkt kan je de c++ code voorbeelden zonder probleem implementeren in c#.

o.a.

http://www.amazon.com/Gam...oks&qid=1172843298&sr=8-1
Dit is een boek met een boel wiskunde, en gaat meer over de game physics dan het plaatje op het beeld zetten. Geen makkelijk boek maar wel uitgebreid. code voorbeelden in C++. complete grafische engine meegeleverd(Wild magic 4.0)

http://www.amazon.com/Ult...oks&qid=1172843298&sr=8-4
Dit is wat meer een basis. een leuk boek om mee te beginnen maar het is meer de onderliggende techniek dan de uitvoer ervan. ook code voorbeelden in c++. voordeel is dat deze ook wat spul bekijkt als networking en sound.

en een hoop online tutorials. en nog wat online boekjes, en online tutorials, en online naslagwerk en online.... nouja je snapt het wel.. google is your friend

[Janoz]

Verwijderd schreef op vrijdag 02 maart 2007 @ 14:58:
ik lees nu meerdere boeken. het nadeel is dat er eigenlijk maar weinig 3d game boeken zijn met c# als basis aangezien dit nog relatief nieuw is.

Over welke taal het gaat is bij 3D-engines eigenlijk helemaal niet relevant (ok, met uitzondering van OpenGL en Direct3D, maar dan hebben we het enkel over het aller achterste stapje in je hele render pipeline). Het grootste deel is pure wiskunde. Of je dit vervolgens implementeerd in C, Java, VB, Brainfuck of C# maakt eigenlijk weinig uit.

[XKB]

Een BrainFuck 3D-engine wil ik wel eens zien

[Verwijderd]

Dan is de source groter dan de .exe zelf denk ik

[Verwijderd]

Janoz schreef op vrijdag 02 maart 2007 @ 21:48:
[...]

Over welke taal het gaat is bij 3D-engines eigenlijk helemaal niet relevant (ok, met uitzondering van OpenGL en Direct3D, maar dan hebben we het enkel over het aller achterste stapje in je hele render pipeline). Het grootste deel is pure wiskunde. Of je dit vervolgens implementeerd in C, Java, VB, Brainfuck of C# maakt eigenlijk weinig uit.

idd, daarom geef ik al aan dat met een klein beetje c# ervaring het zo te implementeren is in C# ongeacht de voorbeelden.

al is het natuurlijk makkelijker om c++ voorbeelden in C# over te zetten dan brainfuck voorbeelden....
nadeel met brainfuck voorbeelden is natuurlijk ook dat je een 20000 pagina's dik boek krijgt maar lijkt me wel een uitdaging.... een volledige 3d engine brainfucken....

wie gaat de uitdaging aan? mijn brain was na hello world al genoeg gefucked... maar is wel leuk om te spelen.

[.oisyn]

Je kunt beter een gcc backend schrijven zodat je C++ code kunt compileren naar brainfuck code

[Verwijderd]

dan haal je de hele lol er vanaf......

maar ff terug naar topic.... begint er best leuk uit te zien al ik kan nu al met een doos vliegen, lopen, schieten etc.. door een landschap voornamelijk bewoond door dozen, spheres en andere standaard meshes als ik nu ook nog enigsinds goed was in modelen was hij nog mooier geweest. binnenkort maar eens wat gratis meshes van internet trekken.

en door dat k nu de transformaties wat anders aangepakt hebt gaat het een stuk makkelijker om alles physics er in te gooien. tnx voor de input.