Extension name:
SimplePhysicsSystem
Location:
~abachn/oe/extensions/SimplePhysicsSystem/
Purpose:
This is a simple physics engine written in C++. It contains a number of PhysicsSystems that again contains particles and constrains. The PhysicsEngine uses Verlet integration to calculate the particle positions over time. This is taken from the FixedTimeStepPhysics extension.
Each PhysicsSystem can have a range of modifiers like gravity and can collide with surfaces that in not part of the world graphics.
Dependencies:
Implementation details:
tirsdag, december 18, 2007
fredag, december 14, 2007
Nu også figurer med placering :-O
Vi har nu gjort det muligt at placere vores ting andre steder end i 0.0. Man kan nu placere dem hvor man har lyst i rummet, og samtidig kan man også dreje dem som man har lyst til. I sig selv en meget god lille opdatering, men for at det ikke skal være løgn er det nu også muligt at vælge en hvilken som helst port, i en hvilken som helst figur, og så fastsætte et sted og en vinkel som den skal tegnes i. Det vil gøre det muligt for os at sige at et hoved skal være i positionen (0, 30, 0) så den altså bliver sat et godt stykke over jorden, og det gør os faktisk også indirekte i stand til at bestemme hvilken del af kroppen vores figur skal tegnes ud fra.
Umiddelbart en lille opdatering, men faktisk en ret væsentlig del af projektet :)
Umiddelbart en lille opdatering, men faktisk en ret væsentlig del af projektet :)
tirsdag, december 11, 2007
Visualizer, nu også med mulighed for placering
Ja, som der så smukt står i overskriften, har vi nu gjort det muligt at bestemme hvor i visualiseringen, det man tegner skal tegnes. Dette blev opnået ved at lave et nyt objekt, der i modsætning til vores andre objekter, havde partikler med placeringer. Inde i vores distributor, sørger vi så for at gemme disse partikler i deres egen liste, så de ikke bliver berørt af eksplosionen, men stadig bliver brugt til at udregne constraints med. Og efter hvert gennemløb af distribute-algoritmen bliver deres position så sat til det de oprindeligt var igen. dette sikrer os at figuren altid vender som vi gerne vil have det, og gør det lettere at visualizere store figurer. Man sørger bare for at attache vores nye object der hedder Placer, meget passende, til det objekt man nu engang vil have til at være på et særligt sted, og placeren sætter sig så med centrum i 0.0 og resten af figuren bliver tegnet ovenpå det :)
mandag, december 10, 2007
randomniseret distributor
nu er vores distributor-algoritme blevet randomniseret ved hjælp af en modulus-funktion.. sørger for at vi ikke kommer ud for nogen problemer, med nogen constraints der ikke virker efter nogen af de tidligere er blevet kørt, og derved bliver det meget mere stabilt og sikkert :)
søndag, december 09, 2007
Præcision af et afstandsbaseret system
Som mange gange nævnt er vores led konstrueret alene ved hælp af partikler og afstande.
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)
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)
lørdag, december 08, 2007
Visualisering
Når man skal opbygge led som dem vi vil lave, er det utroligt praktisk at have en visuel repræsentering af dem. Og til det formål har vi været så heldige at der findes et tool til at visualisere python, nemlig vpython. I sig selv er det ikke voldsomt svært at vise sin kode ved hjælp af vpython, men vi løber dog hurtigt ind i et problem, da det eneste vi har at tegne vores figurer efter, er partikler uden nogen position i rummet og så nogen constraints der binder disse partikler sammen. Dette gør at vi er nødt til at skrive en algoritme der tildeler partiklerne positioner.
Vores algoritme, ellers vores distributor, får givet en liste af partikler, og en liste af constraints.
Det første vi gør er at tildele alle partiklerne nogen tilfældige positioner i rummet, og herefter sætter vi antallet af gange vi vil køre vores eksplosionsalgoritme. Vi laver så en while-løkke, hvor vi i hvert skridt først regner gennemsnitspositionen ud. Herefter exploderer vi vores partikler væk fra det punkt. Med andre ord kan partiklerne ikke lide hinanden. Nu har vi fået partiklerne til ikke bare at ligge i en tilfældig klump omkring (0,0,0), men det er stadig ikke godt nok. Derfor er vi nødt til også at have fat i vores constraintlist. Alle vores constraints har attributer der gemmer på de to partikler de er forbundet til, og vi regner nu vectoren mellem de to partikler ud. Vi regner så længden på alle constraintvectorerne ud, og gemmer dem i en liste. Denne længde bruger vi så til at regne ud om de to partikler constrainten binder sammen er for tæt på hinanden eller for langt væk, ved hjælp af constraintens minimum- og maximum-længde. Er partiklerne for tæt på hinanden, bliver de skubbet lidt væk fra hinanden, og omvendt hvis de er for langt væk fra hinanden.
De sidste skridt hvor vi tilpasser constraintsne bliver kørt en del flere gange end selve eksplosionen, og det er fordi det er her vi tilpasser figuren.
Nu har partiklerne så fået tildelt deres positioner, og det er tid til at tegne dem. I vpython foregår det så smart som at man, i en helt almindelig pythonfil, skriver ”from visual import *”. Når det er gjort har vi tilgang til alle de funktioner vi skal bruge. Vi laver så en funktion der hedder draw, der først kører vores distributionsalgoritme, og herefter tegner partiklerne og constraintsne. Partiklerne bliver tegner som bolde, eller spheres for at blive i fagsproget, og constraints som rods, eller rør.
En af de smarte ting ved den her visualiseringsmetode, er at det også er den vi gør brug af når vi importerer vores python i c++, og derved i openengine, så ikke nok med at den gør vores designarbejde utroligt meget nemmere, så er den også med til at sikre os, at vi kan repræsentere det vi har lavet, og det er alt andet lige en hel del sjovere at se på en visualisering af vores skelet, end bare på nogen stumper kode. Til at starte med giver den os dog ikke det helt ønskede resultat, så vi er nødt til at kunne fortælle den hvilken orientering et givent led skal have, men vi får det tegnet og det ser smukt ud selvom retningen ikke altid er den ønskede. Nedenfor ses vores hængselsled tegnet ved hjælp af vpython.
onsdag, december 05, 2007
Project: CreatePythonModels
Project name:
CreatePythonModels
Location:
http://www.daimi.au.dk/~abachn/oe/projects/CreatePythonModels/
Purpose:
A project that uses the python bindings via PythonModels to create and display models scripted in python. The models are via !PythonModels loaded into a physics system.
Dependencies:
Implementation details:
In the GameFactory of this project we have create one instance of the PythonModels class. This exports the nessesary classes and functions to python and we can run scripts from this project that expect to find the classes defined by the extension.
We have created a Module that in added to the engine that monitors a list of files. It one of these files are updated, the entire model is recalculated.
CreatePythonModels
Location:
http://www.daimi.au.dk/~abachn/oe/projects/CreatePythonModels/
Purpose:
A project that uses the python bindings via PythonModels to create and display models scripted in python. The models are via !PythonModels loaded into a physics system.
Dependencies:
Implementation details:
In the GameFactory of this project we have create one instance of the PythonModels class. This exports the nessesary classes and functions to python and we can run scripts from this project that expect to find the classes defined by the extension.
We have created a Module that in added to the engine that monitors a list of files. It one of these files are updated, the entire model is recalculated.
Abonner på:
Opslag (Atom)
