Search the Community

rFpro has developed the most accurate virtual replica of famous Japanese road network, the Shuto Expressway. Our latest digital twin enables the generation of thousands of test scenarios that are too dangerous and costly to perform in the real world This digital twin enables the creation of accurately labelled training data which is critical to training autonomous vehicle artificial intelligence. Learn more at rfpro.com

Studio397 ora sviluppa e distribuisce il gioco, rFactor2. rFpro è una società completamente indipendente, con zero collegamenti a Studio397 o al gioco rFactor2. Alcuni anni fa la base di codice sorgente si è divisa tra il motore di gioco rFactor2 e il motore di rendering utilizzato qui in rFpro. Il codice è stato sviluppato in modo completamente indipendente per molti anni. rFpro è completamente focalizzato sulla simulazione fisica per il mercato dell'ingegneria professionale. rFpro non è la versione professionale di rFactor. La base di codice di rFpro è completamente l'IP di rFpro.

Mi sa che mi conviene partire dall'ultima domanda per rendere più facili le risposte. Fare un sim scriptato è più semplice e meno complesso sia nella costruzione del mondo fisico sia per la gestione hardware del utente che usa quello stesso sim. L'evoluzione dei sim alla "vecchia maniera" è di fatto morta quando è arrivato rF2 e credo sia dovuto in principal modo, per l'appunto, ad un discorso legato alla snellezza del software, per capacità pratiche di chi crea il software e (credo) per un discorso legato al quanto può importare l'avere l'analogicità assoluta comparata ad altri fattori quali multiplayer od opzioni di quest'ultimo, grafica etc. Spero che non parta un megaflame della madonna...faccio esempi pratici per il 2° e il 3° punto. Casillo è un SIGNOR programmatore. Ma non l'ha dimostrato (secondo me) tanto con AC o ACC. Lo ha dimostrato (sempre secondo me) con netKar. Proporzionalmente a netKar, sono della idea che, AC, doveva continuare con un sim che non doveva cadere nella trappola della necessità dello script. Conoscendo nKP e provando AC ne rimasi un pò deluso (rF2 era già in giro da più di 1 anno mi pare e già stavo sbattendoci la testa alla grande). Col senno di poi dico però che probabilmente avrebbe fallito miseramente lato vendite. Gli ISI quando hanno fatto rF2 hanno fatto ciò per cui erano già abituati. Forse nel creare rF2 non hanno tribolato come invece ha dovuto fare Casillo (per fare un esempio) perchè rF2 è una specie di porting di quello che era rFPRO di quei tempi. Per capacità pratiche intendevo questo. Non è che addito un Casillo come incompetente o gli ISI come dei geni. Se una persona è un inventore della madonna non posso dirgli che è stupido nei confronti di uno che lavora alla NASA...magari può essere anche il contrario. Il terzo punto un pò si piega da se...aumentare il livello di analogicità di un sim porta a richiedere conoscenze che non sono tutt'ora standard per ogni simdriver che guida da 5 anni alle volte. Chi usa rF2 si è trovato spesso a urlare contro il monitor non capendo cosa stava succedendo...finchè poi non capisci che poi lo stupido è quello che urla perchè trovi i "perchè" e ti vergogni immensamente della tua ignoranza (e io tutt'ora mi ritrovo a dire a me stesso spesso che sono ignorante quando provo qualcosa che non conosco su rF2 e capisco l'errore). Un esempio? In quanti sanno spiegare usando un linguaggio terra-terra come funziona e cosa fa una terza molla? Però la terza molla fa qualcosa di VERAMENTE importante e vitale anche solo per stare in pista in certi frangenti. In altre parole un sim ultra hardcore porta a restringere ulteriormente il proprio parco utenti perchè non tutti son disposti a (cercare di) imparare tutto del setup o delle opzioni possibili e utilizzabili del sim. La stragrande maggioranza preferisce l'immediatezza, l'accendere il pc e farsi una gara entro 10 minuti. Già rF2 è totalmente fuori da queste possibilità quindi figuriamoci un simil-rFPRO di questi giorni. Quando parlo di sim scriptato parlo di quei sim che hanno un engine fisico che è inferiore a rF2 o che è semplice di natura al punto che, purtroppo, incappa in certi problemi che possiamo chiamare glitch, errori fisici, troppa semplicità di parametri e così via. Non è detto che siano cose visibili fin dal primo giorno di vita del sim...infatti, per come la vedo io, AC non era scriptato inizialmente. Farò esempi dopo. Questi problemi vengono risolti tramite script, procedure, sottoprocedure. Queste vanno a modificare un certo avvenimento (che è troppo sbagliato per non essere visibile) andando a fare un discorso del tipo - "stà succedendo questo" - "intervengo e sovrasto il modello fisico" - "la macchina fa quello che ho deciso io da sviluppatore". Il tutto a prescindere da circuito in laserscan e dati ufficiali (per quanto possano essere numericamente e per quanto LO possano essere) della vettura. Perchè scriptare e non agire direttamente sulla fisica? Perchè è più facile, veloce e perchè per riscrivere un intero modello fisico (penso) ci vuole lo stesso tempo di rifare da 0 un altro sim. Partiamo con qualche esempio. Se si prova a salire su un cordolo bello alto in stile Nordschleife dritto per dritto quando si è a velocità folli tipo oltre i 200 km/h che cosa ci si aspetta possa succedere? Che la macchina spicchi il volo con destinazione la stazione orbitante spaziale giusto? Se provate a riscaricare una vecchia beta di AC potrete constatare invece che salirci non vuol dire nemmeno vedere un minimo volo...a volte non si staccavano da terra nemmeno le ruote. Passi il discorso prettamente "visivo" della cosa ma andiamo ad analizzarlo da un punto di vista della macchina in se per se. Le sospensioni di AC di quella beta come kaiser lavoravano allora? Erano finte? Le loro regolazioni come si interfacciavano al sim in ambito fisico? Posso, da ignorantone, pensare che allora i rimbalzi e le compressioni veloci erano buttate sul setup là per dire che c'erano? Non credo...o almeno lo spero...però se le sospensioni funzionavano a livello fisico, simulativo e con realismo sul asfalto, senza ombra di dubbio erano totalmente smignottate quando si aggrediva un cordolo o quando si incontrava una sconnessione. A riprovare oggi AC invece il realismo, la simulazione, tutto l'ambito fisico sul fare una prova mirata a questo esempio dà un altro risultato. Là non è stata riscritta la fisica. E' stato aggiunto "un qualcosa" che si attiva, subentra alla fisica base del sim, e da un risultato diverso da quella che è la fisica base. Questo è il caso del sim meno complesso di rF2 che è scriptato. C'è poi il sim scriptato nato "semplice" e che ha dovuto per forza di cose affidarsi allo scripting. Esempio supremo? iRacing. iRacing stà a Nascar 2003 come Automobilista stà a rFactor. iRacing è per l'87% del codice (dati loro eh...niente flame per carità) Nascar 2003...chi non lo conosce vada sul tubo. Chi ha provato il titolo di Kaemmer ha sicuramente sperimentato un certo comportamento (che fa incacchiare) di OGNI veicolo del sim. Guidi, hai grip, la tieni, la macchina scivola per un istante, poi MUORI. Non la riprendi mai. Se la riprendi devi pregare di aver registrato la cosa per postarla su youtube e fare il gradasso con gli amici. Nella realtà l'unica macchina al mondo che si comporta come iRacing quando si perde grip è la Nascar. Partendo da un sim che emulava solo auto Nascar loro han cominciato a creare una vettura alla volta ma sempre partendo da una Nascar. Il motore fisico era quel che era quindi hanno cominciato a "barare". Come? Sapendo la soluzione dell'equazione (cioè il comportamento della macchina) hanno riscritto l'equazione stessa. In altre parole hanno scriptato una macchina Nascar per far sì che, oltre ad aver un modello 3d diverso, ha una tenuta diversa. Prestazioni diverse. Di fatto una 488 su iR è una Nascar ridisegnata e scriptata che sta in pista e si guida come dovrebbe essere la 488 vera. E ora passiamo al esempio supremo di script di iR...cioè le gomme. Tutti noi conosciamo le 3 zone di temperatura della singola gomma giusto? Già nei sim di vecchia generazione come rF, GTR2, netKar etc queste zone sono effettivamente come 3 ciambelline attaccate l'una con l'altra e fanno il loro lavoro letto ed interpretato dal sim ok? Uno pensa che visto chè c'è anche su iRacing, è cosa che funziona allo stesso modo. Sbagliato. Su iRacing ciò non esiste. E' simulato. La gomma è un monoblocco e la divisione in tre zone è simulata. Una simulazione nella simulazione. Non puoi ragionare sul setup pensando alla vecchia regolina dei 5° davanti e 2,5° dietro. Ci sono auto su iRacing che devi settare con 22° gradi di differenza tra interno ed esterno per arrivare alla soluzione "giusta". Guidi, ti impegni, usi motec, ti incacchi, poi ti arrendi, spendi 50 euro annuali e ti compri i setup da PureDriving. Oppure entri nella modalità Monkey Island del "prova-tutto-con-tutto" e ci arrivi. Fintanto che guidi una MX-5 ok...hai da toccare poche cose...ma se devi settare una Formula su iR sei stramaledettamente fregato. Se non metti la gomma a suo agio, su iR, prima o poi perdi grip per qualche motivo, scivola l'auto e vai a muro. Negli anni ci son stati una miriade di "new tires model" per iR...ma in realtà la gomma del primo rF è fantascienza pura paragonata alla attuale gomma del titolo americano. Per quanto scriptano le macchine e per quanto siano BRAVISSIMI a farlo, purtroppo rimane il limite del engine di base che spinge il sim. E là è da fare di necessità virtù. iR lavora benissimo per una miriade di tipologie di vetture. Per altre un pelino meno. Per altre ancora quel sim è il peggiore al mondo in assoluto. Fintanto che si deve guidare una macchina che è l'incarnazione della pulizia allora iR dà il suo meglio. E' preferibile pure a rF2 secondo me. Quando è da guidare le auto che dovrebbero essere quelle più facili da simulare invece già pecca un pelino. Se devi guidare una macchina in manuale o vintage iR è un CANCRO. Dico solo Lotus 49...costringere un uomo a guidarla per me è come barattare una pena di morte vera. E sono un simdriver votato al vintage. Dovrei saper gestirla, settarla, o quantomeno saperci stare in pista. Guidare la Lotus di Senna di AC a Monaco col 100% del boost è una pisciatina rispetto al solo sopravvivere passeggiando con la 49 di iR. Passi che sia un paragone ardito quello tra auto diverse che non centrano una mazza ma vale a maggior ragione il rapporto con la 49 di AC e la Brabham del '66 di rF2. Anche ACC probabilmente è scriptato. Non posso esserne sicuro al 100% ma lo deve essere per forza...è difficile da vedere per colpa di quello che è la dinamica delle vetture in questione. Fintanto che si prova un sim che dà la possibilità di guidare una macchina non troppo potente, magari senza aerodinamica in stile monoposto, là siamo nel caso in cui si può vedere la profondità del livello di fisica di un sim. Questo per il semplice fatto che i fattori in ballo sono pochi e non "inquinati" da effetti esterni. Ma nel momento in cui le macchine sono caccia F15 che non possono stare in aria senza l'ausilio di 30 computer interni la cosa si fa difficilina. ACC non è molto valutabile sotto un punto di vista fisico e non si capisce bene quando finisce la fisica e quando comincia l'eventuale script. Tempo fa il buon Aris ci ha spiegato come i sim vanno a barare con gli aiuti elettronici (cosa che vale anche per rF2) su quello che è il comportamento di una vettura. Tra controllo trazione e ABS è facile rendere credibile e seguire un concetto di realismo se si è bravi programmatori. Vien da sè che la scelta di fare ACC con una unica tipologia di macchina guidabile è semplicemente stata una genialata senza paragoni. Se ti arriva il ragazzino che ti dice che gli sa più simulativo ACC rispetto a rF2 ci stà. Discorso soggettivo, ma anche per me ACC fa un IMMANE bella figura. E' per questo che lo scripting non è il male assoluto. Se fatto bene è si arriva al realismo, lo scripting, è forse soluzione migliore al vecchio modo di creare sim. Ma è limitata su sim che vanno a simulare più cose (tipo iR) perchè tanto la magagna del limite del sim la trovi e se tiri la coperta da una parte scopri da un'altra. E se anche i maestri dello script non possono fare nulla per certe categorie di auto, si capisce che non è la soluzione più "elegante". Hai menzionato ALMS2. Ad essere onesto io non l'ho preso e non credo lo prenderò a breve termine. Ma conosco abbastanza bene il titolo da cui deriva per cui posso dirti, secondo me, perchè ti piace ALMS2. Il titolo Reiza deriva in toto da PC2. PC2, per certi versi, è un sim dalle immani possibilità sacrificate sull'altare della vendibilità. Non ha una engine fisico paragonabile a quello di rF2 ma ha delle chicche che fino a pochissimi anni fa erano prerogative uniche del titolo 397. Parlo di un modello di gomma che abbandona il modello in stile "3 ciambelline" per andare a copiare, non allo stesso livello però, quello di rF2. Inoltre c'è il discorso del telaio vettura che non è più un monoblocco indistruttibile ma deformabile quando sottoposto a forze come in curva ad esempio. Già solo queste 2 feature danno quel qualcosa che ti piace come su rF2. Il motivo è presto detto. Non sono cose prettamente visibili ma grazie al tatto, tramite FFB, le senti sempre. Sono perennemente a contatto con i tuoi sensi e anche un simdriver di primo pelo può accorgersi della differenza tra PC2/ALMS2 e un sim come AC o iR. Purtroppo però per quanto riguarda PC2 anche un simdriver che non ha mai provato rF2 capisce che c'è qualcosa che non va al sim. I Reiza secondo me si son fatti 2 calcoli e han deciso di optare per questo sim perchè loro son dei MAESTRI nel ritoccare parecchi difetti di PC2. Hanno le capacità di fare un FBB che spacchi e andranno a lavorare sulla singola fisica delle vetture in modo migliore di come son fatte le auto su PC2 (sim in cui qualche macchina dà l'idea di correre con un simil-rF2 mentre in altri casi è un cancro assoluto...cosa che puzza in stile iR e che dà l'input per arrivare a quale è la vera differenza del mondo fisico tra rF2 e PC2). Però rimane il motore fisico del sim (che va sempre considerato a parte rispetto a quello delle vetture sia ben chiaro). In un modo o nel altro ci si è fermati con la politica di sviluppo di un sim per come ci ha insegnato la ISI. Purtroppo solo la ISI, secondo me, è capace di battere se stessa. In fin dei conti se andiamo a vedere i sim che fisicamente hanno rotto le ossa alla concorrenza usavano tutti un loro engine. Basti pensare già a F1 2000 della EA, F1 Challenge, i due GTR (con motore ritoccato dai SimBin), rF, Superleague Formula...quale sim era meglio di questi negli anni in cui furono distribuiti? La realtà è che negli ultimi 20 anni c'è stato "monopolio" per sim la cui caratura lato fisica era superiore. E ora che non ci sono più loro (e spero tanto che tornino) gli altri, o si sono affidati ad altre soluzioni o, tutt'ora, non sono capaci di fare un motore fisico migliore del Isiengine2.5 . E se anche la capacità c'è, è da appurare quanto può vendere un titolo del genere e quindi il desiderio di fare un sim in stile rF2.

