[Alg] physics movement

[Verwijderd]

Ik ben op dit moment bezig een simpel model te maken in java voor beweging van een unit op het laagste niveau (de locomotive).

De implementatie heb ik gebaseerd op een tutorial van "autonomous agents".

Hier wordt een unit voorgesteld als
*massa: scalar
*positie: vector
*velocity: vector
*max_force:scalar
*max_speed: scalar
*richting: 2 vectors

de richting zijn twee basis vectoren. Hier wringt nu net het schoentje.

ik heb één methode: integrate(Vector steering_direction)
x>0: stuwing
x<0: remmen
y>0: rechts
y<0: links

oproepen van de methode:
unit.integrate(new Vector2D(10,0)); // ga vooruit met 10
unit.integrate(new Vector2D(0,5));// ga rechts met 5

Je hebt eigenlijk twee assenstelsels: het externe en het interne.
Positie zorgt voor een plaats op het extern assenstelsel en velocity en richting zijn vectoren die zijn gedefinieerd in het intern assenstelsel.

Nu komt de steering_direction binnen in de vorm van een lokaal assenstelsel: 0,10 bijvoorbeeld.

Dit moet dan worden geconverteerd naar de echte positie. Dit doe ik door een rotatie toe te passsen.

Wat ik eigenlijk wil bereiken is dat wanneer mijn unit 30 graden staat gedraaid, en hij moet vooruitgaan, hij in de richting gaat van die 30 graden.

Hier volgt mijn methode:

code:

public void integrate(Vector2D steering_direction ){
    //steering_direction:
    //x>0: acceleration;    x<0: brake
    //y>0: right            y<0:left

steering_direction.setX(steering_direction.getX()*Math.cos(angle)-steering_d
irection.getY()*Math.sin(angle));

steering_direction.setY(steering_direction.getX()*Math.sin(angle)+steering_d
irection.getY()*Math.cos(angle));

    //x-velocity
    double steering_force = Math.min(steering_direction.getX(),maxForce);
    double acceleration = steering_force/mass;
    velocity.setX(Math.min(velocity.getX()+acceleration,maxSpeed));

    //y-velocity
    steering_force = Math.min(steering_direction.getY(),maxForce);
    acceleration = steering_force/mass;
    velocity.setY(Math.min(velocity.getY()+acceleration,maxSpeed));

    //new position
    position.setX(position.getX()+velocity.getX());
    position.setY(position.getY()+velocity.getY());

    forward = velocity.getNormalizedVector();

    angle = forward.dotProduct(x);

    }

Voor de code te begrijpen:
forward = basis vector in local space: in de richting die hij wijst.
up of side as heb ik niet meer nodig (want die staat er toch perpendicular op??? of niet?)

forward as wordt dan opnieuw berekend aan de hand van de genormalisseerde versie van de velocity.

zoals je ziet wordt mijn hoek berekend aan de hand van het dot product tussen de huidige x-as (extern assenstelsel) en foward-as (intern assenstel):

Nu heb ik een paar vragen: ten eerste werkt de code alleen maar wanneer ik beweeg naar het vierde kwadrant toe (eerste kwadrant in comuter graphics??)

ten tweede: is dit de juiste manier om het te doen? of maak ik het weeral veel te moeilijk?

(acceleration etc werkt wel perfect).

[.oisyn]

Mja, als je het mij vraagt ben je het jezelf veel en veel te moeilijk aan het maken ja

Een object heeft 5 eigenschappen: massa (scalar), positie (punt), velocity (vector), oriëntatie (scalar in 2d, axis/angle of quaternion oid in 3d) en een draaisnelheid (eveneens scalar in 2d, axis/angle of quaternion oid in 3d). For the sake of usability nemen we even aan dat een punt ook een vector is

Dus nee, geen snelheid en richting, deze zijn namelijk inherent aan de velocity vector. Een vector zou je namelijk al kunnen zien als een combinatie van richting en snelheid (poolcoördinaten-stelsel), die 2 dingen apart nemen zou dan ook onzin zijn

Goed, eerst even de pure beweging. Eigenlijk komt dat neer op het volgende loopje:

C++:

velocity += acceleration
position += velocity

