---

Jeg har nu endelig fået strikket min simple fysikmotor sammen så jeg kan
lave fine simulationer af div opstillinger. Her er det dog primært klæde der
har fanget min interesse, da det er nogen meget flotte effekter man kan få
frem der.
Imidlertid kan stoffet vikle sig rundt i sig selv og passere gennem sig
selv, og det ser jo ikke så pokkers realistisk ud.
En løsning, som foreslået af Thomas J andetsteds, er at forhindre dele af
objektet (her stoffet) i at nærme sig andre dele af objektet mere end
distancen x. Brugt til at forhindre ben i at gå gennem arme ol. i et andet
project.
Så vil stoffet kollidere med andre dele af stoffet istedet for at smutte
igennem, men er det i praksis den mest effektive måde? Den virker på mig
mere som en nem lappeløsning.

Da jeg har fået en del hjælp, i forbindelse med fysiksimulering, her i
gruppen, vil jeg lige indbyde alle intereserede til at kigge på.
http://icewalker.homepage.dk hvor der ligger en række billeder, exe demoer
og sourcecode.
Alle kommentarer (til siden og dens indhold) modtages med kyshånd.

Nederst på siden er en ..ehm.. "vand"simulering. Den burde kunne blive
ganske strålende hvis der anvendes 3d metaballs istedet for de nuværende 2d
kugler.

Tak til alle, der har hjulpet med det her

---

Desilva skrev:

>Da jeg har fået en del hjælp, i forbindelse med fysiksimulering, her i
>gruppen, vil jeg lige indbyde alle intereserede til at kigge på.
>http://icewalker.homepage.dk hvor der ligger en række billeder, exe demoer
>og sourcecode.

Jeg vil opfordre evt. interesserede til at udskifte \ med / i de
links der er angivet. Og husk at placere bitmappen i C:\

Alternativt kunne hjemmesiden naturligvis også få rettet disse
ting, og programmerne kunne hente billedet i samme mappe som de
selv ligger.

Men det ser meget skægt ud!

--
Bertel
http://lundhansen.dk/bertel/   FIDUSO: http://fiduso.dk/

---

> Alternativt kunne hjemmesiden naturligvis også få rettet disse
> ting, og programmerne kunne hente billedet i samme mappe som de
> selv ligger.

Siden er rettet. Den er resultatet af en smule hurtig indtastning i notepad,
derfor stibenævnelsen \.
Virker dog fint med både msie og opera.
Fik desværre compilet alle eksemplerne med stien c:\texture.bmp, og da
kildekoden til hver eksemple ikke findes længere pga. fælles base som bare
er rettet til hver gang.

---

Desilva skrev:

>Fik desværre compilet alle eksemplerne med stien c:\texture.bmp

Det er et lille problem.

--
Bertel
http://lundhansen.dk/bertel/   FIDUSO: http://fiduso.dk/

---

"Desilva" <SPAMOFFalamyx@softhome.net> wrote in message
news:af7phr$1vu2$1@news.cybercity.dk...

> En løsning, som foreslået af Thomas J andetsteds, er at forhindre dele af
> objektet (her stoffet) i at nærme sig andre dele af objektet mere end
> distancen x. Brugt til at forhindre ben i at gå gennem arme ol. i et andet
> project.
> Så vil stoffet kollidere med andre dele af stoffet istedet for at smutte
> igennem, men er det i praksis den mest effektive måde? Den virker på mig
> mere som en nem lappeløsning.

Det er generelt et beregningstungt problem. I praksis løses selvkollision
ofte ved at holde punkterne parvis væk fra hinanden. Den simple
implementation har kompleksitet O(n^2) og det er for langsomt, hvis der er
mange punkter. Så for at det skal gå hurtigt må man have en passende
datastruktur op at køre, f.eks. noget octree-agtigt, så man kan finde
punkter i nærheden.

