Wednesday, July 25, 2012

Still Alive

I'm not dead, i'm just working hard on autopilot :)

Non sono morto, e' che sto lavorando intensamente per rendere l'autopilota preciso. Sembra una banalita' ma la semplice sequenza Allineati, Accelera, aspetta, decelera fino a fermarti e' estremamente complessa, o meglio lo e' riuscire far si' che sia sufficientemente precisa, specie quando a priori non sono noti i frames al secondo.


Se devo andare da A a B in un sistema 3D, fatta ipotesi pure che inizialmente io sia fermo, devo:


- Ruotare fino a puntare B- Accelerare diciamo fino a meta' strada- Frenare.Il primo punto l'ho realizzato e funziona bene.Anche il secondo, che e' piuttosto banale.Il difficile e' proprio il frenare. Cioe': nel caso dell'accelerazione costante, detto t il tempo che e' intercorso tra un frame all'altro la velocita' nuova e' banalmente v2=v1+a*t dove v1 era la velocita' precedente.Ma per la decelerazione? non va bene semplicemente considerare a "negativo" perche' non trattasi di frenata ma bensi' di accelerazione nel verso opposto. Una formula migliore e' v2=v1*e^(-f*t). I guai iniziano pero' non appena inizio a calcolare lo spazio di frenata con una simile equazione. integrando ottengo una formula che va bene sul continuo, il gioco pero' funziona per intervalli discreti, ovvero gli intervalli di tempo tra un frame e l'altro, e pertanto la formula matematica che ottengo mi da un risultato approssimato, tanto piu' approssimato tanto piu' gli fps sono bassi. Col rischio che su un pc buono l'algoritmo funzioni bene, su un pc obsoleto l'algoritmo addirittura non faccia a tempo a frenare.


Stay Tuned..

4 comments:

Anonymous said...

una cosa del tipo TweenLite (http://www.greensock.com/tweenlite/) ma in uno spazio 3d ?

PdG said...

Il punto e' questo.

Se devo andare da A a B in un sistema 3D, fatta ipotesi pure che inizialmente io sia fermo, devo:

- Ruotare fino a puntare B
- Accelerare diciamo fino a meta' strada
- Frenare.

Il primo punto l'ho realizzato e funziona bene.
Anche il secondo, che e' piuttosto banale.
Il difficile e' proprio il frenare.
Cioe': nel caso dell'accelerazione costante, detto t il tempo che e' intercorso tra un frame all'altro la velocita' nuova e' banalmente v2=v1+a*t dove v1 era la velocita' precedente.
Ma per la decelerazione? non va bene semplicemente considerare a "negativo" perche' non trattasi di frenata ma bensi' di accelerazione nel verso opposto. Una formula migliore e' v2=v1*e^(-f*t). I guai iniziano pero' non appena inizio a calcolare lo spazio di frenata con una simile equazione. integrando ottengo una formula che va bene sul continuo, il gioco pero' funziona per intervalli discreti, ovvero gli intervalli di tempo tra un frame e l'altro, e pertanto la formula matematica che ottengo mi da un risultato approssimato, tanto piu' approssimato tanto piu' gli fps sono bassi. Col rischio che su un pc buono l'algoritmo funzioni bene, su un pc obsoleto l'algoritmo addirittura non faccia a tempo a frenare.

Unknown said...

Il fatto รจ che deve essere indipendente dai frames. Usa solo il tempo...

PdG said...

Il punto e' questo Andrea: ad ogni inizio (o fine) rendering di un frame viene chiamata la funzione di update. Li' dentro va messo tutto il codice che aggiorna la posizione e le caratteristiche degli oggetti.
Quindi ad esempio, in questa funzione faro' posizione = posizione + velocita*tempo_trascorso_dallultimo_frame.
Questa cosa e' necessaria affinche' l'esecuzione del gioco sia identica su un pc potente o su un pc lento, altrimenti avresti il classico effetto di "filmato accelerato" che si ottiene facendo andare la pellicola piu' veloce del normale.