Search the Community

Gli sviluppatori della piattaforma software professionale di rFPro lanciano oggi la nuova tecnologia RayTracing che trasforma il realismo della simulazione, accelerando lo sviluppo dei vari progetti di Autonomous Vehicles e ADAS. I sensori dei veicoli possono ora essere sviluppati in simulazione, prima ancora che esista un prototipo fisico.Inoltre, per la prima volta, vengono simulati accuratamente gli effetti di blurring e rolling shutters per rappresentare davvero ciò che le telecamere "vedono". Il video qui sotto, preso direttamente dal software, ci mostra un viaggio completamente ray-tracing attraverso il modello digitale di Coventry in UK. Commenti nel topic dedicato sul forum in italiano.

Il nuovo "Digital Twin" del simulatore professionale rFPro del banco di prova Applus IDIADA supporta il crescente utilizzo della simulazione nello sviluppo e nei test dei veicoli. Il modello digitale di livello ingegneristico di rFPro consente lo sviluppo e il test della dinamica del veicolo, dell'ADAS e dei sistemi autonomi nella simulazione prima e insieme alla convalida del mondo reale sul banco di prova. rFpro ha sviluppato un modello virtuale altamente accurato del banco di prova di Applus IDIADA da utilizzare per lo sviluppo di veicoli in simulazione. Il gemello digitale consente ai produttori di accelerare e migliorare il processo di sviluppo dei veicoli. Consente la valutazione di sistemi e veicoli in un ambiente virtuale pienamente rappresentativo sia prima che dopo che i prototipi fisici sono disponibili per la convalida in pista.

A typical scenario could be to use my homemade tires as physical model, engine or aerodynamics, like with simulink / matlab etc., for the rest I rely on rfpro which allows me to have the graphic engine the input and output channels , the ability to create plugins etc .. net banking Regards, teatv.ltd

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.