En lidt nemmere løsning er at introducere constraints eller fjedre mellem
par af punkter, som har en nabo til fælles. På den måde introduceres lidt
stivhed i tøjet, og så har det ikke samme tendens til at penetrere sig selv.
D.v.s. hvis du har tre forbundne punkter A----B----C, så forbinder du A og C
med enten en fjeder eller en constraint der aktiveres når de to punkter
kommer for tæt på hinanden.

Men hvis det skal være helt 'ægte' selvkollision, så skal du have gang i
førstnævnte metode. Og hvis dine trekanter er store, så er det heller ikke
nok at kollidere punkter, så skal du også checke punkter mod trekanter.
Tungt, med absolut muligt.

Venlig hilsen
Thomas

---

> Det er generelt et beregningstungt problem. I praksis løses selvkollision
> ofte ved at holde punkterne parvis væk fra hinanden. Den simple
> implementation har kompleksitet O(n^2) og det er for langsomt, hvis der er
> mange punkter. Så for at det skal gå hurtigt må man have en passende
> datastruktur op at køre, f.eks. noget octree-agtigt, så man kan finde
> punkter i nærheden.

Ja.. som det er nu laver jeg sleti kke den slags optimeringer. Burde måske
egentlig prøve bare for at få denne simple simulation lidt op i fart. Nu
tester jeg derimod alle gældende constraints mod alle punkter i hvert
gennemløb.

> En lidt nemmere løsning er at introducere constraints eller fjedre mellem
> par af punkter, som har en nabo til fælles. På den måde introduceres lidt
> stivhed i tøjet, og så har det ikke samme tendens til at penetrere sig
selv.
> D.v.s. hvis du har tre forbundne punkter A----B----C, så forbinder du A og
C
> med enten en fjeder eller en constraint der aktiveres når de to punkter
> kommer for tæt på hinanden.

Så i praksis sætter du en constraint der holder en minimunsafstand mellem A
og C på x? Denne metode gør det vel stadig muligt for D at gå gennem A hvis
A---B---C---D da hvert led ABC og BCD kan dreje næsten helt rundt, men ikke
helt.. men hvis de begge folder samtidigt kan D så ikke gå gennem ved A?
Ex hvis vinklen der godtages er 90 grader (og i praksis er den vel en del
mindre) så kan 3 knæk føre rundt i et loop og stoffet går gennem stoffet..?

> Men hvis det skal være helt 'ægte' selvkollision, så skal du have gang i
> førstnævnte metode. Og hvis dine trekanter er store, så er det heller ikke
> nok at kollidere punkter, så skal du også checke punkter mod trekanter.
> Tungt, med absolut muligt.

Mnja.. Det skal nok ikke være så ægte. Er trods alt ikke en bro der skal
bygges.
I Hitman brugte i da bare den mere simple metode med constraints der
forhindre parvis punkter i at mødes?

---

Desilva wrote:
> Så vil stoffet kollidere med andre dele af stoffet istedet for at
> smutte igennem, men er det i praksis den mest effektive måde?
> Den virker på mig mere som en nem lappeløsning.

Hvordan simulere du stoffet?

Hvis du har en triangulering, således at hjørner i hver trekant
har en masse, og selve stoffet så består af en masse trekanter,'
der er bundet sammen med fjedre med en vis ligevægts længde.

Så kan du addere en ekstra frastøddende kraft, der afhænger af hvor
tæt centet af to trekanter er på hinanden. Det kræver til at begynde
med at du for hver iteration udregner kraften alle centre, og
udregner afstanden mellem dem, og hvis afstanden er lille så addere
du en frastødende kraft. Dette kan optimeres på en række måder.

Det ville måske også være en idee at addere en friktionskraft
for hver trekant, og i modsat regning af gennemsnitshastigheden
af de tre hjørner, derved bør du kunne emulere aerodynamiske
effekter.

Du kan også udregne vinklen mellem to trekanter og addere
krafter, der sørger for at denne er lille, du kan så kontrollere
stoffets stivhed ved at pille ved denne kraft.

--
Mvh. Carsten Svaneborg
Where do you not want to go tomorrow:
http://www.softwarepatenter.dk

---