Ehhhhh il buon Crammond comincia a essere anzianuccio. Passi il fatto che non era neanche un amante del mondo che lui stesso ha creato. Temo si possa rischiare un effetto Molyneux se capite cosa intendo. Genio assoluto nei primi titoli e decelebrato mentale negli ultimi per molte scelte e lavori. Il mio sogno bagnato è che la ISI cacci fuori un ISIengine3.0 ripreso dal attuale rFPRO da mettere in vendita ad altre software house. A quel punto il sim sarebbe ancora più hardcore e non credo che andrebbe a rubare così tanta utenza altrove...tranne che per rF2 che a quel punto morirebbe per come è morto ora rFactor.

AB Dynamics have just released a video of their driving simulator being used to test ADAS systems in rFpro. Involving human test drivers earlier in the development cycle, by testing in simulation, saves time and money and helps ensure consumer acceptance. This video shows the new Virtual Millbrook Proving Ground, the result of a year long collaboration between rFpro and Millbrook to help create a road-map leading to the regulatory approval of autonomous vehicles.

Aris Vasilakos della Kunos Simulazioni ha risposto direttamente su Facebook al dubbio di un utente: Ecco qui di seguito la sua completissima risposta: Ciao a tutti Cerchiamo di mettere un po’ di ordine sul discorso simulatori pro/simulatori videogame. Innanzitutto chiariamo subito la questione hardware. Pedali, volanti e attuatori per motion platform su simulatori usati da case automobilistiche, sono chiaramente costosissimi, di alta qualità, spesso presi direttamente dalle auto vere e soprattutto settati in modo realistico con precisione. Di conseguenza, se ad esempio, il costruttore Sto arrivando! dalla telemetria, che un pilota esercita una pressione di 70kg sul pedale del freno per una frenata adeguata, la pedaliera del simulatore sarà regolata adeguatamente, senza scuse del tipo “eh ma così è troppo duro, preferisco la pedaliera del g27” (per dire ) Se per il freno magari i valori vi sorprendono, allora forse vi sorprenderà ancora di più sapere che a livello di FFB , di solito i piloti preferiscono una taratura molto debole, sia sulla auto vera che sul simulatore… vanno regolati anche qui adeguatamente. Sul discorso motion platform, tornerò più avanti. Discorso software. Diffidate di chi vi dice che i costruttori usano rFactor, o Assetto Corsa, o iRacing. I costruttori, usano di solito rFactor PRO. Qualcuno una versione particolare dell’engine AC, qualcuno un software di simulazione dall’Olanda che adesso non ricordo il nome, e qualcun’altro ancora delle versioni dedicate di programmi come simulink, mathlab etc. (ma che sono poco compatibili con asset grafici avanzati e allora poco usati per la grafica) TUTTI, ma proprio tutti NON usano il motore fisico di rF, AC, iR etc. Come mai? Cosa usano? Quello che usano è così più avanzato? Si e no. Andiamo con ordine. Cominciamo da rFactor PRO. Questo software è ormai seguito e realizzato da una società indipendente dagli ISI, creatori di rF originale. C’è scambio di tecnologia ma è del tutto e per tutto una azienda diversa. La sua forza consente nel permette agli ingegneri di utilizzare il motore grafico, sonoro, collisioni col terreno fra auto etc, asset grafici (piste, auto 3D etc) ed eventualmente AI e multi di rFactor, con collegamente esterni di solito via UDP, con qualsiasi software matematico/simulativo ogni costruttore usa. Di solito mathlab e simulink. Questi sono programmi ingegneristici di alta fedeltà e grande complessità, che vengono usati dagli ingegneri per creare un modello matematico che simula diversi elementi di un veicolo. Essendo questi dei software standard usati dalla stragrande maggioranza dei centri di sviluppo e progettazione delle case, permettono di implementare diversi sistemi in modo completamente separato ed autonomo. Ci sarà un modulo per la simulazione delle gomme, uno per la simulazione della sospensione, uno per l’aero, se arriva domani la Bosch con un nuovo modulo ABS, allora può semplicemente attaccare tutta la logica e così via. Di fatto allora, la fisica di rFactor PRO (o di AC per dire) non viene usata, ma viene del tutto bypassata dai loro software di simulazione, che fra le altre cose, può lavorare anche su server collegati in parallelo fra loro. Quello che rFPRO fa, è mettere in comunicazione il risultato dei calcoli ottenuto dai programmi di simulazione, con il proprio motore grafico, fisica di base (gravita, collisioni etc), sonoro e quant’altro. Ovviamente lo fa a frequenze superiori a quelle usate nei nostri “giochi”, di solito oltre 1000hz. I nostri simulatori/giochi, usano frequenze di aggiornamento inferiori, dai 333 ai 400hz più o meno, per un questione di semplice compromesso prestazionale. Si cerca di avere la maggior frequenza possibile, per la qualità grafica/numero di AI/altre funzione per le quali il gioco è stato creato. Tutti i sviluppatori di simulatori/giochi, possono facilmente tirare su la frequenza a valori estremi, senza problemi e la differenza, credetemi, si sente. AC a 1000hz è… cristallino, si sente ogni piccola imperfezione dell’asfalto. Purtroppo però girerebbe solo su PC super potenti e con limitato numero di AI. Sono sicuro che alcuni di voi si chiedono perché non rilasciamo un file .ini o qualcosa per permettere a chi ha il pc potente di girare a tale frequenza. Semplicemente ci sono problemi di multiplayer, parità di sensazioni e tempi sul giro fra utenti etc etc… si apre proprio la scatola di pandora. Nota importante. Solo i costruttori di auto (stradali o da gara) hanno accesso a rF PRO, e qualche altra piccola realtà professionale, molto spinta. Diffidate chiunque privato pubblicizza l’uso di rF PRO per la sua “stanza di simulatori professionale”… usano semplicemente rF o AC “base”. “Ma allora questi simulatori professionali sono ben superiori dai nostri giochi?”. Risposta semplice: Ni. Almeno non sempre. La cosa più importante di questi simulatori è la possibilità di verificare i risultato di una simulazione (con driver in the loop, cioè che guida, perché la simulazione si può fare anche senza qualcuno che guidi l’auto), tirando fuori dati in un formato che gli ingegneri possono confrontare in modo facile, veloce e soprattutto già collaudato. Quando dico valori verificabili, non intendo semplici forze G, la velocità o altro, ma dati ben più complicati da ottenere e tradotti subito in un formatto che gli ingegneri possono usare in tutti i loro calcoli. Da parte “nostra”, ce ne freghiamo altamente. Noi ottimizziamo il codice in modo da poter inserire e provare più valori possibili, non da poter tirare fuori risultati dettagliati, o giri di dati complessi. Faccio un esempio semplice da capire. Il nostro sistema ABS/TC è molto efficiente ma “cheata”. Nel mondo virtuale io posso sapere esattamente che slipangle/slipratio ha ogni singola ruota (dai calcoli che il simulatore fa in tempo reale). Dopo di che posso scrivere algoritmi per limitare lo slittamento in modo più o meno efficiente, simulando così un sistema TC/ABS più o meno evoluto. Il risultato è estremamente vicino alla realtà come verificato anche dal confronto di telemetrie reali e virtuali. Un simulatore professionale, non “cheata”. Anche se sanno benissimo che slipangle/ratio ha ogni singola ruota ad ogni momento, come noi d’altronde. Gli ingegneri devono ignorare questi valori. Costruiranno un software, che andrà a prendere SOLO i valori di sensori “reali”, come velocità di rotazione delle ruote, gps, accelerometri, sensori di pressione del gas, freno, giri motore, e tanto altro ancora, tutti sensori presenti nelle auto vere. Da questi valori di questi sensori, scriveranno un codice lungo 1500-2000 righe pieno di canali matematici, che cerca di “indovinare” lo stato delle ruote e il loro slipangle/ratio (come fa il sistema vero, perché nella realtà non esistono sensori che ti dicono se una gomma slitta e di quanto slitta) e infine agire su un motore simulato o su un sistema frenante simulato (o magari vero, posizionato sul banco). Noi facciamo il tutto con 5-10 righe di codice. Loro fanno più o meno lo stesso risultato (non sto esagerando) ma con 1500-2000 righe di codice. Il loro vantaggio è che poi possono prendere quelle 2000 righe di codice, inserirle in una ECU, posizionarla nella macchina vera e… funziona! Ci sono anche casi contrari. Spesso quando chiediamo agli ingegneri, dati per situazioni molto particolari, ben oltre il limite, spesso non sanno dare una risposta, per il semplice motivo che “non dovresti guidare così, non è veloce, ne efficiente”. Quando noi insistiamo per sapere cosa fa una gomma a livello di temperatura e grip a 50 gradi di traverso, o come si comporta un diffusore a 30 gradi di yaw angle, oppure a 30kmh, loro, quasi come se fosse una barzelletta, insistono con risposte del tipo “ma non devi farlo, non si può, non si fa” Noi e voi, sappiamo bene che un simracer non si ferma davanti a nulla… e troverà modo di fare la flugplatz con la Zonda a 300kmh di traverso… con 3 ruote per aria. Vi sorprenderà scoprire che spesso i vostri giochi/simulatori, in situazioni così estreme, si comportano in modo più realistico a confronto con un simulatore professionale, semplicemente perché agli ingegneri non interessa sapere cosa succederà se un suicida pazzo cercherà di schiantarsi 8 su 10 in una situazione del genere. Ricordo che nella realtà non c’è restart. Un altro fattore importante che può provocare reazioni “poco realistiche” su un simulatore professionale, è legato alle equazioni matematiche usate, specialmente per le gomme. Spesso i dati per le gomme, arrivano direttamente dal costruttore (michelin, pirelli, bridgestone, etc), come curve realizzate da equazioni che riprendono i dati registrati da prove vere nel modo più vicino possibile. Tuttavia, essendo curve da equazioni matematiche, a certi valori estremi, possono seguire andature non realistiche. Questo poco interessa agli ingegneri, perché spesso loro devono ottenere risultati in un range ben specifico di utilizzo, e quello che succede prima o dopo quel range, non importa. Inoltre, chi rischierà il suo posto di lavoro per cambiare una curva che arriva direttamente dal costruttore della gomma… é il così detto “fit” dell’equazione, cioè usare solo una parte del range dei risultati che da, che è poi la parte che interessa. Stessa cosa anche per l’aerodinamica e così via. Infine, mentre noi sviluppatori di videogiochi, stiamo cercando di inserire fattori di variazione per ottenere una guida “naturale” una auto “viva”, come pressioni gomme, temperature, asfalto con grip variabile, vento, temperature ambientali diversi etc, spesso i simulatori professionali vanno verso la direzione completamente opposta, per limitare al minimo variabili non controllabili e ottenere i stessi risultati giro dopo giro. Su quest’ultimo paragrafo va collegato il discorso motion platform. Si le loro motion platform sembrano (e lo sono) spettacolari… ma hanno più un uso pubblicitario e di immagine, che un uso pratico. Innanzitutto anche le migliori in assoluto, non riescono a simulare le forze G di una auto vera. Possono dare un alto valore G di picco, ma poi sustained, cioè sostenuto, non possono superare 1G, per forza di cose. Oggi, una crossover con gomme normalissime, supera 1G in fase di frenata, figuriamoci le auto da gara… Inoltre, come spiegavo sopra, i simulatori professionali servono per verificare soluzioni ingegneristiche. Serve un pilota che riesca a effettuare tanti giri nel modo più preciso possibile. Una guida meno precisa, causata dai movimenti di una motion platform, è controproducente per il loro lavoro, e spesso, molto spesso, dopo il girato dei video pubblicitari, il motion platform viene spento e il pilota continua a girare senza forze esterne di disturbo. Sicuramente a qualcuno la mia risposta sembrerà poco modesta. Sarà vero che i simulatori professionali sono meno realistici da un “gioco”? No, non è proprio così, ma il loro focus di realismo è diverso dal nostro. A livello ingegneristico un simulatore professionale è ben più preciso di un gioco. A livello di verifica di soluzioni sul setup o nuovi componenti, il simulatore professionale vince ancora. A livello di guida pura… ce la giochiamo… e su qualche situazione estrema, vinciamo pure. Infine ricordatevi anche il famoso detto fra ingegneri. Shit in, shit out. Il realismo di un simulatore, oltre che alla bontà delle equazioni, è molto influenzato dalla precisione dei dati inseriti. Dimenticavo, quasi tutti i simulatori professionali, usano asset creati dai sviluppatori di videogiochi. Modestamente… le nostre piste laserscan e modelli 3D di auto, vanno a ruba.

