Kommentar til XNA Drift Game

[kimla]

Tankegangen vår er å rendre i 3D, men å bruke 2D-fysikk langs x- og z-aksen som du sier datastol, antatt at z-aksen er "innover i skjermen", altså top-down 2D-fysikk. Med et lite team er det viktig å ikke ta seg vann over hodet, men litt ambisiøst burde det være. Så litt eyecandy med 3D, og god fysikk i 2D burde være en god kombinasjon. Det er dog ikke bestemt enda, og vi kan finne ut at vi går for noe enklere etterhvert.

 

Så bounding-rectangle er nok en av de få/mange måtene vi kan finne på å gjøre kollisjonstesting på. Det er også snakk om å bruke en 2D-fysikkmotor, gjerne Farseer som virker å være en voksen 2D fysikkmotor for XNA. Da får vi isåfall fysikken "gratis", noe som frigjør tid til å lage god spillbarhet.

 

Å ha synspunktet top-down kan vi en ganske tøff effekt tror jeg, men det er ingenting som tilsier at man ikke skal kunne se på bilen og landskapet fra andre vinkler. Det blir en prosess vi må gjennom for å se hva som blir best.

[GeirGrusom]

Hvis dere heller bruker linje-linje krysning, så kan objekter roteres i en vilkårlig retning og fortsatt vil kollisjoner se realistisk ut, og det er heller ikke veldig vanskelig å få til.

[South_Bridge]

Ingen dum tanke, vi er tidlig på planleggingsstadiet (alfa alfa imo ). Ser hva vi får satt i gang de nærmeste ueken

[kimla]

Hvis dere heller bruker linje-linje krysning, så kan objekter roteres i en vilkårlig retning og fortsatt vil kollisjoner se realistisk ut, og det er heller ikke veldig vanskelig å få til.

 

Mener Farseer gjør dette i sin fysikkmotor, sammen med andre mer effektgjerrige metoder. Ser også at dette må gjøres ved flatesortering i en 3D-motor jeg er med på å lage for Silverlight, så får vel litt erfaring fra det om det kommer så langt.

[GeirGrusom]

Jeg kan lage en demonstrasjon på hvordan dette kan gjøres, så kan dere ta det derifra dersom dere er interessert. Har ikke tid til å gjøre dette i dag, men i løpet av uka.

 

edit: ved hjelp av quadtree kan hastigheten for brettets kollisjonslinjer økes, og rektangel-sjekking for alle objektene så burde det fungere mer enn bra nok.

 

Hadde litt mer tid før jeg måtte dra enn jeg trodde, så jeg laget den ferdig.

Den bruker quadtree for å øke hastigheten (slik at den slipper å sjekke all linjer)

Endret 5. juni 2010 av GeirGrusom

[kimla]

Jeg kan lage en demonstrasjon på hvordan dette kan gjøres, så kan dere ta det derifra dersom dere er interessert. Har ikke tid til å gjøre dette i dag, men i løpet av uka.

 

edit: ved hjelp av quadtree kan hastigheten for brettets kollisjonslinjer økes, og rektangel-sjekking for alle objektene så burde det fungere mer enn bra nok.

 

Kunne vært veldig interessant å se kode for dette (selv om jeg alltid ønsker å gjøre sånt selv for læringsprosessen ). Ingen garanti for at vi bruker det iom. at vi kanskje skal bruke en ferdig fysikkmotor, men absolutt interessant å se på den type kode.

 

Viktig at du kommenterer mye i koden hvis du bestemmer deg for å lage noe, bare for å ha sagt det

[GeirGrusom]

Hmmm jeg har ikke kommentert alt for bra, men jeg kan forklare prinsippene:

 

Quadtree: hensikten her, er å dele opp en figur i logiske biter. Quadtreet består av n-antall med nivåer, hvor hvert nivå har 4, eller ingen undernoder. En node kan ha enten en liste med primitiver (linjer), 4 nye undernoder eller ingenting.

Det som gjør dette raskt, er at for hvert nivå, så eliminerer vi 3/4 av alle gjenværende mulighetene, og det blir derfor svært få elementer som må testes til slutt.

 