> Hvordan simulere du stoffet?

I denne udgave bare som firkanter. Da jeg på et tidspunkt ville lave smooth
shading med pr. vertex normaler var min trekant struktur for bøvlet.
Stoffet er altså et lodret-vandret netværk hvor der er "vægte" i
knudepunkterne.


> Hvis du har en triangulering, således at hjørner i hver trekant
> har en masse, og selve stoffet så består af en masse trekanter,'
> der er bundet sammen med fjedre med en vis ligevægts længde.
>
> Så kan du addere en ekstra frastøddende kraft, der afhænger af hvor
> tæt centet af to trekanter er på hinanden. Det kræver til at begynde
> med at du for hver iteration udregner kraften alle centre, og
> udregner afstanden mellem dem, og hvis afstanden er lille så addere
> du en frastødende kraft. Dette kan optimeres på en række måder.

Er problemet med krafter, som er afhængige af afstand, ikke det man oplever
med fjedre og for store timesteps, nemlig at fra en frame til den næste har
to trekanter evt. bevæget sig meget tæt på hinanden hvilket giver en meget
høj frastødende kraft, som i næste iteration får det hele til at
eksplodere...?

> Det ville måske også være en idee at addere en friktionskraft
> for hver trekant, og i modsat regning af gennemsnitshastigheden
> af de tre hjørner, derved bør du kunne emulere aerodynamiske
> effekter.

Jeg har en simpel friktion på vægtene nu, men overvejer, som du siger, at
lave en pr flade.
Min tanke er at påvirke en flade med en kraft der er noget i stil med
F=k*v^2*cos(vinkel mellem normal og vindretning).
v er så vindhastigheden, eller ved "drag" faktisk fladens hastighed.
Ser det ikke nogenlunde rimeligt ud?

> Du kan også udregne vinklen mellem to trekanter og addere
> krafter, der sørger for at denne er lille, du kan så kontrollere
> stoffets stivhed ved at pille ved denne kraft.

Ja, jeg har faktisk lavet en simlel CAngularConstraint som håndterer
afslappede vinkler på 180 grader mellem BA og BC for A---B---C.
Det vil dog stadig kun gøre materialet mere stift, ikke forhindre kollision.
Der kan også være situationer med meget blødt stof som heller ikke må vikle
sig rundt i sig selv.

---

Desilva wrote:
> Er problemet med krafter, som er afhængige af afstand, ikke det man
> oplever med fjedre og for store timesteps, nemlig at fra en frame til den
> næste har to trekanter evt. bevæget sig meget tæt på hinanden hvilket
> giver en meget høj frastødende kraft, som i næste iteration får det hele
> til at eksplodere...?

Yeps. Det er et typisk problem at kraft integrationen kan
give "interessante" effekter. Et hurtigt hack er at bestemme
tidsskridtet som funktion af kraften, således at den maksimale
hastighedsændring er under en vis given konstant. Det ser grimt
ud for en realtime simulation, fordi den simpelthen går
langsommere når der sker kritiske ting, men præcisionen bliver
meget forbedret. Det er samtidigt meget simplere end at bruge
suffistikerede højreordnes integrationsmetoder.

> Min tanke er at påvirke en flade med en kraft der er noget i stil med
> F=k*v^2*cos(vinkel mellem normal og vindretning).
> v er så vindhastigheden, eller ved "drag" faktisk fladens
> hastighed. Ser det ikke nogenlunde rimeligt ud?

Hvis du tænker på luft som en masse partikler med en given
tæthed og alle med samme hastighedsvektor v så har du en
antal strøm partikler givet ved J = v* N/V Hvis disse rammer
en flade med areal A med normal n så er antallet af partikler,
der strømmer igennem fladen i løbet af dt: A n*J *dt = A*N/V v*n*dt

Lidt mere regne regne på impuls overførslen fra disse til fladen,
og man kommer til dit udtryk med passende defineret k.

--
Mvh. Carsten Svaneborg
Where do you not want to go tomorrow:
http://www.softwarepatenter.dk