Aris Vasilakos della Kunos Simulazioni ha risposto direttamente su Facebook al dubbio di un utente: Ecco qui di seguito la sua completissima risposta: Ciao a tutti Cerchiamo di mettere un po’ di ordine sul discorso simulatori pro/simulatori videogame. Innanzitutto chiariamo subito la questione hardware. Pedali, volanti e attuatori per motion platform su simulatori usati da case automobilistiche, sono chiaramente costosissimi, di alta qualità, spesso presi direttamente dalle auto vere e soprattutto settati in modo realistico con precisione. Di conseguenza, se ad esempio, il costruttore Sto arrivando! dalla telemetria, che un pilota esercita una pressione di 70kg sul pedale del freno per una frenata adeguata, la pedaliera del simulatore sarà regolata adeguatamente, senza scuse del tipo “eh ma così è troppo duro, preferisco la pedaliera del g27” (per dire :D ) Se per il freno magari i valori vi sorprendono, allora forse vi sorprenderà ancora di più sapere che a livello di FFB , di solito i piloti preferiscono una taratura molto debole, sia sulla auto vera che sul simulatore… vanno regolati anche qui adeguatamente. Sul discorso motion platform, tornerò più avanti. Discorso software. Diffidate di chi vi dice che i costruttori usano rFactor, o Assetto Corsa, o iRacing. I costruttori, usano di solito rFactor PRO. Qualcuno una versione particolare dell’engine AC, qualcuno un software di simulazione dall’Olanda che adesso non ricordo il nome, e qualcun’altro ancora delle versioni dedicate di programmi come simulink, mathlab etc. (ma che sono poco compatibili con asset grafici avanzati e allora poco usati per la grafica) TUTTI, ma proprio tutti NON usano il motore fisico di rF, AC, iR etc. Come mai? Cosa usano? Quello che usano è così più avanzato? Si e no. Andiamo con ordine. Cominciamo da rFactor PRO. Questo software è ormai seguito e realizzato da una società indipendente dagli ISI, creatori di rF originale. C’è scambio di tecnologia ma è del tutto e per tutto una azienda diversa. La sua forza consente nel permette agli ingegneri di utilizzare il motore grafico, sonoro, collisioni col terreno fra auto etc, asset grafici (piste, auto 3D etc) ed eventualmente AI e multi di rFactor, con collegamente esterni di solito via UDP, con qualsiasi software matematico/simulativo ogni costruttore usa. Di solito mathlab e simulink. Questi sono programmi ingegneristici di alta fedeltà e grande complessità, che vengono usati dagli ingegneri per creare un modello matematico che simula diversi elementi di un veicolo. Essendo questi dei software standard usati dalla stragrande maggioranza dei centri di sviluppo e progettazione delle case, permettono di implementare diversi sistemi in modo completamente separato ed autonomo. Ci sarà un modulo per la simulazione delle gomme, uno per la simulazione della sospensione, uno per l’aero, se arriva domani la Bosch con un nuovo modulo ABS, allora può semplicemente attaccare tutta la logica e così via. Di fatto allora, la fisica di rFactor PRO (o di AC per dire) non viene usata, ma viene del tutto bypassata dai loro software di simulazione, che fra le altre cose, può lavorare anche su server collegati in parallelo fra loro. Quello che rFPRO fa, è mettere in comunicazione il risultato dei calcoli ottenuto dai programmi di simulazione, con il proprio motore grafico, fisica di base (gravita, collisioni etc), sonoro e quant’altro. Ovviamente lo fa a frequenze superiori a quelle usate nei nostri “giochi”, di solito oltre 1000hz. I nostri simulatori/giochi, usano frequenze di aggiornamento inferiori, dai 333 ai 400hz più o meno, per un questione di semplice compromesso prestazionale. Si cerca di avere la maggior frequenza possibile, per la qualità grafica/numero di AI/altre funzione per le quali il gioco è stato creato. Tutti i sviluppatori di simulatori/giochi, possono facilmente tirare su la frequenza a valori estremi, senza problemi e la differenza, credetemi, si sente. AC a 1000hz è… cristallino, si sente ogni piccola imperfezione dell’asfalto. Purtroppo però girerebbe solo su PC super potenti e con limitato numero di AI. Sono sicuro che alcuni di voi si chiedono perché non rilasciamo un file .ini o qualcosa per permettere a chi ha il pc potente di girare a tale frequenza. Semplicemente ci sono problemi di multiplayer, parità di sensazioni e tempi sul giro fra utenti etc etc… si apre proprio la scatola di pandora. Nota importante. Solo i costruttori di auto (stradali o da gara) hanno accesso a rF PRO, e qualche altra piccola realtà professionale, molto spinta. Diffidate chiunque privato pubblicizza l’uso di rF PRO per la sua “stanza di simulatori professionale”… usano semplicemente rF o AC “base”. “Ma allora questi simulatori professionali sono ben superiori dai nostri giochi?”. Risposta semplice: Ni. Almeno non sempre. La cosa più importante di questi simulatori è la possibilità di verificare i risultato di una simulazione (con driver in the loop, cioè che guida, perché la simulazione si può fare anche senza qualcuno che guidi l’auto), tirando fuori dati in un formato che gli ingegneri possono confrontare in modo facile, veloce e soprattutto già collaudato. Quando dico valori verificabili, non intendo semplici forze G, la velocità o altro, ma dati ben più complicati da ottenere e tradotti subito in un formatto che gli ingegneri possono usare in tutti i loro calcoli. Da parte “nostra”, ce ne freghiamo altamente. Noi ottimizziamo il codice in modo da poter inserire e provare più valori possibili, non da poter tirare fuori risultati dettagliati, o giri di dati complessi. Faccio un esempio semplice da capire. Il nostro sistema ABS/TC è molto efficiente ma “cheata”. Nel mondo virtuale io posso sapere esattamente che slipangle/slipratio ha ogni singola ruota (dai calcoli che il simulatore fa in tempo reale). Dopo di che posso scrivere algoritmi per limitare lo slittamento in modo più o meno efficiente, simulando così un sistema TC/ABS più o meno evoluto. Il risultato è estremamente vicino alla realtà come verificato anche dal confronto di telemetrie reali e virtuali. Un simulatore professionale, non “cheata”. Anche se sanno benissimo che slipangle/ratio ha ogni singola ruota ad ogni momento, come noi d’altronde. Gli ingegneri devono ignorare questi valori. Costruiranno un software, che andrà a prendere SOLO i valori di sensori “reali”, come velocità di rotazione delle ruote, gps, accelerometri, sensori di pressione del gas, freno, giri motore, e tanto altro ancora, tutti sensori presenti nelle auto vere. Da questi valori di questi sensori, scriveranno un codice lungo 1500-2000 righe pieno di canali matematici, che cerca di “indovinare” lo stato delle ruote e il loro slipangle/ratio (come fa il sistema vero, perché nella realtà non esistono sensori che ti dicono se una gomma slitta e di quanto slitta) e infine agire su un motore simulato o su un sistema frenante simulato (o magari vero, posizionato sul banco). Noi facciamo il tutto con 5-10 righe di codice. Loro fanno più o meno lo stesso risultato (non sto esagerando) ma con 1500-2000 righe di codice. Il loro vantaggio è che poi possono prendere quelle 2000 righe di codice, inserirle in una ECU, posizionarla nella macchina vera e… funziona! Ci sono anche casi contrari. Spesso quando chiediamo agli ingegneri, dati per situazioni molto particolari, ben oltre il limite, spesso non sanno dare una risposta, per il semplice motivo che “non dovresti guidare così, non è veloce, ne efficiente”. Quando noi insistiamo per sapere cosa fa una gomma a livello di temperatura e grip a 50 gradi di traverso, o come si comporta un diffusore a 30 gradi di yaw angle, oppure a 30kmh, loro, quasi come se fosse una barzelletta, insistono con risposte del tipo “ma non devi farlo, non si può, non si fa” Noi e voi, sappiamo bene che un simracer non si ferma davanti a nulla… e troverà modo di fare la flugplatz con la Zonda a 300kmh di traverso… con 3 ruote per aria. Vi sorprenderà scoprire che spesso i vostri giochi/simulatori, in situazioni così estreme, si comportano in modo più realistico a confronto con un simulatore professionale, semplicemente perché agli ingegneri non interessa sapere cosa succederà se un suicida pazzo cercherà di schiantarsi 8 su 10 in una situazione del genere. Ricordo che nella realtà non c’è restart. :) Un altro fattore importante che può provocare reazioni “poco realistiche” su un simulatore professionale, è legato alle equazioni matematiche usate, specialmente per le gomme. Spesso i dati per le gomme, arrivano direttamente dal costruttore (michelin, pirelli, bridgestone, etc), come curve realizzate da equazioni che riprendono i dati registrati da prove vere nel modo più vicino possibile. Tuttavia, essendo curve da equazioni matematiche, a certi valori estremi, possono seguire andature non realistiche. Questo poco interessa agli ingegneri, perché spesso loro devono ottenere risultati in un range ben specifico di utilizzo, e quello che succede prima o dopo quel range, non importa. Inoltre, chi rischierà il suo posto di lavoro per cambiare una curva che arriva direttamente dal costruttore della gomma… é il così detto “fit” dell’equazione, cioè usare solo una parte del range dei risultati che da, che è poi la parte che interessa. Stessa cosa anche per l’aerodinamica e così via. Infine, mentre noi sviluppatori di videogiochi, stiamo cercando di inserire fattori di variazione per ottenere una guida “naturale” una auto “viva”, come pressioni gomme, temperature, asfalto con grip variabile, vento, temperature ambientali diversi etc, spesso i simulatori professionali vanno verso la direzione completamente opposta, per limitare al minimo variabili non controllabili e ottenere i stessi risultati giro dopo giro. Su quest’ultimo paragrafo va collegato il discorso motion platform. Si le loro motion platform sembrano (e lo sono) spettacolari… ma hanno più un uso pubblicitario e di immagine, che un uso pratico. Innanzitutto anche le migliori in assoluto, non riescono a simulare le forze G di una auto vera. Possono dare un alto valore G di picco, ma poi sustained, cioè sostenuto, non possono superare 1G, per forza di cose. Oggi, una crossover con gomme normalissime, supera 1G in fase di frenata, figuriamoci le auto da gara… Inoltre, come spiegavo sopra, i simulatori professionali servono per verificare soluzioni ingegneristiche. Serve un pilota che riesca a effettuare tanti giri nel modo più preciso possibile. Una guida meno precisa, causata dai movimenti di una motion platform, è controproducente per il loro lavoro, e spesso, molto spesso, dopo il girato dei video pubblicitari, il motion platform viene spento e il pilota continua a girare senza forze esterne di disturbo. Sicuramente a qualcuno la mia risposta sembrerà poco modesta. Sarà vero che i simulatori professionali sono meno realistici da un “gioco”? No, non è proprio così, ma il loro focus di realismo è diverso dal nostro. A livello ingegneristico un simulatore professionale è ben più preciso di un gioco. A livello di verifica di soluzioni sul setup o nuovi componenti, il simulatore professionale vince ancora. A livello di guida pura… ce la giochiamo… e su qualche situazione estrema, vinciamo pure. Infine ricordatevi anche il famoso detto fra ingegneri. Shit in, shit out. Il realismo di un simulatore, oltre che alla bontà delle equazioni, è molto influenzato dalla precisione dei dati inseriti. Dimenticavo, quasi tutti i simulatori professionali, usano asset creati dai sviluppatori di videogiochi. Modestamente… le nostre piste laserscan e modelli 3D di auto, vanno a ruba.