Så det det gjør, er at den henter ut boundingbox til figuren (min-maks til alle punktene) sjekker mot alle noder i treet som krysser denne boundingboxen (husk dette blir relativt få søk) og hvis en node med linjer i seg krysser boundingboksen til bilen, så sjekker den alle linjene i bilen mot alle linjene i noden. Hvis noen krysser, så setter programmet rett og slett bare velocity i revers (siden dette er en kollisjonsdemo, ikke en fysikkdemo)

2D fysikk er veldig enkelt å få til, ettersom derfra er det bare å implementere muligheten til å hente normal fra kræsjpunkt, og legge inn RK4-interpolering eller euler-interpolering, så har dere en fullt brukbar 2D fysikkmotor.

 

Teknikken er veldig simpel hvis en forstår det, og det er lett å implementere.

 

edit: flyttet filene til "Tips og triks"

https://www.diskusjon.no/index.php?showtopic=648798&view=findpost&p=15754336

Endret 5. juni 2010 av GeirGrusom

[kimla]

Morsom app GeirGrusom Og forresten mer morsomt å rygge rundt på banen enn å kjøre rett frem

 

Og ja, jeg skjønner teorien med quadtree fra før av så den er grei.

 

2D fysikk er veldig enkelt å få til, ettersom derfra er det bare å implementere muligheten til å hente normal fra kræsjpunkt, og legge inn RK4-interpolering eller euler-interpolering, så har dere en fullt brukbar 2D fysikkmotor.

 

Veeeeel, ikke helt enig med påstanden om at 2D-fysikk er veldig enkelt å få til Den type fysikk du bruker i eksempelet ditt er veldig enkelt, men når man skal ha litt mer som f. eks. riktig bruk av krefter så blir det fort noen timer med prøv og feil på alle småting man kommer over (been there, done that ).

 

Du sier man kan hente en normal fra kræsjpunkt, du mener vel å hente resultantkraften når kollisjonen inntreffer? Normalen eksisterer vel bare i 3. og 7(?). dimensjon.

 

RK4-interpolering har jeg ikke hørt om tror jeg, husker den ikke isåfall. Hva går den ut på? Og går ut fra at du mener euler-metoden når du sier euler-interpolering.

[GeirGrusom]

Morsom app GeirGrusom Og forresten mer morsomt å rygge rundt på banen enn å kjøre rett frem

 

Og ja, jeg skjønner teorien med quadtree fra før av så den er grei.

 

2D fysikk er veldig enkelt å få til, ettersom derfra er det bare å implementere muligheten til å hente normal fra kræsjpunkt, og legge inn RK4-interpolering eller euler-interpolering, så har dere en fullt brukbar 2D fysikkmotor.

 

Veeeeel, ikke helt enig med påstanden om at 2D-fysikk er veldig enkelt å få til Den type fysikk du bruker i eksempelet ditt er veldig enkelt, men når man skal ha litt mer som f. eks. riktig bruk av krefter så blir det fort noen timer med prøv og feil på alle småting man kommer over (been there, done that ).

 

Du sier man kan hente en normal fra kræsjpunkt, du mener vel å hente resultantkraften når kollisjonen inntreffer? Normalen eksisterer vel bare i 3. og 7(?). dimensjon.

 

RK4-interpolering har jeg ikke hørt om tror jeg, husker den ikke isåfall. Hva går den ut på? Og går ut fra at du mener euler-metoden når du sier euler-interpolering.

http://en.wikipedia.org/wiki/RK4

Og det er relativt simpelt. Mitt program var ikke en fysikksimulering, men kollisjonstest, så det er en del bugs og slikt fordi det var kollisjonene som var poenget ^^ Men det er ikke lang vei derifra til en komplett rigid body 2D fysikksimuerling. Å regne ut krefter og lignende er igjen relativt simpelt når du vet kræsjpunkt. Det som er vanskelig å få til skikkelig er å finne korrekt kræsjpunkt dog :/

[RAD1V]

Er prosjektet definitivt dødt?