Physics engine rates

[BoNI]

il Fullmode c'era anche prima.. ora

[mafredx]

il problema e' che, IMO, certi discorsi su dei forum come questo adrebbero evitati.

Il caro Manfredini sara' pure un grande a spingere forte sul pedale del gas, ma di matematica/fisica ne capisce poco, e neanche si puo' pretendere il contrario.

Come detto dai pochi che hanno veramente una base di conoscenza per parlare di queste cose (a memoria Miles e Desmo), la frequenza di aggiornamento NON DICE ASSOLUTAMENTE NULLA riguardo la CORRETTEZZA risultati ottenuti.

La dinamica e' tutta basata su integrali. Per risolvere un integrale si deve usare un "integratore", cioe' un algoritmo numerico capace di "campionare" la situazione.

A scuola tutti abbiamo imparato (o dovremmo aver imparato) la formula del moto uniformemente accelerato.. ci insegnano questa:

S=1/2*A*T^2+V0*T

Ma questa e' una soluzione arrotondata.. la formula puo' essere espansa all'infinito (vedi. serie di Taylor) e resa, ad ogni espansione, piu' accurata.

I sim di veicoli su gomme hanno tutti da risolvere un problema base: un moto oscillato di corpo vettura e sospensioni. I moti oscillatori con molla/ammortizzatore (cioe' tutto quello che accade in una sim) hanno la tendenza a "esplodere" se l;integratore non e' accurato o se l'integratore non gira ad una frequenza adeguata.

Quindi, in poche parole, ogni sviluppatore sceglie quello che reputa un bilanciamento accettabile fra:

- Frequenza di calcolo

- Complessita' di calcolo

- Accuratezza del risultato

Ora, la tabella dell OP, ci da solamente una delle 3 variabili di sopra. Il parametro "accuratezza del risultato" e' totalmente soggetivo, come dimostra bene Manfredini.. l'unico pilota "reale" che io conosca che consideri rFactor un prodotto attendibile.

Quindi, in conclusione, senza sapere COSA FANNO i vari motori fisici ad ogni integrazione, la tabella proposta non dice assolutamente nulla di interessante.

In una delle versioni di test della 1.0.3 ho provato ad introdurre un integratore piu' leggero e veloce.. per combattere l'instabilita' ho dovuto subito alzare la frequenza a 500Hz.. le prestazioni erano cmq superiori (in termini di tempi di calcolo, non di accuratezza) ma i tester hanno riportato "gomme che sembrano staccarsi dalla sospensione di qualche mm quando si prende un cordolo". Per stabilizzare il comportamento sarei stato obbligato ad alzare verso i 1000Hz. Nel mio caso ho preferito ritornare al vecchio integratore e mantenere la frequenza a 333Hz con risultati numerici piu' attendibili.

Chiudo con il dire che, la frequenza di aggiornamento e' un numerino da cambiare e non richiede poi tanta tecnologia. Per i sim di F1 professionali netKar PRO gira oltre i 1000Hz.. ma li la cosa e' dettata dal desiderio di ottenere il massimo dalle piste in laserscan con pochi cm di accuratezza.

A 300 Km/h la macchina percorre ben 83 metri al secondo. Con 1000Hz, la posizione della gomma fa piu' di 8 cm per step... rendendo, di fatto inutile, una rappresentazione della pista cosi' accurata. Ma il modello matematico RIPRODUCE NUMERICAMENTE risultati ESTREMAMENTE vicini, sia a 333Hz che a 1000,2000Hz.

questa

[Guest Miles Gloriosus]

...sintetizzando Kunos...

Come detto dai pochi che hanno veramente una base di conoscenza per parlare di queste cose , la frequenza di aggiornamento NON DICE ASSOLUTAMENTE NULLA riguardo la CORRETTEZZA risultati ottenuti.

Quindi, in conclusione, senza sapere COSA FANNO i vari motori fisici ad ogni integrazione, la tabella proposta non dice assolutamente nulla di interessante.

il modello matematico RIPRODUCE NUMERICAMENTE risultati ESTREMAMENTE vicini, sia a 333Hz che a 1000,2000Hz.

...questo l'ho scritto io, non sono attendibile come Kunos ma sono convinto che sia giusto anche perch

Edited October 8, 2008 by Miles Gloriosus

[Guest Space Marine]

Io non dico niente

....lukro sgranocchiando popcorn......

Tanto la tua firma parla per te

Cmq io una utilit

[kunos]

...in parole povere e da igniorante sempre se io nn ho problemi di gomme che si staccano ecc a 500hz e meglio della stessa soluzione a 333hz ?

decisamente si. lo stesso motore, se spinto a frequenze piu' alte genera una qualita' numerica superiore.

[kunos]

Io non dico niente

....lukro sgranocchiando popcorn......

Sul forum di lfs si parlava anche del fatto che alcuni valori influenzassero la fluidit

[Guest Xana]

la presa della corrente e' a 50 Hz....scarsa...l'Enel poteva fare di piu'

[Guest AsterX]

la presa della corrente e' a 50 Hz....scarsa...l'Enel poteva fare di piu'

Muoio!

Grazie a Miles e Kunos per gli interventi tecnici, sempre chiari ed efficaci.

[elwood]

io non so se ridere o piangere

gli hertz sono una impostazione scelta dal programmatore che decide a quale velocita' il proprio simulatore legge megli i dati. un valore piu' alto non e' indice di maggiore velocita'.

un pentium II del 98 portato a 3Ghz non va quanto un quad core del 2008 a 2Ghz

MA CI VUOLE TANTO PER CAPIRLOOOOOOOOOOOOOOOOO

No davvero, per un'attimo ho seguito il thread, poi mi son visto Paura e Delirio a Las Vegas ed era decisamente meno grottesco.

Non me ne vogliate.

[darios81]

Quoto quello che dicono Miles e Kunos in toto.

Ma poi da quanto in qua gli Hertz ( le frequenze ) sono divenute in ambito informatico un metro di paragone assoluto per calcolare l'efficenza di un algoritmo ( come in questo caso ) o di un Hardware.

Cio' che conta non e' la velocita' , ma come lo si fa.

Sapete studiando algoritmi dalla mattina alla sera , si capiscono tante cose , come che mancando certe basi si associ l'agoritmo ad un pezzo di programma che restituisce dei valori.

Si puo' avere il computer piu' efficente e veloce del mondo , ma se l'algoritmo non e' buono , fara' sempre pena a differenza di uno invece efficente.

Ma una cosa , l'algoritmo che si realizza per la gestione dei simulatori , fa sempre parte di programmazione dinamica ?

Oppure alcuni usano anche un algortimo tipo greedy ? ( anche se non penso )......