Dopo aver annunciato la collaborazione con il settore automotive per lo sviluppo delle vetture a guida autonoma, Image Space Incorporated (ISI) comunica la collaborazione con 7 scuderie di Formula E che utilizzerano il già noto rFPro, simulatore professionale dell'azienda americana che utilizza i collaudatissimi engine ISIMotor (per la fisica) e gMotor (per la grafica), per l'allenamento, il testing e la messa a punto della monoposto. ISI inoltre ha iniziato a sviluppare i tracciati di Formula E in tecnologia LIDAR e ci mostra in anteprima il nuovo circuito di Hong Kong, sul quale si correrà nel prossimo weekend la prima gara di campionato elettrico. During 2017 rFpro invested in LiDAR scanning and building accurate circuit models for all the events on the calendar. As of November 2017 seven Formula E entrants are using rFpro for their simulated vehicle development and testing. We are now starting the F-E Annual Circuit Maintenance contract to keep our customers' investments protected against future updates. Here's a lap of Hong Kong, the first race of the season on 2nd December.

Image Space Incorporated (ISI) ha annunciato la collaborazione con varie aziende del settore automotive per lo sviluppo delle vetture a guida autonoma. Il lavoro sarà effettuato utilizzando il già noto rFPro, il simulatore professionale dell'azienda americana che, pur essendo profondamente diverso dalle versioni commerciali rFactor ed rFactor 2 (peraltro cedute allo Studio 397), utilizza i collaudatissimi engine ISIMotor (per la fisica) e gMotor (per la grafica). Gjon Camaj ha spiegato in proposito:"Over the last ten years we've dedicated our team to producing realistic and verifiable, rather than cinematic, simulation. That focus really paid off with the emergence of the Autonomous Driving simulation market. Our overall simulation architecture and graphics engine delivers, out of the box, the tools and techniques that are required for Deep Learning based perception systems driven by camera, LiDAR and radar feeds." Chris Hoyle, direttore tecnico di rFPro ha aggiunto: "Vehicle manufacturers and their suppliers are increasing their investment in the development of ADAS and autonomous systems, that places the emphasis on the development and validation of Deep Learning systems for both Perception, using cameras, radar and LiDAR to detect the environment, and Prediction, to plan a path through the road ahead, allowing for traffic, pedestrians, road signals and hazards. The combination of technologies from rFpro and ISI is so much greater than the sum of the two parts as it allows us to substantially accelerate our R&D, rFpro has one core focus: driving simulation, and, by investing in our R&D capability, we hope to keep ahead of the curve on the demand for new capabilities from our customers in Deep Learning Autonomous Driving, ADAS and Vehicle Dynamics. The deal also secures our access to key technology, essential to producing realistic simulation for perception systems." Qui di seguito due interessanti video ed alcune immagini che ci mostrano il lavoro in corso. ISI ha inoltre annunciato la realizzazione per rFPro della versione laser scan del circuito di Sepang, che possiamo ammirare nel video qui sotto.

