Det har før givet anledning til megen dokumentation af effektivisering, men nu er vi nået til et punkt, hvor vi bliver nødt til at overveje præcision, når verlet-integration anvendes.
Lad os tage et konkret eksempel:
To partikler (de blå) har en constraint imellem sig (den grønne linje), som er 2x lang. Vi ønsker nu at placere en partikel midt imellem dem (den gules placering), og det virker oplagt, at så skal den røde bare have afstanden x til hver af de to partikler, og så er den i vinkel.
Sådan er det imidlertid ikke når man arbejder med verlet integration. Man kan ikke være sikker på at partiklernes placering hele tiden er korrekt, blot, at de vil forsøge at placere sig korrekt. Jo flere integration steps man tager i sekundet, desto mere præcis er vil partiklernes placering være, men den vil i reglen aldrig være perfekt.
Når en konstruktion som den ovenstående indgår i en struktur kommer denne præcision til at spille ind.
Der sker nemlig det, at de blå partikler vil søge at placere sig korrekt, og derfor vil stå og slå lidt.
Det gør ikke noget for dem - de har mange andre partikler at støtte sig til, så deres placering opnår ved relativt få iterationer af verlet integration en god ca. placering.
Den røde partikel, derimod, har kun 2 partikler at læne sig op ad. Og hvad værre er, en relativt lille procentvis afvigelse i x giver en stor procentvis afvigelse i forhold til hvor tæt den er på idealplaceringen. Lad os kigge på nogen kommatal:
Hvis x er 1.0 lang, så kunne den for eksempel få værdien 1.001. så er den grønne afstand 2.002. Hvis de blå partikler så ryster lidt, så afstanden ændrer sig til 2.004, og x derfor ændrer værdi til 1.002, så er det ok - for de blå partikler er der tale om 0.002/2 = 0,1% forskel, og det er ikke til at se. Men får den røde partikel, som før var i afstanden (1.001^2 - 1.000^2) = 0.002 fra sin idealplacering, så er den nu (1.002^2 - 1.000^2) = 0.004 - altså en 100% større fejlmargin.
Men betyder det virkelig noget? når tallene er så små?
Ja, det gør det, og det har vi nogle screenshots af allerede. Det betyder faktisk så meget, at der pludselig opstår tydelige afstande, hvor der ikke burde være nogen. Efter mange tests viser det sig, at hvis længderne er præcise med blot 4-5 decimaler i forhold til idealet, så er der ikke noget problem, selv med en følsom midterpartikel - men det krævede så,
med en stor, verbos algoritme, mere end 1000 verlet integrations før denne præcision var opnået.
Da der er påvirkninger i forbindelse med hver eneste integration, kan vi ikke umiddelbart arbejde ud fra at denne form for ro nogensinde vil opstå i openengine.
Det er et problem, for det tvinger os til at overveje konstruktioner som undgår bestemte teknikker til partikelplacering, og generelt kan vi ikke længere bruge, at et lavt antal constraints giver et sundt resultat hvis bare man sætter antallet af integrationer i vejret. Vi bliver nu, simpelthen, nødt til at forholde os til konstruktionstypem, og dennes stabilitet. Noget kan eksempelvis løses ved hjælp at lidt løsere constraints, andet ved hjælp af en mere doven integration, og noget tredje kan være aktivt at udsulte systemet for energi så det falder til ro lettere.
Da tidspresset så småt begynder at kunne mærkes, og vi ikke har et miljø oppe og køre hvor vi kan teste os til _et_ resultat som passer med openengine, kan vi gøre det at vi programmerer både ideale optimerede konstruktioner med den ene hånd, og samtidig programmere robuste konstruktioner, som så er tungere men mere pålidelige med den anden.
Såfremt vi sikrer at ledene anvender løse koblinger kan vi anvende fleksibiliteten i vores system til at lave både livrem og seler, og så senere skifte efter forgodtbefindende =]
(præcis ligesom vi, i parantes bemærket, kan lave fuldt kompatible skeletter med ens opførsel, der kan anvende constraints til forward kinematics hvis vi skulle have lyst til det)
Ingen kommentarer:
Send en kommentar