Waarbij acceleration natuurlijk ook een vector is, die je evt. haalt uit de externe krachten die op het object werken (mbv Newton's F = m*a, dus a = F/m)

Dit geldt natuurlijk ook voor de draaisnelheid

C++:

draaisnelheid += draaiacceleratie
orientatie += draaisnelheid

waarbij je de draaiacceleratie haalt uit torsie en momenten en dat soort zut. In principe komt het hier alleen maar neer op een positieve of negatieve waarde afhankelijk van of ie naar links of naar rechts gaat. De waarde die je kiest is natuurlijk wel weer afhankelijk van de massa van het object

Om de acceleratie in snelheid te nemen gebruik je gewoon een kracht in de richting van de orientatie, oftewel (f * cos (a), f * sin (a)) in 2D, waarbij f de kracht is die op het object werkt om z'n snelheid toe laten te nemen of juist af te remmen

[Verwijderd]

Ok bedankt alvast: maak niks te complex als het niet moet!

Maar ik heb toch één stap niet kunnen volgen denk ik:

Mijn invoer per iteratie is een vector (in dit vroeg stadia kan ik dit uiteraard nog veranderen) waarbij:
x>0: acceleration; x<0: brake
y>0: right y<0:left

nu doe jij: positie += acceleratie.
Maar je hebt toch x - acceleratie en y- acceleratie?
en deze komen NIET overeen met met invoer? of vergis ik mij hier?

voorbeeld:
je angle = 45 graden (schuin naar onder).

je invoer is: ga vooruit 5 positie's >> new Vector2D(5,0);

als je het gewoon bijtelt wordt x alleen verhoogd en niet y, terwijl hij eigenljk schijn naar onder moet gaan en dus zowel x als y moet worden verhoogd. Langs de andere kant als je hoek 135 graden is moet x zelfs afnemen terwijl je invoer x postief is. (new Vector 2D(5,0);

[jvdmeer]

Verwijderd schreef op 22 januari 2004 @ 19:07:
[..]

voorbeeld:
je angle = 45 graden (schuin naar onder).

je invoer is: ga vooruit 5 positie's >> new Vector2D(5,0);

als je het gewoon bijtelt wordt x alleen verhoogd en niet y, terwijl hij eigenljk schijn naar onder moet gaan en dus zowel x als y moet worden verhoogd. Langs de andere kant als je hoek 135 graden is moet x zelfs afnemen terwijl je invoer x postief is. (new Vector 2D(5,0);

Nu gebruik je in beide gevallen new Vector2D(5,0) ongeacht of de hoek 45° of 135° is. Daar zit blijkbaar een fout in.
Je kan dit op 2 manieren oplossen. Door de nieuwe Vector te voorzien van
poolcoordinaten:
• Vector2D(5,135°)
• Vector2D(5,45°).

Of je voorziet ze van (woord ontschiet me)-coordinaten:
• Vector2D(5*½√2,5*½√2) (=Vector2D(3.54,3.54) )
• Vector2D(5*½√2,-5*½√2) (=Vector2D(3.54,-3.54) )

[ Voor 21% gewijzigd door jvdmeer op 22-01-2004 19:28 ]

[.oisyn]

Verwijderd schreef op 22 januari 2004 @ 19:07:
Ok bedankt alvast: maak niks te complex als het niet moet!

Maar ik heb toch één stap niet kunnen volgen denk ik:

Mijn invoer per iteratie is een vector (in dit vroeg stadia kan ik dit uiteraard nog veranderen) waarbij:
x>0: acceleration; x<0: brake
y>0: right y<0:left

nu doe jij: positie += acceleratie.
Maar je hebt toch x - acceleratie en y- acceleratie?

dat zit toch al in de acceleratie-vector. Een vector heeft immers een x- en een y-component. En vectoren kun je bij elkaar optellen

en deze komen NIET overeen met met invoer? of vergis ik mij hier?

idd, hier gebruikte ik nog een algemene acceleratie, bijvoorbeeld gevormd door een externe kracht op het object. Lees even verder, naar het stukje onder de oriëntatie:

quote: http://gathering.tweakers...message/19804879#19804879

Om de acceleratie in snelheid te nemen gebruik je gewoon een kracht in de richting van de orientatie, oftewel (f * cos (a), f * sin (a)) in 2D, waarbij f de kracht is die op het object werkt om z'n snelheid toe laten te nemen of juist af te remmen

[ Voor 3% gewijzigd door .oisyn op 22-01-2004 19:42 ]

[Verwijderd]

Hoewel

C++:

velocity += acceleration
position += velocity

natuurlijk wel werkt ben ik er voorstander van om overal ook de tijdstap die je maakt bij te betrekken

C++:

velocity += acceleration*dt
position += velocity*dt

Dit heeft als voordeel dat je heel gemakkelijk in het SI (standaard eenheden) kan werken. Je maakt je simulatie dan ook (min of meer) onafhankelijk van de tijdstap, dus als het te schokkerig gaat, of zelfs numeriek instabiel is kan je de dt verkleinen en het gaat beter. En daarbij is het ook duidelijker dat je een euler-integratie methode gebruikt voor het (nummeriek) oplossen van de differentiaalvergelijking:
(d^2/dt^2) position = acceleration(t)

[.oisyn]

Uhm ja, ik ging idd even uit van een vaste stapgrootte. Zelf gebruik ik ook altijd variabelen stapgrootten idd

[Verwijderd]

*kick*

Het werkt nu min of meer maar ik zit met één probleempje. Het wagentje slipt eigenlijk. De richting verandert wel (angle) maar om hem in die richting te rijden moet je gaas geven. Bij een gewone auto moet je toch geen gas geven in de bochten?

ik heb volgende code reeds geschreven:

Java:

//steering_direction:
        //x>0: acceleration;    x<0: brake
        //y>0: right            y<0:left

        turningSpeed +=steering_force.getY()/mass;
        angle += turningSpeed;

        //F = m * a
        //a = F/m
        double x = (steering_force.getX())*Math.cos(angle);
        double y = (steering_force.getX())*Math.sin(angle);

        steering_force.setX(x);
        steering_force.setY(y);

        steering_force.divide(mass);

        Vector2D acceleration = steering_force;
        velocity.add(steering_force);

        velocity.add(acceleration);
        position.add(velocity);

Ik heb al verschillende dingen geprobeerd maar ik kom er niet echt uit! Wie kan mij hierbij helpen

[Opi]

Waarom druk je angle uit in m/s²? Dit horen radialen of graden te zijn.

Ik vermoed dat hierdoor de absolute waarde van je snelheid niet correct meer is.

[ Voor 38% gewijzigd door Opi op 12-02-2004 13:48 ]

[Verwijderd]

de input is:

Java:

//links
model.integrate(new Vector2D(10,-Math.PI/4));
//rechts
model.integrate(new Vector2D(10,Math.PI/4));

Dus invoer is in radialen hoor.
(bij het maken van een bocht geef ik nog gas bij, maar dit lost mijn probleem maar gedeeltelijk op: bij het klikken op het linker pijltje gaat hij een beetje in die richting maar niet helemaal)

[.oisyn]

Verwijderd schreef op 12 februari 2004 @ 13:44:
*kick*

Het werkt nu min of meer maar ik zit met één probleempje. Het wagentje slipt eigenlijk. De richting verandert wel (angle) maar om hem in die richting te rijden moet je gaas geven. Bij een gewone auto moet je toch geen gas geven in de bochten?

Het gaat precies zoals hierboven besproken is, en zoals het in het echt ook zou gaan, je hebt namelijk geen rekening gehouden met frictie. Het is nu meer alsof het object door de ruimte vliegt Hij heeft een bepaalde velocity, en daar voeg je een torsie aan toe waardoor ie gaat draaien. Maar daardoor gaat ie natuurlijk niet ineens in de andere richting verder vliegen, daarvoor heeft ie thrust nodig.

Met een auto is het echter anders, omdat de wielen met de weg wrijving hebben. Als je een auto onder een hoek van zeg 45 graden over het wegdek schuift, dan zal ie op een gegeven moment verder gaan met de vector van z'n kijkrichting geprojecteerd op z'n bewegingsrichting, omdat de wielen gaan draaien (de wielen kunnen rollen in z'n kijkrichting, en rolwrijving is vrijwel nihil. De wielen geven natuurlijk wel wrijving als ze bewegen in een richting die haaks op de rolrichting staat). En dus "stopt" ie in de huidige bewegingsrichting en "gaat ie verder" in de kijkrichting

[.oisyn]

OpifexMaximus schreef op 12 februari 2004 @ 13:47:
Waarom druk je angle uit in m/s²? Dit horen radialen of graden te zijn.

ik vraag me af waaruit je die conclusie trekt?

[Opi]

.oisyn schreef op 12 februari 2004 @ 13:56:
[...]


ik vraag me af waaruit je die conclusie trekt?

code:

turningSpeed +=steering_force.getY()/mass; [F/m = a]
        angle += turningSpeed; [a]

        //F = m * a 
        //a = F/m 
        double x = (steering_force.getX())*Math.cos(angle); [cos(a)]

Ik heb zuiver naar de eenheden gekeken, of in ieder geval, naar wat ik dacht dat de eenheden zijn, gelet op de naam van desbetreffende variabele.

[Verwijderd]

.oisyn schreef op 12 februari 2004 @ 13:55:
[...]
Met een auto is het echter anders, omdat de wielen met de weg wrijving hebben. Als je een auto onder een hoek van zeg 45 graden over het wegdek schuift, dan zal ie op een gegeven moment verder gaan met de vector van z'n kijkrichting geprojecteerd op z'n bewegingsrichting, omdat de wielen gaan draaien (de wielen kunnen rollen in z'n kijkrichting, en rolwrijving is vrijwel nihil. De wielen geven natuurlijk wel wrijving als ze bewegen in een richting die haaks op de rolrichting staat). En dus "stopt" ie in de huidige bewegingsrichting en "gaat ie verder" in de kijkrichting

Bedankt voor de duidelijk uitleg. Het ziet er inderdaad uitleg als een ruimteschip .
Kan je mij een hint geven hoe dit te implementeren?

[.oisyn]

Als ik ervan uitga dat de zijwaartse wrijving van de wielen op het wegdek maximaal is, dan is het een kwestie van de bewegingsvector v projecteren op de kijkvector k, zoals ik al zei.

v' = (v ∙ k) * k

v ∙ k is het inproduct van v en k, en is simpelweg gedefinieerd als v.x * k.x + v.y * k.y
k is hier een unit-vector, dus eigenlijk gewoon de vector (cos angle, sin angle)

Je zou hier eventueel nog een niet-maximale wrijving kunnen simuleren door te interpoleren tussen v en v', waarbij het resultaat v is als er geen wrijving is, en v' als de wrijving maximaal is

[ Voor 21% gewijzigd door .oisyn op 12-02-2004 14:43 ]

[Verwijderd]

Je moet de snelheidsvector roteren als je stuurt.
met complexe getallen:
V=V*e^(i*phi) , waar phi de draaihoek in radialen is.
dit werkt uit in:

code:

vx=vx*cos(phi) -vy*sin(phi)
vy=vy*cos(phi)+vx*sin(phi)

edit:
@.oisyn:
dan ga je er van uit dat de wagen eerst draait en dan door het slippen de nieuwe rijrichting aanneemt, als de wagen gewoon netjes stuut moet je alleen de snelheidsvector roteren. Dan heb je ook energie behoud en met de projectie verlies je bewegingsenergie.

[ Voor 41% gewijzigd door Verwijderd op 12-02-2004 14:47 ]

[Verwijderd]

.oisyn zijn oplossing is dan eigenlijk zogezegd achterwiel aandrijving, omdat je daar door de bocht "slipt" (klein beetje)

PtDw zijn oplossing is dan voorwielaandrijving >> efficienter >> met behoud van energie en dus geen wrijvingsverlies.

Nu snap ik PtDw zijn oplossing wel qua principe, maar niet qua implementatie (ik heb nooit complexe getallen zien).

Kan jij mij hier een beetje uitleg over verschaffen? i is een constante die zorgt dat je negatieve vierkantswortels kon trekken ofzoiets? Wat is phi in mijn verhaal precies?

[.oisyn]

Verwijderd schreef op 12 februari 2004 @ 14:44:
dan ga je er van uit dat de wagen eerst draait en dan door het slippen de nieuwe rijrichting aanneemt, als de wagen gewoon netjes stuut moet je alleen de snelheidsvector roteren. Dan heb je ook energie behoud en met de projectie verlies je bewegingsenergie.

Klopt idd, maar je draait eigenlijk ook de wielen, niet de auto zelf

Verwijderd schreef op 12 februari 2004 @ 14:54:
Nu snap ik PtDw zijn oplossing wel qua principe, maar niet qua implementatie (ik heb nooit complexe getallen zien).

Kan jij mij hier een beetje uitleg over verschaffen? i is een constante die zorgt dat je negatieve vierkantswortels kon trekken ofzoiets? Wat is phi in mijn verhaal precies?

Vergeet complexe getallen, het komt eigenlijk gewoon neer op een transformatie dmv een matrix M:
[ cos (a), -sin (a) ]
[ sin (a), cos (a) ]

En dat vermenigvuldigen met je snelheidsvector (de a is hier natuurlijk een delta, en niet je absolute orientatie)

Alleen met dit model kun je natuurlijk nooit slippen

[ Voor 10% gewijzigd door .oisyn op 12-02-2004 15:01 ]

[Verwijderd]

.oisyn schreef op 12 februari 2004 @ 14:59:
Vergeet complexe getallen, het komt eigenlijk gewoon neer op een transformatie dmv een matrix M:
[ cos (a), -sin (a) ]
[ sin (a), cos (a) ]
En dat vermenigvuldigen met je snelheidsvector (de a is hier natuurlijk een delta, en niet je absolute orientatie)
Alleen met dit model kun je natuurlijk nooit slippen

Over complexe getallen, dat haalde ik er alleen bij om even snel de transformatiematrix, die .oisyn hierboven netjes opgeschreven heeft, af te leiden. (Vermenigvuldiging met een complexe e-macht geeft een rotatie, met als hoek het complexe deel van de exponent, maar zoals gezegd dat is hier eigenlijk niet relevant)

Als je de kijkrichting al weet is .oisin's methode misschien handiger, en als je die zonder slip wil hebben doe je gewoon :

code:

v_nieuw=||v_oud||*k

oftewel, met eventuele slip

code:

vnorm=sqrt(vx^2+vy^2)*(1-slip)
v_nieuw_x=vnorm*k_x
v_nieuw_y=vnorm*k_y

[.oisyn]

Hmm, die slip zoals je 'm daar hebt zorgt er alleen voor dat de snelheid afneemt, niet dat ie een stukje in de oude richting doorschuift

[Verwijderd]

dank jullie mannen!
Het werkt nu.

Het verbaast mij telkens weer opnieuw hoe moeilijk (ja ik vind dit moeilijk) simpele movements zijn. Gewoon voor een stomme tank te bewegen! Ik zal er allemaal wel véél bij leren danku

[.oisyn]

Je moet wel weten dat de oplossingen die in deze topic zijn aangedragen verre van nauwkeurig zijn, het is meer losse pols werk eigenlijk ("als je het zo en zo doet, dan lijkt het wel ongeveeer te kloppen"). Een beetje een combinatie van newtonian dynamics, euler integration (zoektermen ) en verder wat logisch redeneren en vogelen met vectoren. Als je er echt mee verder wilt kan ik je aanraden om wat meer te lezen over die 2 termen die ik net noemde, alsmede langrangian dynamics en verlet integration

Ik heb ooit eens geexperimenteerd met verlet integration, http://www.xs4all.nl/~oisyn/files/physics1.exe
spatie = een kracht uitoefenen op een van de vertices van het object, en met + en - regel je het aantal iteraties (staat standaard op 4). 1 iteratie geeft een heel elastisch object, terwijl een hoog aantal het juist heel stijf maakt (er zit verder geen check in, dus je moet even uitkijken dat je niet onder de 1 komt anders gaat het fout )

Verder kan ik je Game physics aanraden, hoewel het absoluut geen lichte stof is en vector en matrix algebra kennis, alsmede gewoon algemene wiskunde wel vereist is

[Verwijderd]

.oisyn schreef op 12 februari 2004 @ 15:14:
Hmm, die slip zoals je 'm daar hebt zorgt er alleen voor dat de snelheid afneemt, niet dat ie een stukje in de oude richting doorschuift

@.oisyn:Ja dat klopt, maar dat doet die bij jou ook niet. De schaling zit bij jou in het inproduct. (hoek tussen de vectoren)

En dit is inderdaad een beetje houtje touwtje, maar vaak wel nauwkeurig genoeg voor een spelletje. Als je netjes wil modelleren zal je de verschillende onderdelen afzonderlijk moeten identificeren, wat bij een tank (2 rupsbanden die bij iedere stuurbeweging slippen, in voorwaartse richting anders dan in zijwaardse richting, waar de gewichtsverdeling afhangt van de stand van de loop, en zowieso niet symetrisch is ......) niet eenvoudig zal zijn.

[Verwijderd]

Het gaat een tank zijn voor een rts spellejtes. Hoop en al 40 pixels op 40 pixels. Ik denk dat ik NIET twee rupsbanden ga moeten modelleren. Anders kan ik een héél eindwerk maken over een tank

[.oisyn]

Verwijderd schreef op 12 februari 2004 @ 15:49:
[...]

@.oisyn:Ja dat klopt, maar dat doet die bij jou ook niet. De schaling zit bij jou in het inproduct. (hoek tussen de vectoren)

oh ik beweer ook niet dat die van mij perfect is verre van perfect zelfs

offtopic:

maar vaak wel nauwkeurig genoeg voor een spelletje

met de nadruk op letje
Hedendaagse games zijn vrij goed gemodeleerd met uitgebreide numerical differential en integral solvers, verdeelde massa en individuele objecten. Een auto bestaat dan bijvoorbeeld ook echt uit 4 wielen, vering, een motor en de rest, waarbij de simulatie ook echt werkt door een torsie op de motor te zetten, afhankelijk van het huidige toerental en versnelling, waardoor de wielen gaan draaien, en de wielen ook echt sturen. Vaak zit er zelfs een gesimuleerde differentiaal in zoals in een echte auto ook zit, om wielen aan de buitenkant van een bocht sneller te laten draaien dan die aan de binnenkant.

[Soultaker]

Ik geloof dat het probleem al opgelost was, dus misschien is het niet meer van belang, maar je zou je ook kunnen laten inspireren door het model dat in RARS gebruikt wordt: RARS Physics Model. Het is nog redelijk te behappen en het resultaat komt redelijk realistisch over (al zijn er nog een heleboel uitbreidingen denkbaar; auto's worden bijvoorbeeld nog steeds als punten gemodelleerd).

Er wordt onder andere ook ingegaan op het beperken van het motorvermogen (je kunt logischerwijs niet oneindig veel vermogen genereren) en je krijgt het 'slippen' (in de niet-mechanisme betekenis) erbij kado. Het leuke vind ik ook dat dingen als ABS wel direct effect hebben, zonder dat allerlei moeilijke dingen erbij gesleept worden.

Uiteindelijk komt het allemaal neer op dit plaatje:

De snelheid (V) en oriëntatie (P) van de auto zijn bekend, de lengte van W is in principe willekeurig. Uiteindelijk gaat het om de krachtvector F die (in combinatie met het gewicht van de auto) de acceleratie (en daarmee de snelheidsverandering) bepaalt.

[ Voor 32% gewijzigd door Soultaker op 12-02-2004 16:07 ]

[Verwijderd]

ik dacht eignelijk dit boek http://www.amazon.com/exe...me=ATVPDKIKX0DER&st=books te kopen.

Welk is dan het beste vergeleken met http://www.amazon.com/exe...TFRB0&colid=2R7T2Q9NGMNP8

[.oisyn]

Game physics is wel een stuk duurder ($69 vs. de $27.11 van Physics voor gamedevvers) (ik had 'm zelf voor $48, hij was ook maar net uit. Tegen de tijd dat ik 'm ontvangen had was ie ineens $21 in prijs gestegen ), maar dat buiten beschouwing gelaten...

Ik ken physics voor gamedevvers niet, maar aan de inhoudsopgave te zien zijn het wat meer beginnersconcepten. Wat ik overigens wel mis is een hoofdstuk over collision detection, zeker geen makkelijk onderwerp en toch vrij essentieel voor game physics. Pre is dat ze wel weer allemaal modellen bespreken voor auto's, vliegtuigen, etc.. Maar ik denk dat het daarom ook meer een benadering is, terwijl de technieken besproken in Game Physics veel meer met de werkelijkheid te maken hebben (waar je ook hoofdstukken terugvindt over het goed numerical oplossen van differentiaal en integraal vergelijkingen).

Game physics komt ook met een uitgebreide cdrom met voorbeeldcode en een complete physics engine, compileerbaar onder windows, linux en macintosh. In dat boek staan ook nog andere physics dingen besproken, zoals de physics die met graphics te maken hebben (reflection, refraction, etc.)

Ik zie dat de TOC van game physics niet online staat, die staat toevallig op de cdrom die erbij zit, kan ik wel online zetten

.edit: http://www.oisyn.nl/gamephysics_toc.html

[ Voor 3% gewijzigd door .oisyn op 13-02-2004 21:42 ]

[Confusion]

.oisyn schreef op 22 januari 2004 @ 18:41:
Een object heeft 5 eigenschappen: massa (scalar), positie (punt), velocity (vector), oriëntatie (scalar in 2d, axis/angle of quaternion oid in 3d) en een draaisnelheid (eveneens scalar in 2d, axis/angle of quaternion oid in 3d). For the sake of usability nemen we even aan dat een punt ook een vector is

Een quaternion? Hoe wil je die toepassen om de beweging van een voorwerp te beschrijven?

[.oisyn]

Lees eens goed, daar staat oriëntatie, en draaisnelheid. Niet voor reguliere beweging dus
(Overigens is draaisnelheid niet helemaal de correcte term, maar het gaat natuurlijk om een angular velocity, oftewel een vector quantity waarvan de magnitude staat voor de draaisnelheid en de richting voor de draairichting. Typisch een quaternion dus)

[ Voor 58% gewijzigd door .oisyn op 13-02-2004 23:31 ]

[Confusion]

.oisyn schreef op 13 februari 2004 @ 22:49:
Lees eens goed, daar staat oriëntatie, en draaisnelheid. Niet voor reguliere beweging dus

Nouja, dat beschouw ik als onderdeel van de beweging van het object; ik doelde in ieder geval gewoon op wat je schreef.

(Overigens is draaisnelheid niet helemaal de correcte term, maar het gaat natuurlijk om een angular velocity, oftewel een vector quantity waarvan de magnitude staat voor de draaisnelheid en de richting voor de draairichting. Typisch een quaternion dus)

Ik ben inmiddels een linkje op het spoor gekomen dat het me heeft verklaard. Ik kende quaternionen alleen als abstracte groep en ik vroeg me af waarom je het niet 'gewoon' met 2x2 complexe matrices deed (in 3D), maar 2x2 complexe matrices zijn een representatie voor quaternionen .

[ Voor 4% gewijzigd door Confusion op 14-02-2004 00:04 ]

[.oisyn]

Ah ok, quaternions staan er (in mijn vakgebied iig) bekend om dat je er rotaties mee kunt representeren, dus ik ging er even vanuit dat jij dat ook wel wist . Maar goed, het voordeel van een quaternion tov 3x3 of 4x4 transformatiematrices is natuurlijk om het feit dat je ze veel makkelijker kunt interpoleren (of in het algemeen: exponent en logaritme van een quaternion zijn well-defined en vrij simpel, wat natuurlijk de mogelijkheid geeft tot machtsverheffen, en derhalve interpoleren)

[Tomatoman]

.oisyn schreef op 13 februari 2004 @ 22:49:
Lees eens goed, daar staat oriëntatie, en draaisnelheid. Niet voor reguliere beweging dus
(Overigens is draaisnelheid niet helemaal de correcte term, maar het gaat natuurlijk om een angular velocity, oftewel een vector quantity waarvan de magnitude staat voor de draaisnelheid en de richting voor de draairichting. Typisch een quaternion dus)

In het Nederlands heet angular velocity hoeksnelheid.

[.oisyn]

Vertaalt snelheid dan wel naar velocity? Velocity impliceert namelijk een soort van vector, snelheid lijkt me eigenlijk alleen maar een scalar

[quote=http://www.vandale.nl/opzoeken/woordenboek/?zoekwoord=snelheid]snel·heid (de ~ (v.), -heden)

1. het zich snel kunnen voortbewegen
2. grootheid die de verhouding tussen de afgelegde weg en de daarvoor gebruikte tijd uitdrukt => gang, tempo, vaart
3. mate waarin een proces voortgang heeft
4. [foto.] lichtgevoeligheid van opnamemateriaal

[q=http://dictionary.reference.com/search?db=*&q=velocity]
ve·loc·i·ty
[list=1]• Rapidity or speed of motion; swiftness.
• Physics. A vector quantity whose magnitude is a body's speed and whose direction is the body's direction of motion.
•

• The rate of speed of action or occurrence.
• The rate at which money changes hands in an economy.

Maar misschien is vandale gewoon onvolledig in deze

[Tomatoman]

Het is toch ook een snelheid? De hoeksnelheid ω, uitgedrukt in radialen per seconde, is een grootheid waarmee je aangeeft hoe snel iets roteert. Het aardige van de hoeksnelheid is dat dit getal voor ieder punt in een roterend object even groot is. De snelheid van een punt is daarentegen afhankelijk van de afstand tot de omwentelingsas:
v = ω × r

[Confusion]

.oisyn schreef op 14 februari 2004 @ 00:14:
Maar goed, het voordeel van een quaternion tov 3x3 of 4x4 transformatiematrices is natuurlijk om het feit dat je ze veel makkelijker kunt interpoleren (of in het algemeen: exponent en logaritme van een quaternion zijn well-defined en vrij simpel, wat natuurlijk de mogelijkheid geeft tot machtsverheffen, en derhalve interpoleren)

Maar exponenten en logaritmes van matrices zijn ook goed gedefd en uiteindelijk wordt alles toch componentsgewijs berekend: de atomaire berekeningen zijn uitgeschreven exact hetzelfde. Ik zie daarom niet waarom quaternionen 'goedkoper' qua rekenkracht zijn. Waar komt dat door?

[Tomatoman]

Als je bij een 3x3 matrix de exponent of logaritme van alle afzonderlijke componenten berekent, kost je dat 9 berekeningen. Als je eerst de matrix uitwerkt en daarna pas de exponent of logaritme neemt, hoef je dat maar 1x te doen. Dat is 8 berekeningen 'goedkoper'.

[.oisyn]

tomatoman schreef op 14 februari 2004 @ 01:16:
Het is toch ook een snelheid? De hoeksnelheid ω, uitgedrukt in radialen per seconde, is een grootheid waarmee je aangeeft hoe snel iets roteert. Het aardige van de hoeksnelheid is dat dit getal voor ieder punt in een roterend object even groot is. De snelheid van een punt is daarentegen afhankelijk van de afstand tot de omwentelingsas:
v = ω × r

Euh ja, maar denk nu eens aan het 3-dimensionale geval. Behalve een snelheid moet je ook nog weergeven over welke as gedraaid moet worden Een angular velocity heeft dat in zich, die ω niet

Confusion schreef op 14 februari 2004 @ 01:17:
[...]

Maar exponenten en logaritmes van matrices zijn ook goed gedefd

is ook zo

en uiteindelijk wordt alles toch componentsgewijs berekend: de atomaire berekeningen zijn uitgeschreven exact hetzelfde.

Niet echt. Je moet eraan denken dat voor rotaties niet de volledige verzameling van quaternions wordt gebruikt, maar alleen de quaternions met lengte 1.
Een quaternion kan geschreven worden als
[1] R * (cos (theta), u * sin (theta))
waarbij u een 3-vector is met lengte 1, en R een scalar.

Gegeven (1), dan is de exponent van een quaternion:
[2] exp(q) = exp (cos (theta)) * (cos (R), u * sin (R))
[3] ln(q) = (ln (R), u*theta)

Aangezien we werken met unit-length quaternions, is R gelijk aan 1. Het berekenen van exponent en logaritme is dus vrij makkelijk. Sterker nog, we kunnen deze functies totaal vergeten om machten te berekenen. Ook logisch als je het van een intuitief standpunt benaderd: een quaternion is gemaakt van een as u en een hoek theta. Dat betekent dat q^x hetzelfde is als de quaternion van u en theta*x. Dat zijn dus maar enkele operaties, tov al die operaties die je bij een matrix uit moet voeren.

Een ander punt is afrondingsfouten, waar een quaternion veel minder last van heeft dan een matrix. Het combineren van rotaties dmv vermenigvuldigingen gaat bij quaternions ook een stuk sneller (14 muls, 13 adds) dan bij 3x3 matrices (27 muls, 18 adds)

(PS: ja je kunt axis/angle ook extracten uit een rotatie-matrix, maar dat is geen goedkope operatie vergeleken met quaternions, en bevat ook nog eens conditionele operaties)

[ Voor 8% gewijzigd door .oisyn op 14-02-2004 02:10 ]

[Tomatoman]

.oisyn schreef op 14 februari 2004 @ 01:58:
[...]


Euh ja, maar denk nu eens aan het 3-dimensionale geval. Behalve een snelheid moet je ook nog weergeven over welke as gedraaid moet worden Een angular velocity heeft dat in zich, die ω niet

Wel degelijk. Zoals je in mijn notatie ziet, heb ik ω vet aangegeven - het is een vector. v is het uitwendig product van ω en r en staat als zodanig loodrecht op beide vectoren. Hieruit kun je afleiden dat ω parallel loopt aan de omwentelingsas. Via de rechterhandregel kunt je beredeneren welke kant ω op moet wijzen.

[.oisyn]

ah ok, daar heb je gelijk in (ben er met m'n hoofd niet echt bij vandaag)

.edit nav de post onder me:
* .oisyn is ook geen belg Volgens mij haal je me door de war met whoami (en anders snap ik je opmerking niet )

.edit2: mijn slotjes zijn toch nooit zo bot?

[ Voor 107% gewijzigd door .oisyn op 14-02-2004 04:29 ]

[Tomatoman]

Ach ja, ik ben dan ook geen Belg

[edit n.a.v. .oisyn]
Jij geen Belg? Zijn er dan ook van die botte Nederlandse slotjesgooiers?

[ Voor 58% gewijzigd door Tomatoman op 14-02-2004 04:01 ]

[Confusion]

.oisyn schreef op 14 februari 2004 @ 01:58:
Niet echt. Je moet eraan denken dat voor rotaties niet de volledige verzameling van quaternions wordt gebruikt, maar alleen de quaternions met lengte 1.

En daarom ook alleen de groep unitaire 2x2 complexe matrices met determinant +1

Dat zijn dus maar enkele operaties, tov al die operaties die je bij een matrix uit moet voeren.
[..]
Het combineren van rotaties dmv vermenigvuldigingen gaat bij quaternions ook een stuk sneller (14 muls, 13 adds) dan bij 3x3 matrices (27 muls, 18 adds)

Ten opzichte van 3x3 matrices begreep ik het wel, maar ten opzichte van matrices uit SU(2) niet, aangezien ik dacht dat dat volkomen identiek zou moeten zijn. Maar ik zie nu dat R = 1 rekenwerk bespaart voor de representatie van quaternionen zoals je gebruikte, terwijl het dat voor matrices uit SU(2) niet direct doet, zoals een snuggere coordinaattransformatie variabelen kan besparen.

Dank je voor de uitleg.

[Tomatoman]

.oisyn schreef op 14 februari 2004 @ 02:32:
[...]
.edit2: mijn slotjes zijn toch nooit zo bot?

offtopic:
Het is een grote fout mij serieus te nemen. Zie mijn sig.