With F1 taking to the streets of London today in Trafalgar Square and Whitehall, it reminded us of a project from 2012 when rFpro was used to evaluate the feasibility of a London Grand Prix. This video shows a lap of the suggested route. Look out for Piccadilly, the Wellington Arch, Buckingham Palace and the Victoria Memorial, Parliament Square, Westminster Abbey, Big Ben, the London Eye, Trafalgar Square and a narrow squeeze through Admiralty Arch to the finish on The Mall.

Forte anche dei complimenti ricevuti direttamente dalla Ferrari, che ha confermato come i propri progressi siano stati anche merito dell'uso del simulatore, il team di rFactor Pro prosegue lo sviluppo del software professionale dedicato al training ed all'uso aziendale. Proprio in questi giorni infatti è stata annunciata la disponibilità del tracciato stradale e cittadino del centro di Shanghai, che vedete nelle immagini qui sotto, oltre ad una nuova versione aggiornata del circuito dell'Hungaroring. E' stato inoltre implementato in rFPro l'utilizzo della impressionante camera a 360 gradi. rFpro have completed another public road model, this one is in the centre of Shanghai and it is already being used for Autonomous testing. The model spans an area containing a wide selection of roads and junctions from dense urban single-carriageway to multi-lane dual carriageway, with very high correlation to the real-world. This model has been rebuilt from a new LiDAR survey, with new graphics and a new TerrainServer HDSurface at 1cm resolution in x,y. Here are a couple of screen-grabs showing the new road surface and kerb details. The model is quite detailed but still manages to achieve 120fps on our reference hardware.

