/ Forside / Teknologi / Udvikling / Delphi/Pascal / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
Delphi/Pascal
#NavnPoint
oldwiking 603
jrossing 525
rpje 520
EXTERMINA.. 500
gandalf 460
gubi 270
DJ_Puden 250
PARKENSS 230
technet 210
10  jdjespers.. 200
Problem med accelerationsprogram
Fra : Klaus Petersen


Dato : 27-04-03 19:51

Hej NG.

Jeg har lavet et program, der kan simulerere en flytning af et objekt fra A
til B med en acceleration og en deacceleration.

Programmet er baseret på beregningerne beskrevet her -
http://makeashorterlink.com/?Z45A63B54

Programmet tegner flytningen som en værdi mellem 0 og 1 (parametrisk) - dvs.
0 er ved start positionen og 1 er ved slut positionen.

Det hele skal bruges i et størrere projekt, hvor det er et stykke grafik der
flyttes på den måde.

Og det er også meget fint alt sammen. MEN.....

.... det driller en lille smule. Simulationen ender ikke med en parametrisk
position på 1.000 (eller meget tæt derpå) - som den burde! 1.0 er jo slut
positionen.

Så når jeg udfører animationen med den kode der, springer den til sidst
fordi den ender på 0.993 (jeg sætter positionen til slutpositionen til
sidst).

Kan nogen hjælpe mig med at finde ud af hvor problemet ligger?

Det er jo nok en eller anden unøjagtighed i beregningerne et eller andet
sted.....

Jeg har lagt programmet ud så i kan se det og sourcekoden der til - det er
lavet i Delphi 6.

http://62.199.203.164/eksperten/acceleration.zip

Mange tak på forhånd for hjælpen.

Klaus.



 
 
Thomas Eg Jørgensen (27-04-2003)
Kommentar
Fra : Thomas Eg Jørgensen


Dato : 27-04-03 21:09

Klaus Petersen wrote:
> Det er jo nok en eller anden unøjagtighed i beregningerne et eller
> andet sted.....

Med risiko for at blive jordet på min fysik og/eller matematiske viden vil
jeg dog forsøge mig:

Jeg har meget svært ved at overskue hvad A, B, C, M, pp, pb, pc og alle de
andre meget lidt sigende variabler gør og betyder. Men ud fra:
http://makeashorterlink.com/?Z45A63B54 kan jeg tyde noget i retning af en
integration du forsøger at udføre med trekantsberegning? Hvis det er
tilfældet vil du altid få en fejlmargin. Og i såfald ligger din
"unøjagtighed" i de formler du anvender. Ideelt set skal du sætte dine
"frames" til uendelig så burde du teoretisk set få 1.0000 i sidste ende når
den nu "er nået til uendelig".

