Fysikmotor update 090710: Numerisk Integration (tech talk)

Det är inte utan en viss känsla av ironi jag ser tillbaka på hur arbetet med fysikmotorn började. För det första så hade jag en hyfsat avancerad kurs i numerisk integration färskt i bagaget, och tänkte att detta måste ju vara den mest kritiska komponenten. Oavsett om jag skulle behöva enkel Euler-integration eller mer manliga metoder som implicit Euler eller adaptiv steglängd så var det i alla fall här problemet låg. Kollisionsdetektering var också viktigt, så mycket insåg jag.

Men utvecklingen blev en helt annan. För det första så insåg jag överhuvudtaget inte behovet av den komponent som skulle visa sig vara allra viktigast i slutändan – solvern, som gör det möjligt att hantera flera länkade kontaktpunkter och leder.
Men framförallt så visade det sig att betydelsen av numerisk integration var en helt annan än vad jag hade tänkt mig. I kursen jag hade läst handlade det alltid om kända mekaniska system där alla relationer kunde ställas upp i ekvationssystem på förhand. Så är ofta fallet i industri- och forskningssammanhang där man simulerar enstaka system, och söker så precis simuleringsdata som möjligt utan krav på snabbhet. Det vill säga helt motsatta förhållanden till dem jag skulle hålla på med. Jag prioriterade hastighet istället för exakthet, vilket i princip uteslöt vissa av det mer exotiska – och dyra – integrationsmetoderna redan från början.

Sedan hade jag som en nyckelegenskap att relationer (kollisioner, krafter och leder) skulle kunna komma och gå dynamiskt (exempelvis genom interaktion med användaren), vilket innebar att det inte fanns några på förhand kända systemekvationer. Detta var av kritisk betydelse för de annars populära implicita metoderna, där man bl a behöver kunna evaluera sitt system i framtiden – en omöjlighet för okända/föränderliga system. Man kan approximera framtiden, och detta är precis vad en del utvecklare gör, men det är omständigt och kostsamt. Gängse norm bland realtidsutvecklare verkar därför vara att undvika implicita metoder helt och hållet genom att designa systemen på så sätt att de inte behövs (bl a genom att undvika mycket styva fjädrar, som kan vara svåra att få stabila för icke-implcita metoder).

Så istället för en häftig numerisk integrator sitter jag nu med enkel Euler-integrator på kanske tio rader kod, samtidigt som kollisionsdetekteringen (som jag bara hade mindre sus om) och solvern (som jag inte ens hade insett behovet av) svällt upp som de stora, tunga komponenterna. Tji fick jag.

~ av Calvin den juli 10, 2009.

Kommentera

Fyll i dina uppgifter nedan eller klicka på en ikon för att logga in:

WordPress.com Logo

Du kommenterar med ditt WordPress.com-konto. Logga ut / Ändra )

Twitter-bild

Du kommenterar med ditt Twitter-konto. Logga ut / Ändra )

Facebook-foto

Du kommenterar med ditt Facebook-konto. Logga ut / Ändra )

Ansluter till %s

 
Följ

Få meddelanden om nya inlägg via e-post.