rFPro è montato sul simulatore fisico Ferrari dalla stagione passata. Quindi secondo il tuo ragionamento c'è stato, di fatto, un miglioramento. Tara...no...non è rF2 ovviamente. rFPro poi non è che sia 1 singolo sim. E' più che altro la "costruzione" del mod che dovrà essere usato. E' qualcosa di completamente diverso perchè è fatto per funzionare per 1 determinato pacchetto HW...quello usato. Poi c'è la costruzione dei circuiti in cui dovrà correre quel mod. Non è paragonabile ad un sim commerciale ma questo dopotutto vale per tutti i sim professionali concorrenti di rFPro.

Infatti NON è un gioco o almeno io lo vedo così...dopotutto le feature che abbiamo oggi su rF2, sono un travaso da rFPRO. E' un sim pluriutilizzato, come software, su simulatori professionali di molte squadre...o di team importanti. Il GT Academy, fa utilizzare il titolo ISI per allenamento...altro che Gran Turismo. Per le AI il discorso è diverso. Usano il set default, sempre, ma rimanendo comunque moooooooolto competitive senza dover arrivare al massimo di difficoltà (120%). Consumano le gomme ma a volte non si fermano e si ritirano...qualche volta bruciano il motore anche se il mod ha difficoltà immani per rendere la cosa possibile...qualche problemino c'è anche per loro (si può anche forzargli un setup ma è prassi complicata e io non ci ho mai provato) ma a livello di qualità dell'intelligenza artificiale ci siamo. Certo...forse ancora non sono il massimo per poter pensare di farci campionati sani in single player ma il loro dovere lo fanno.

