I den forbindelse er vi stødt på et problem med vores porte, som kræver at vi foretager et umiddelbart valg. Lad os først dokumentere problemet:
Et væsentligt langsigtet mål med vores system er at vores knogler/led/skeletobjekter er entydigt bestemt internt - Det på trods af at de kun består af afstande og punkter. Men, hele skelettet skulle også gerne være entydigt bestemt. Det skulle vores porte, i reglen, sørge for. Det har de også gjort hidtil, men det er nu gået op for os, at det ikke altid er tilfældet.
Sådan er det imidlertid ikke på nuværende tidspunkt. Helt basalt set er vores porte ikke orienteret korrekt. Vi låser, som det er nu, to objekter sammen ved at svejse deres porte sammen – det har den heldige effekt, at man kan orientere objektet man sætter på i 4 retninger, så man kan foretage en tilnærmelsesvis drejning i et led og ikke behøver skrue på de omkringliggende knogle-objekter meget.
Samtidig, og vigtigst, sikrer vi rigtig 3-dimensional placerings-afhængighed, idet portene nu er 1 og samme, og dermed har dens position indflydelse på partiklerne i begge objekter.
Problemet er, at objekterne ikke kan finde ud af hvilken side af den nye port netop deres partikler skal være på:
Det ene objekt, skoen, er opbygget af indbyrdes afstand, og er entydigt. Det andet objekt, læggen, er også opbygget af inbyrdes afstande og er entydigt.
Det at svejse portene sammen er ikke nok – der skal på én eller anden måde tilføjes endnu en constraint for at det holder. Vores opgave, rent programmeringsmæssigt, er at automatisere samlingen bedst muligt. Ideelt set skal brugeren af objekterne ikke kende til hverken skoens eller læggens opbygning; og han skal absolut ikke ind og beregne afstanden mellem to punkter i det nye objekt for selv manuelt at tilføje en constraint, det ville være ødelæggende for vores mix-and-match mål med bibliotektet.
Desværre betyder det her en generel udvidelse af vores arbejde:
1.
Vores porte ændres så de er 3dimentionale ved at tilføre én ny partikel, og kun en del af portene svejses, hvilket vil indbygge orientering i portene. Det betyder imidlertid at man, i designet af objekter, skal forbinde sig stramt til en væsentligt mere kompleks port: Hvis hele objektet er hæftet ved en 3dimensional port, kan man, i svejsningen, automatisk sætte en constraint på mellem de 2 partikler i portene som ikke er i plan sammen. De er nødt til, for at sikre at man kan rottere et led som nu, at være en slags små pyramidetoppe.
- Det er en puritansk løsning, som desværre gør hvert eneste led mere komplekst, og som gør at skrivningen af nye basisled, knogler, og større strukturer bliver mere kompleks. På plus-siden er den overkommelig: Der skal kun én ny fast constraint imellem den nye partikel i den ny porttype og vores hidtige knogler og led. Resten af konstruktionen ligger i den ny porttype. Det er smatidig heller ikke en uoverkommelig opgave at splejse de ny porttyper sammen, og vi kan, efter splejsnigen, glemme alt om porte og objekter og derfra kun arbejde med en liste af partikler og en liste af constraints.
2.
Vi løser problemet når vi sætter koordinater på: gennemsnittet af koodinaterne i det ene objekt skal ligge på den ene side af det plan porten udgør, gennemsnittet af koordinaterne for det andet objekt skal ligge på den anden side.
- Det er en rigtig snusket løsning som fritager os for ansvaret her ved at skubbe det fremad til instancieringen af koordinater. Vi skal bare sikre, som invariant, at vores objekter altid, i gennemsnitskoordinater, befinder sig på den ”rigtige” side af porten, og det gør ikke noget at nogen af partiklerne raver forkert. Det er lunkent, for hvis foden, i den tegnede analogi, bliver slået hårdt på runtime kommer den pludselig til at krænge op i læggen, og det er vi helt sikkert ikke interesserede i. Endelig kræver det, at vi, når vi producerer koordinater stadig bibevarer mulighed for at traversere legemet som objekter med porte.
3.
Vi gør det samme som ovenover, min vi udvidder openengine til også at forstå konceptet porte og skeletobjekter, og vi foretager hele beregningen på runtime. Så har vi oversat hele modellen til c++ og vi bruger kun python fordi det er ”et rart sprog”. Vi smadrer i øvrigt alt hvad der har med performance og gøre.
- kritiske kommentarer og grimme ord overlades til læserens fantasi.
4.
Vi udpeger en føle-partikel som har riggid-forbindelse til hver port i hvert objekt, og giver variabler med for porten og føle-partiklen frem til koordinatisering/runtime. Når porte svejses arves følepartikler fra de to forældre-porte. Vi foretager lejlighedsvis, men først i forbindelse med koordinatisering/runtime, en point-plane-comparison til begge følepunkter tilkoblet en svejset port. Er de på samme side smides det ene følepunkt over på den anden side.
- Hvis ikke denne løsning fremføres helt op til runtime har den samme svaghed med inadkrængende objekter som løsningen ovenover, men den vil være relativt billig at checke på runtime i forhold til.
5. Alle punkter i alle objekter holder sig på deres side af portene. Det giver problemer i forhold til punkt 4, se illustrationen nedenunder, hvor en stor rigidbody har en port med partikler på begge sider. Her skal objekterne bibevares helt frem til det tidspunkt hvor checket køres.
Som det kan ses accepteres en del af partikler ikke (de gule).
- Ærgelig løsning, som kræver bibevarelse af mange variable for at adressere objekterne individuelt langt hen i processen.
6. Ligesom i punkt 4 anvendes følepartikler, men denne gang defineres på slum for hver følepartikel en constraint, hvori portstørrelsen indgår som faktor. Det gælder så generelt, at partiklen som minimum er ½ portstørrelse væk fra porten, og at dens constraint til enhver anden følepartikel maximum rager ½ portstørrelse ind over dennes. Afstandene er angivet i afstande vinkelret på planet porten udgør. Derudover må det gælde, at alle portens 4 partikler have kortere afstand til følepartiklen, end dens minimumsafstand til den anden følepartikel. Når portene splejses sørger partiklerne for automatisk at oprette disse minimums-constraints.
- Svær at dokumentere forståeligt, og designet af basisled problematiseres noget. Følepartiklen skal vælges til at være centralt placeret i forhold til sin tilhørende port, men så længe den befinder sig ”oven over” porten så går det. Hvis ikke constraintsne overholdes nøje risikerer man inkompatible led/knogler.
_______________
Gruppen hælder for øjeblikket mod model 1, og vi ønsker at beslutte os for en løsning inden fredag, men det er forhåbentligt den sidste større problemstilling i vores modelleringsarbejde =]
Ingen kommentarer:
Send en kommentar