Hvis du øger opløsligheden, fra 400 til f.eks. 400.000(og ændre din kode så
den ikke gentegner for hvert billede så vil du se at din funktion kommer
noget tættere på 1, noget i retning af 0.999999995 eller noget i den stil...

Nogen konkret løsning kan jeg ikke give dig, men hvis ovenstående ellers er
korrekt så må du finde den gyldne middelvej. Opveje præcision vs. hastighed.
Ønsker du høj præcision skal du have høj opløslighed=>mange
beregninger=>langsomt og visa versa...

Håber det hjælper lidt...

PS: Hvis jeg må spørge: hvad skal du bruge det til? Fysiske simulationer er
altid spændende

--
MVH Thomas Eg Jørgensen

** OE Quotefix: http://home.in.tum.de/~jain/software/oe-quotefix/ **
** Kandu.dk-brugere betragtes som useriøse og ignoreres! **



Klaus Petersen (27-04-2003)
Kommentar
Fra : Klaus Petersen


Dato : 27-04-03 21:39

> Jeg har meget svært ved at overskue hvad A, B, C, M, pp, pb, pc og alle de
> andre meget lidt sigende variabler gør og betyder. Men ud fra:
> http://makeashorterlink.com/?Z45A63B54 kan jeg tyde noget i retning af en
> integration du forsøger at udføre med trekantsberegning?

Du kan godt ud fra det link der, for det er netop en implementation baseret
på den side.
Men det er i hvert fald noget integration ... men helt nøjagtig hvad han gør
og hvorfor ved jeg ikke.

> Hvis det er tilfældet vil du altid få en fejlmargin.

Det lyder ikke godt.

> Og i såfald ligger din "unøjagtighed" i de formler du anvender. Ideelt set
skal du sætte dine
> "frames" til uendelig så burde du teoretisk set få 1.0000 i sidste ende
når
> den nu "er nået til uendelig".

Ja, men det ville ikke kunne fungere i praksis

> Hvis du øger opløsligheden, fra 400 til f.eks. 400.000(og ændre din kode

> den ikke gentegner for hvert billede så vil du se at din funktion
kommer
> noget tættere på 1, noget i retning af 0.999999995 eller noget i den
stil...

Ja ... nøjagtigheden stiger tydeligvis ved flere frames.

> Nogen konkret løsning kan jeg ikke give dig, men hvis ovenstående ellers
er
> korrekt så må du finde den gyldne middelvej. Opveje præcision vs.
hastighed.
> Ønsker du høj præcision skal du have høj opløslighed=>mange
> beregninger=>langsomt og visa versa...

Argh... det er svært at gå på komprimis her. For det skal både være hurtigt
og præcist. Så gode råd er dyre nu.

> PS: Hvis jeg må spørge: hvad skal du bruge det til? Fysiske simulationer
er
> altid spændende

Hehe.. så er dette her knap så spændende. Det er til 2D/Game engine, som er
entitets baseret. Een af de funktioner jeg gerne vil have med er denne
hersens accelerede flytning.

Når den er færdig skal man være i stand til at lave flotte grafiske
præsentationer/applikationer/spil på forholdsvis kort tid

Tak for dit svar i øvrigt... jeg er da blevet en helt klogere på problemet
nu.



Klaus Petersen (27-04-2003)
Kommentar
Fra : Klaus Petersen


Dato : 27-04-03 22:56


Lige for at følge op. Jeg har faktisk "løst" problemet.

> Men ud fra:
> http://makeashorterlink.com/?Z45A63B54 kan jeg tyde noget i retning af en
> integration du forsøger at udføre med trekantsberegning?

Ja, det er en integration af en art.

> hvis tilfældet vil du altid få en fejlmargin

Ja, kun hvis du kunne udregne integralet t=uendelig ville du få en præcis
værdi.

> Og i såfald ligger din "unøjagtighed" i de formler du anvender.

Det er korrekt, men det jeg har fundet ud af er, at den unøjagtighed, der
er, overhovedet ikke er så stor som 0,007!

Den er nærmere 0,0000166667 for eksemplet med 400 frames.

Problemet var en programmeringsfejl... lille men betydelig:

pa & pb bliver jo sat undervejs - i interval 2 bliver pa brugt til at
udregne pb og i interval 3 bliver pb brugt til at udregne pc.

Så hvis pa og pb kun er næsten korrekte.... så bliver pc jo også kun næsten
korrekt

Det er galt hvor jeg finder ud af hvilket interval den er i:

Sådan her skal det være:

if (interval=2) and (t > (A+B)) then interval := 3;
if (interval=1) and (t > A) then interval := 2;

interval 1 er [0, A]
interval 2 er ]A, A+B]
interval 3 er ]A+B, A+B+C]

Så bliver præcisionen god nok.



Richard Thordsen (29-04-2003)
Kommentar
Fra : Richard Thordsen


Dato : 29-04-03 21:52

Klaus Petersen skrev i meddelelsen ...
>Programmet tegner flytningen som en værdi mellem 0 og 1 (parametrisk) - dvs.
>0 er ved start positionen og 1 er ved slut positionen.


Du kan udtrykke det hele ved følgende funktion:

f(x) = x^2( -2*x + 3 ) for x = [0..1]

I dette interval går f(x) netop fra 0 til 1 . Hastigheden er 0 i start- og slutpositionen, hhv. x = 0 og x = 1 og størst
i midterpositionen, x = 1/2 . Desuden er accelerationen lineært aftagende fra positiv til negativ (fra +6 til -6 ).

Hvis flytningen så skal foregå over n antal gange sætter du x = i/n hvor i går fra 0 til n .


Søg
Reklame
Statistik
Spørgsmål : 177580
Tips : 31968
Nyheder : 719565
Indlæg : 6409084
Brugere : 218888

Månedens bedste
Årets bedste
Sidste års bedste