Di base il sim Ferrari, usato da Kimi e Seb da inizio di questa stagione, è rFPRO modificato su determinate specifiche. Stranamente il finlandese ha anche smesso di soffrire di qualche suo problema personale con i sim e non avuto particolari lamentele come negli scorsi anni.

Da quanto avevo letto (se non erro proprio qui sul forum) la Ges usa un simulatore basato su rFPRO. Diverso il discorso per le postazioni al museo Ferrari di Maranello e nei Ferrari Store (l'ho visto giusto la settimana scorsa a Milano), dove viene usato qualcosa di molto vicino ad AC.

Mi ero perso questo intervento che, purtroppo, non mi sento di condividere. Senza voler sminuire la prova fatta dall'autore dell'articolo, mi permetto di osservare che le sue conclusioni non sono coerenti con la descrizione dello svolgimento della prova. L'autore ammette che il simulatore usato (in quel caso rF) non riproduce alcune caratteristiche della Dallara F3 (ad esempio l'aerodinamica è fortemente semplificata) e, inoltre, il tracciato utilizzato non corrisponde esattamente (o almeno con un buon grado di precisione) a quello reale. Quindi i dati che riesce a comparare sono relativi al comportamento delle componenti meccaniche a determinate sollecitazioni, dove emerge che il motore fisico riesce a simulare con buona approssimazione la cinematica di alcuni componenti della vettura come sospensioni, ammortizzatori ecc... Un software ha 30€ riesce certamente a fare quello che l'autore dell'articolo dice, ma con un grado di approssimazione tale da essere inutile per qualsiasi uso professionale. I simulatori sviluppati ad hoc per tali scopi hanno livelli di approssimazione ridotti (nell'articolo vengono indicati alcuni dati con l'approssimazione del 4% rispetto al reale, che per una squadra corse sarebbe una tolleranza troppo elevata). In sostanza un qualsiasi simulatore se ha accesso a dati reali può avvicinarsi molto alla realtà, ma il livello di approssimazione è tale da poter essere utile solo per far imparare il circuito al pilota o per avere delle prime e puramente indicative indicazioni sull'assetto calcolato dagli ingegneri con il computer. I simulatori con cui le squadre corse fanno le prove di assetto sono sviluppati appositamente per riprodurre un mondo virtuale molto più complesso e con un grado di approssimazione rispetto alla realtà molto ridotto. Non a caso quei simulatori costano migliaia di Euro e richiedono l'utilizzo di più computer, alle cui CPU vengono dedicati specifici calcoli. Si, puoi non condividere in pieno. Si, il simulatore rFPro attuale della Ferrari costa migliaia di euro (perche' tenta, fallendo, di riprodurre con attuatori le forze che agiscono sul pilota e perche' ha bisogno di hardware potentissimi per ridurre praticamente a zero il lag del motore fisico). Si, monza in rF1 non e' laserscanned. Pero', at the end of the day, tempo reale 1.47,3 tempo rF1 1.47,1. Che e' quello che voleva sapere l'O.P.

Development Tool of the Year: rFpro road modeling service rFpro’s road modeling service was a popular choice for jury members. In something of an unprecedented result, the highly detailed modeling software took top marks from almost all judges. As juror Gabor Szecsenyi explains, “accurate road surface modeling has the potential to help manufacturers to adapt their worldwide models to local conditions globally – only more accurately and more cost-effectively than ever before…” -> http://www.vehicledynamicsinternational.com/news.php?NewsID=68331

Non so se è gia stato postato anche questo articolo, cmq allego link. io ho sempre saputo che usavano rFpro, che poi altro non è, che una versione evoluta di rFactor1...poi ovvio che sarà modificato a piacimento di giorno in giorno, ma la base è quella, che poi lo usino tutti i Team di F1 o solo alcuni questo non lo so, in ogni caso alcuni lo usano. invece le piste scannarizzate i team le comprate a parte a suon di soldoni (mi ha riferito delle cifre un'amico che ha usato questi simulatori). http://www.formulapassion.it/2014/10/ferrari-nuovo-software-per-il-simulatore-f1/ PS: l'articolo dice "SOSTITUTO" e ciò significa tutto o nulla, può voler dire che è una ditta nuova a farlo come voler dire che è stato sostituto da un modello nuovo ma della stessa ditta.

Megaquote. Piccolo OT ma manco più di tanto: Si sa che software usava in passato la Ferrari? Ne ha usati più di uno da quando esiste il simulatore Ferrari (inteso come hardware)? Non conosco neanche un concorrente della ISI sul campo...quali e come si chiamano i concorrenti di rFPRO?

ma come e' nn c'entra nulls? Ma stai scherzando? Rfactor pro si basa su rfactor. E' lo stesso motore sviluppato e migliorato per I team. Avete un pò ragione tutti, ma vi spiego meglio. Rfpro, come core è più l'origine di rfactor 2, diversa illuminazione e migliorie grafiche rispetto a rf1.....probabilmente è stato la base di sviluppo per rf2...a livello grafico intendo. Perchè avete ragione tutti, perchè può centrare con gmotor o può non centrare niente. La vera forza è la "frequenza di campionamento" per la fisica ed il fatto che permette di utilizzare modelli propri per la simulazione delle varie parti interessate, in questo contesto potremmo definire il pro come un rf con codice "aperto". Uno scenario tipo potrebbero essere usare come modello fisico per pneumatici , engine o areodinamica i miei fatti in casa,tipo con simulink/matlab ecc, per il resto mi appoggio a rfpro che mi permette di avere l'engine grafico i canali in entrata ed uscita , la possibilità di creare plugin ecc.. Potreste quindi immaginarlo come il cryengine sdk/unity sdk per le simulazioni di auto , cioè ti mette a disposizione tutto l'occorrente per una simulazione automobilistica con alta velocità di campionamento per la fisica ed altamente "moddabile"( possibilità di utilizzare modelli propri per tutto , sospensioni, motore, areodinamica). Per questo tante squadre che sviluppano i loro modelli , o meglio hanno il budget per farlo si affidano al pro, prendi un motore consolidato , che gira bene, e lo personalizzi al massimo con i tuoi modelli. Extreme

I titoli che abbiamo noi hanno la stessa struttura di codice e motore di rFP. Senza ombra di dubbio. Quello che cambia è che dal 2006 rFP ha avuto costanti aggiornamenti nel tempo fino adesso e continuerà ad averli. Dal 2006 rF ha avuto 3 patch e basta e là si è fermato. Quando un cliente si affida alla ISI per un simulatore c'è un interscambio di dati prestazionali e telemetrici che portano a creare mod che non hanno nulla a che vedere con le vetture a cui siamo abituati (ed in ogni sim). C'è un'assistenza diretta e, nel "campo", test con i piloti che saranno giudici di quelle che sono le differenze tra mod e realtà nel comportamento dinamico. In altre parole...comparare rF1/2 con rFPRO è come comparare un linguaggio di programmazione di basso livello con uno di alto livello (su cui molti di noi potrebbero metterci mano). Non conosco i potenziali concorrenti di rFPRO però so che parliamo anche e sopratutto di clientela di "nicchia" se consideriamo che la Toro Rosso usava nel proprio simulatore, fino al 2009, rF1.