netKar diventa nKpro

[rookie]

Dopo un po' di tentennamenti e silenzi, che avevano anche fatto pensare il peggio, finalmente ci sono grosse novità sul fronte netKar, IL (a mio giudizio) simulatore di guida, creatura di quel genio di nome Stefano "Kunos" Casillo.

Ieri è uscito il primo rapporto su quello che sarà il futuro di netKar, dico subito che la più grossa novità è che non sarà più gratuito, troppo il tempo che richiederebbe una nuova versione di nK se non si organizza tutto un altro tipo di lavoro, compresi dei fidati collaboratori (Kunos finora ha fatto tutto praticamente da solo).

In ogni caso questo per un appassionato di simulazioni di auto non DEVE essere un problema, solo a pensare quante soddisfazioni molti di noi hanno avuto negli ultimi 2 anni con nK "aggratis" penso che non ci possa essere spazio per qualsivoglia critica per la decisione presa.
Non ci sarebbe potuto essere un futuro per nK (nonostante esista una versione beta più evoluta), per Kunos le cose a livello professionale erano radicalmente cambiate dalla creazione dell'ultima versione.....

Io sono estremamente contento di questa decisione, sono convinto che con l'esperienza (positivissima) di nK e la collaborazione di persone molto capaci, nKpro sarà senza dubbio la pietra di paragone per il genere.

Vi allego il primo "dev report", Kunos lo ha scritto in inglese, ma c'è un'ottima traduzione in italiano (thx daf).

C'è un pulsante PayPal per sostenere il progetto.......I BELIEVE!

http://www.drivingitalia.net/forum/i...hp?showforum=7
http://www.netkar-pro.com
http://www.outrunner.net/


"2004/8/6



This is my first dev update for netKar Pro. I will try to keep this as a constant appointment for people curious to sneak behind the scenes of this project.



At the beginning, I will be forced to keep my reports pretty generic. We don't want to generate false alarms or any possible misunderstanding about what nKpro is going to be, so please keep in mind that every conclusion you might come up with reading these docs is just that: "your" idea :-P



netKar Pro development is divided into different phases; these phases will bring us to the final product and the release of v1.0. This is to say that nKpro is not "features-driven" but "time-driven", meaning, I will stuff as much as I can into the given time costraints.



The first phase is dedicated to graphics, and I am working hard together with Alessandro "Outrunner" to enhance nKpro's graphics experience. Alessandro came out with a big break-through yesterday about shadow generation, I am finishing the code to support his idea so we can try it in-game.



netKar Pro has a much more "professional" approach to 3D editing. The original plans for netKar's 3D engine were assuming no artist working on the graphics, so everything had to be as much automatic as possible. This meant building a series of "rules" to import files from editing packages straight into netKar trying to match the various parameters in the best possible way. This cut down the 3D development process drastically, don't forget that, about 70-80% of the 3D present on the first 0.9.0 release of netKar and the 100% on the Alpha versions was made by be and at that time I would have never imagined to find myself in the position of having a great 3D artist working on the game "full time".

The approach now is based on a custom 3D editor that sits in between the 3D editing package and the game itself; in this editor the artist is able to change dozen of parameters for each texture pass and see the effect of his changes in real time becase there's the 3D engine up and running on another window.

It was a bit of a mess trying to come up with a decent solution to integrate the 3D engine and the user interface needed by an interactive editor. I've looked into many solutions to solve the problem of my 3D engine being based on Microsoft Visual Studio and my user interface based on Borland C++ Builder. I did a lot of hacking with the managed C++ extensions in VS but I've found very very hard to integrate managed code with non managed code, almost impossible.

The decision was to sitck to Borland C++ Builder and use UDP to setup a communication between the editor interface and the 3D "view application" written in Visual Studio, a bit complicate but easier than trying to come up with a custom GUI on the top of DirectX.

I am planning to have more experiments done on C++ Builder using DirectX9 and possibly able to run the 3D inside its own windows, it could be very useful to have a "rendered" view without actually starting the simulation.

This will bring up the cost for me a bit since my C++ Builder licence is only for non commercial applications, so I need to upgrade it to a commercial one.



Another big change done this week was the complete removal of the dll system used in nK since from the start. The new nKpro is 100% based on the nK|dK concept, so there is no need for a "car" dll anymore since the car infos are all stored into nK|dK database. This sort of complicates things a bit when it comes to new features and "special" behaviour; in nK 099 if I wanted something peculiar to happen on the MG I just had to load the dll's code into VS and write the behaviour in native C++. Now, when facing the same scenario I will have to think how to integrate this into nK|dK and then implement it in the game. It takes more forward thinking but, once done, it is easier to test on different cars because all of them are going through the same piece of code, so if ABS works for the MG it is supposed to work for XX.

From a pure software engineering point of view nKpro is simpler than nK 099 beacuse it is made of 2 exe files (the interface and the simulation) and no additional dlls since I've moved the old nkClient.dll code into nks.exe as well. There is a very small improvement in performance since the compiler doesn't have to cope with all the interfaces between the dlls module. Now the main application class (CKar2.cpp) has a direct pointer to a car class (CCar) and not to an interface car class (ICar).

Although not needed I decided to keep the code generation setting in VS to use the Multithread DLL libraries I still want to keep the possibility of "plugins" open. The scenario here is, if I really need to hack a very unique behaviour in a car, I can write a "plugin" to the simulation that can react to different events by implementing a virtual function and access the internals of the game. Probably AI could use this system, other good applications could be custom telemetry or strange devices like "fans" or movable wings.



Physics is just a blast, it's one of the part in nK where I would feel confident enough to release "tomorrow". Major bugs in ARBs and camber where fixed over nK 099 and now the car is just perfect, it does what you'd expect in every condition, and it is so "regular" that, once you learn to drive "ahead" of the car you can really have fun sliding around everywhere.

ARBs has been my headache since the beginning of nK because my original "assumptions" where all wrong. Every version of nK had a sort of "hack" to cure the problem.. but it is easy to find the problem in nK 099, just drive at Donington Long with a 3000 or a MG with very stiff ARBS. On the last "complex", the first left/right corner hit the kerb on the right apex and, it is very likely that the car will spin in the air out of control.. that's the old ARBs code going crazy..

That is a very evident manifestation of the problem but the "wrong" behaviour was infecting the car in every manouver, new ARBs code, months ago made Aris go wild on MSN with "what have you done? It is a DIFFERENT game!".

Camber formula had another stupid problem with a missing division by the load on the tyre making it seriously unstable.

After these 2 major fixes the only adjective that describe nK's physics is "smooth", actually, sometimes "too" smooth, we're looking into making the tracks a bit more "alive".



I've also rewritten from scratch the code for wall collision response, and I am very pleased with the results, now the car bounces witht he right amount of "structural damping", scratches the wall when hitting from a side and so on.

For Kidcodea's pleasure now cars don't disappear under the ground when flipped ;-).



I've added a "PayPal" donate button on the homepage. This project doesn't have anything to offer as download or something, but netKar "free" gave many people hours of enjoyment in these 2 years, so if you feel bad about it, that's the magic button that will take away your feeling guilty ;-).



It is a nice feeling to be back on this, it is a real stress that will drive me crazy eventually because I still have to divide my time between my job and nKpro, but it is amazing what a couple of hours difference on my alarm can make ;-), after all, I am lucky enough to be at just 10 minutes from my office, and that, in Tokyo, is a real priviledge. I hope nKpro V1.0 sells will solve this "problem" and allow me to make nK my only "to do" in my life.



back to you next time.



ciao



stefano"





"2004/8/6
Questo è il mio primo aggiornamento sullo sviluppo di netKar pro. Cercherò di renderlo un appuntamento costante per tutti coloro che vogliono curiosare nel “dietro le quinte” di questo progetto. Inizialmente sarò costretto a dare un taglio molto generico a questi aggiornamenti. Non vogliamo generare falsi allarmi o nessun tipo di possibile fraintendimento circa quello che netKar pro sta diventando, quindi per favore sia ben chiaro che qualsiasi conclusione alla quale arriverete leggendo questi documenti sarà proprio solo questo: una “vostra” conclusione :-P

Lo sviluppo di netKar Pro è suddiviso in differenti fasi; queste fasi ci porteranno alla realizzazione del prodotto finale e al rilascio della versione v1.0. Questo significa che nKpro non è "features-driven" (sviluppato secondo le caratteristiche) ma "time-driven" (sviluppato in base al tempo), ovvero svilupperò codice tanto quanto riuscirò a fare in intervalli di tempo prestabiliti.

La prima fase sarà dedicata alla grafica,e sto lavorando un bel po’, insieme ad Alessandro "Outrunner", sull’esperienza grafica in nKpro. Alessandro se ne è uscito ieri con una grande trovata circa la generazione delle ombre, io sto finendo il codice per supportare la sua idea in modo da poterla provare all’interno della simulazione.

netKar Pro ha un approccio molto più "professionale" all’editing 3D. I piani originali per il motore 3D di netKar ipotizzavano non esistesse nessuno grafico professionista dedicato, quindi ogni cosa era stata pensata per essere il più “automatica” possibile. Questo significava costruire una serie di “regole” per importare i file da pacchetti grafici direttamente in netKar provando a gestire i vari parametri nel miglior modo possibile. Questo diminuiva drasticamente il processo di sviluppo 3D, non dimenticate che circa il 70-80% della grafica 3D presente nella 1a release 0.9.0 di netKar e il 100% delle versioni Alpha era stato realizzato da me e a quel tempo non avrei mai immaginato di trovarmi nella situazione di avere un grande artista 3D che lavorasse sulla simulazione a tempo pieno.

L’approccio attuale è basato su un editor 3d personalizzabile che si posiziona tra i pacchetti di editing 3D e la simulazione stessa; in questo editor il grafico può cambiare dozzine di parametri per ogni passo di texture e osservare l’effetto dei suoi cambiamenti in tempo reale poichè c’è il motore 3D attivo che gira in un’altra finestra.
E’ stato un po’ un casino arrivare ad una soluzione decente per integrare il motore 3D e l’interfaccia utente necessaria ad un editor interattivo. Ho provato molte soluzioni per risolvere il problema che il mio motore 3D è basato su MS VisualStudio mentre l’interfaccia utente è basata sul Borland C++ Builder. Ho fatto molti tentativi con le managed C++ extensions di VS ma ho trovato molto molto difficile integrare managed code con non managed code, di fatto impossibile.
La decisione è stata quella di usare il protocollo UDP per mettere in piedi una comunicazione tra l’interfaccia utente e la 3D "view application" scritta con Visual Studio, un po’ complicato ma più facile che provare a tirar fuori una interfaccia utente personalizzabile basata sulle DirectX.

Sto pensando di fare più esperimenti con C++ Builder usando le DirectX9 provando a far girare il 3D dentro le sue proprie finestre, potrebbe essere molto utile avere una vista “renderizzata” senza far partire la simulazione.

Questo farebbe alzare i costi per me dato che la mia licenza del C++ Builder è per solo uso non commerciale,quindi avrei bisogno di aggiornarla a quella commerciale.

Un altro grande cambiamento fatto questa settimana è stata la rimozione completa del sistema a dll usato in nk sin dall’inizio. Il nuovo nKpro è basato al 100% sul concetto del nK|dK, per cui non c’è più bisogno di una dll per ogni auto visto che i dati sulle auto sono contenuti nel database del nK|dK. Questo complica un po’ le cose quando c’è bisogno di nuove funzionalità e comportamenti "particolari"; con nK 099 se volevo che la MG si comportasse in una maniera particolare dovevo solo caricare il codice della dll della MG dentro VS e scrivere il codice del nuovo comportamento in maniera nativa in C++. Ora, ipotizzando lo stesso scenario dovrò pensare a come integrare questa funzionalità dentro nK|dK e poi implementarla nella simulazione. Questo comporta il dovere ragionare di più in proiezione futura ma, una volta fatto, è più facile testarlo su auto differenti poichè tutte ‘passaranno’ per lo stesso blocco di codice, quindi se l’ABS funziona per la MG si suppone che funzionerà per tutte le altre che lo implementano.

Da un punto di vista puramente ingegneristico nKpro è più semplice di nK 099 poichè è costituito da 2 soli file (l’interfaccia e la simulazione) senza dll addizionali dato che ho spostato il codice del vecchio nkClient.dll code dentro nks.exe. Questo rappresenta un piccolo aumento nelle prestazione dato che il compilatore non dove gestire tutte le interfaccie tra i moduli dll. Ora la classe dell’applicazione principale (CKar2.cpp) ha un puntatore diretto alla classe auto (CCar) e non ad un interfaccia per la classe auto (ICar).

Anche se non necessario ho deciso di mantenere le impostazioni per la generazione del codice in VS per usare le librerie per le DLL Multithread, voglio ancora mantenere aperta la possibilità di avere "plugins". Lo scenario qui è il seguente, se ho realmente necessità di modificare un comportamento veramente “unico” in un auto, posso scrivere un "plugin" per la simulazione che può reagire ai diversi eventi implementando una funzione virtuale e accedendo agli elementi interni alla sim. Probabilmente la IA potrebbe usare questo sistema, altre applicazioni interessanti potrebbero essere una telemetria personalizzabile oppure elementi strani come “ventole” o alettoni mobili (n.d.daf: qui nn sono sicuro cosa intendesse: se rimovibili o modificabili).

La fisica è una bomba, è una delle parti di nK che rilascerei tranquillamente anche domani. I bug principali riguardanti le barre anti-rollio e il camber erano già stati sistemati sulla versione 099 e ora la macchina è praticamene perfetta, fa ciò che uno si aspetterebbe che faccia in ogni condizione, ed è così “regolare” che, una volta imparato cosa aspettarsi dall’auto ci si può veramente divertire derapando in ogni dove.

Le barre anti-rollio sono state un problema sin dall’inizio a causa di mie assunzioni iniziali errate. Ogni versione di nk ha utilizzato una sorta di escamotage per risolvere il problema, ma il problema si può riscontrare facilmente nella 099, basta girare a donington con una 3000 o MG con barre molto rigide. Nell’ultimo tratto, nella prima curva verso destra basta prendere il cordolo nel punto di corda, ed è probabile che l’auto salti in aria avvitandosi.. è il vecchio codice per le barre che da di matto...
È una manifestazione molto evidente del problema ma il comportamento “errato” incideva sull’auto in ogni manovra, il nuovo codice per le barre, ha fatto imbestialire Aris che se ne è uscito mesi fa su MSN con un "ma che hai fatto? E’ UN ALTRO gioco!".

La formula per il camberaggio soffriva di un altro stupido problema legato ad una mancata divisione per il carico sulle gomme rendendolo tremendamente instabile.
Dopo il fix di questi due bug principali il solo aggettivo che può descrivere la fisica di nK è "liscia", al momento, alcune volte “troppo” liscia, stiamo cercando di rendere le piste un po’ più "vive".

Ho anche riscritto da capo il codice per la risposta alle collisioni con muri, e sono molto soddisfatto dei risultati, ora l’auto rimbalza con il giusto valore di "ammortizzazione strutturale", graffia il muro quando lo si urta da un lato e così via.

Per la gioia di Kidcodea ora l’auto non scompare sotto il terreno quando si rigira;-).

Ho aggiunto sulla homepage il tasto per le donazioni "PayPal". Questo progetto non ha niente da offrire come download o altro, ma netKar gratuitoha regalato a molta gente ore di divertimento in questi 2 anni, quindi se vi sentite a disagio per questo fatto, c’è il tasto magico che allontanerà la vostra sensazione di colpevolezza ;-).

È una piacevole sensazione l’essere tornati sul progetto netkar, è un vero stress che mi potrebbe far uscire matto visto che devo ancora dividere il mio tempo tra il lavoro e nKpro, ma è incredibile cosa possano fare un paio di ore di differenza sulla mia sveglia ;-), dopo tutto sono molto fortunato ad abitare a 10 minuti dal mio ufficio, e questo, a Tokyo, è un vero privilegio. Spero che la vendita di nKpro V1.0 risolverà questo "problema" e mi permetterà di rendere nK il mio unico "obbligo" nella vita.
alla prossima.
ciao
stefano"

[Buffus]

è ingiocabile via tastiera?

[rookie]

Originariamente inviato da Buffus
è ingiocabile via tastiera?

Sì, niente tastiera, niente aiuti di guida, niente visuali esterne.

In futuro si vedrà, ma credo rimanga così.

[Buffus]

quindi senza volante è ingiocabile....esatto?

[noxius]

se mi implementate la possibilità di driftare senza perdere subito il mezzo vi finanzio netkar 2 :=)

potreste prendere spunto dalla fisica di Live for speed.

ho provato tutte le auto ma è impossibile derapare con qualsiasi tecnica.

niente freno a mano, niente pendolo, niente sovrasterzo di potenza.

nel senso che la macchina parte via subito e non si può gestire la sgommata.

per me è importante

[giova22]

peccato non sia più gratuito.

A mei giochi di machcine non piacciono tanto. Cio voul dire che lo dimenticherò divanetando a pagamento

[rookie]

Originariamente inviato da noxius
se mi implementate la possibilità di driftare senza perdere subito il mezzo vi finanzio netkar 2 :=)

potreste prendere spunto dalla fisica di Live for speed.

ho provato tutte le auto ma è impossibile derapare con qualsiasi tecnica.

niente freno a mano, niente pendolo, niente sovrasterzo di potenza.

nel senso che la macchina parte via subito e non si può gestire la sgommata.

per me è importante

A scanso di equivoci.....io non c'entro nulla con lo sviluppo, sono solo uno che si diverte un mondo con nK


Ah......e poi si drifta che è un piacere, basta prenderci la mano, ci sono in giro un paio di video, se vuoi te li linko.

[rookie]

Originariamente inviato da Buffus
quindi senza volante è ingiocabile....esatto?

Non proprio, con un pad analogico si guida e si fa pure forte, ma non è ovviamente la stessa cosa di un buon volante con FF

[Zappz]

c'e' qualche screen in giro per vedere la grafica?

[rookie]

Originariamente inviato da Zappz
c'e' qualche screen in giro per vedere la grafica?

Lo sviluppo di nKpro è appena agli inizi, invece per netKar puoi guardare tra gli altri:


http://www.nkzone.com/Default.asp
http://netkarworld.altervista.org/
http://fab9000.altervista.org/
http://70gtmod.no-ip.com/index.php?s=&act=portal

[rookie]

Le cose sembrano procedere molto bene, oggi è uscito un altro rapporto sui progressi di nKpro, tra le varie cose c'è anche un bel filmato che fa vedere una delle nuove funzioni implementate, il Per Pixel Rendering.

http://www.netkar-pro.com/devreports/2004_8_12.htm

......BELLE COSE!!!!......

P.S. se serve si traduce in ita.......

[Cfranco]

Originariamente inviato da rookie
Dopo un po' di tentennamenti e silenzi, che avevano anche fatto pensare il peggio, finalmente ci sono grosse novità sul fronte netKar, IL (a mio giudizio) simulatore di guida, creatura di quel genio di nome Stefano "Kunos" Casillo.

Ieri è uscito il primo rapporto su quello che sarà il futuro di netKar, dico subito che la più grossa novità è che non sarà più gratuito, troppo il tempo che richiederebbe una nuova versione di nK se non si organizza tutto un altro tipo di lavoro, compresi dei fidati collaboratori (Kunos finora ha fatto tutto praticamente da solo).
[cut]

Rispondo qui perché se facessi le considerazioni che sto per fare sul forum di DrivingItalia non ne esco vivo ...
Dico solo una cosa :
A un titolo gratuito si perdona tutto , se pago NO .
E visto che ci sono altri progetti in pentola che sono gestiti da gente in gamba ( gli Ex-Papy , la banda di GTR ... no , i west non li conto proprio ) , il rischio di fare il passo più lungo della gamba e finire nella polvere esiste , per come la vedo io NetKar ha ancora molte , troppe lacune da riempire , quindi ... buon lavoro , spero che ci riesca ma sarà dura .

[Dias]

Originariamente inviato da rookie
A scanso di equivoci.....io non c'entro nulla con lo sviluppo, sono solo uno che si diverte un mondo con nK


Ah......e poi si drifta che è un piacere, basta prenderci la mano, ci sono in giro un paio di video, se vuoi te li linko.

Linka.

[rookie]

Originariamente inviato da Cfranco
Rispondo qui perché se facessi le considerazioni che sto per fare sul forum di DrivingItalia non ne esco vivo ...

Vero , in parte, le opinioni anche contrarie, purchè esposte im maniera civile ed intelligente credo siano ben accette, già qualcuno ha sottolineato quello che dici tu, che mi pare giusto.

Dico solo una cosa :
A un titolo gratuito si perdona tutto , se pago NO .
E visto che ci sono altri progetti in pentola che sono gestiti da gente in gamba ( gli Ex-Papy , la banda di GTR ... no , i west non li conto proprio ) , il rischio di fare il passo più lungo della gamba e finire nella polvere esiste , per come la vedo io NetKar ha ancora molte , troppe lacune da riempire , quindi ... buon lavoro , spero che ci riesca ma sarà dura .

Beh, io sono uno di quelli che pur con tutte le sue lacune, pagherebbe anche per un nK così com'è ora, magari con alcune cosette sistemate. E' ormai da abbastanza che ci gioco per giustificare un mio supporto al progetto nKpro, che ho già dato.

L'altro giorno in game parlavo con un tizio straniero che è qualcuno a GPL.......ebbene, tanto per fare un esempio lui ritiene che la fisica della Supra di nK sia già così com'è superiore a quella della Lister della demo di GTR, che tanti consensi ha avuto, è la stessa cosa che penso io, solo che il sottoscritto non ha certo l'autorità per dirlo......
Se leggi il primo report Kunos dice che la fisica di nKpro è già ora perfetta grazie ad un paio di modifiche apportate, io gli credo e questo è quello che mi fa essere fiducioso.
E' quasi incredibile quello che è riuscito a fare Kunos praticamente da solo, posso solo immaginare cosa possa uscire fuori con le persone giuste coinvolte nel progetto che si occupano di cose di cui lui non è più di tanto in grado (grafica) o a cui non è interessato (netcode). Poi non è mai stato nemmeno un gran PR di sè stesso, ora c'è chi se ne occupa......

La base degli appassionati di nK è bella solida, anche se non numerosissima, ma vedo che anche all'estero si sta facendo onore, speriamo bene

[rookie]

Originariamente inviato da Dias
Linka.

http://www.oldteam.net/Users/outrunner/rijeka_drift.wmv

http://utenti.lycos.it/ecio78/netkar/

[rookie]

Kunos ha dichiarato che la versione 1.0 di nKpro è SICURO che uscirà , è dal successo che avrà che ne dipende il futuro.

[rookie]

....ormai è un appuntamento settimanale, Kunos sta lavorando duro......

http://www.netkar-pro.com/devreports/2004-08-19.htm

Traduzione in italiano by pala......non perfetta ma si capisce

http://www.drivingitalia.net/forum/i...=post&id=12105

[rookie]

Ancora aggiornamenti, questa volta si scende molto sul tecnico.....

http://www.netkar-pro.com/devreports/2004_08_26.htm

Traduzione, fatta da me stavolta

"26 agosto 2004

PUNTI DI VISTA NELLA FISICA
Stavo seduto da Starbucks di fronte a "Computational Dynamics" di Shabana,
pensando alle implicazioni di una delle sue dichiarzioni.
Sembrava molto simile a quello che anche Katz spiega nel suo libro di
Aerodinamica a Basse Velocità e recitava pressapoco così:
"Qualche volta, in fisica, scegliere la giusta struttura di riferimento(*) potrebbe fare la differenza tra un problema con una soluzione e un problema senza".
Avevo passato la notte prima a studiare fino a tardi per trovare una soluzione
al mio codice di cambio/trasmissione(*). Ho scritto qualcosa al proposito un paio di anni fa, è andato perso nei meandri di internet, ma ricapitolo in breve la situazione.
In nK la trasmissione è simulata usando un "network" di componenti a ingranaggi.
La maggiore influenza dell'averlo disegnato in questo modo viene da qui:

http://www.bausch-gall.de/powertrn.htm

La possibilità di organizzare un infinito numero di combinazioni semplicemente connettendo
semplici parti insieme mi ha eccitato, quindi ho cominciato. Tutto andava bene con semplici
nodi di ingranaggi, frizioni, moltiplicatori a ingranaggi(*), ma tutto andava a puttane
(libera interpretazione nd rOOk ) con i differenziali. Alla fine della giornata la soluzione fu un "trucco" che, di fatto, rese impossibile utilizzare il network in una maniera "creativa": il differenziale presumeva che non ci fosse nulla dopo di esso a parte un asse con un pneumatico.
Non era un enorme compromesso, diede comunque la possibilità a nK di simulare trazioni anteriori e posteriori senza problemi tramite qualche elaborata implementazione di differenti differenziali.
Ma il codice era VERAMENTE complesso e incasinato, ogni volta che dovevo cominciare qualche lavoro sui differenziali ero impaurito dall'ammontare di codice da "ri-imparare", dovevo pensare a qualcosa di diverso per nKpro.

Il primo approccio è stato provare ad assimilare il differenziale ad un oggetto 3D, attualmente una leva con un perno al centro e input provenienti dalle ruote. L'idea venne da RCVD di Milliken, dove egli faceva questo esempio per spiegare i differenziali.
Era un casino, non funzionava ed era in ogni caso un'enorme spreco di potenza di calcolo della CPU. Un passo indietro.
In seguito provai a pensare ad un semplice sistema "constrained lagranian"(*) per rappresentare l'intero network di ingranaggi e questo mi riportò al libro di Shabana fino a notte tarda. Era un salto nel buio, ridisegnare un sistema come quello da zero usando formule con le quali non avevo più confidenza avrebbe richesto secoli, ma andava fatto.

Ma l'originale dichiarazione circa la "struttura di riferimento" continuava a farmi pensare e quindi mi chiesi: "sei sicuro di star analizzando il problema dal giusto punto di vista?". Essendo scarso in terimi di "analisi del futuro", la sola possibilità di provarlo era sedere e cercare di codificare un "approccio differente".

In nK 0.9.X il network di trasmissione è basato sulle coppie. I singoli pezzi si scambiano la coppia a vicenda e reagiscono a queste coppie. Il trucco è mandare la "coppia residua" al prossimo livello. Ecco un esempio:

O1-O2-O3

Questi sono 3 oggetti rotanti connessi assieme, non hanno alcun moltiplicatore, infatti agiscono come un singolo oggetto, ma nel network essi sono _ancora_ separati. Se una coppia T viene applicata a O1, come posso io muovere questa coppia ai vari oggetti per avere le corrette accelerazioni e le velocità finali?
Iniziando da O1 io calcolo quella che chiamo "l'effettiva inerzia vista da O1", questo viene fatto chiedendo agli oggetti connessi di riportarla, è come andare giù di un albero(*) (forse di un livello nd rOOk) e accumulare un valore. Ora, se O1, O2 e O3 hanno tutti un'inerzia di 1, l'inerzia "vista" da O1 dovrebbe essere 3. Così se applico la coppia T a quest'inerzia e accelero O1, giusto quello che dovrei fare con O2 e O3, che coppia riceveranno? Essi ricevono la coppia originale MENO la coppia utilizzata per accelerare O1, e le cose procedono a questo modo attraverso il network.

L'inizio del mio aproccio "differente" era cercare di evitare di mandare coppie in giro, "salire di un livello" e mandare accelerazioni. Questo aveva un grosso vantaggio, una volta che io avevo l'inerzia effettiva "vista" dal "generatore" di coppia, tutto quello che dovevo fare era calcolare l'accelerazione e propagare QUEL valore attraverso il network. Quendo un oggetto riceve un'accelerazione, non deve pensare alla sua inerzia e a quanta coppia sta assorbendo, ma semplicemente accelerare e passare lo stesso valore di accelerazione al nodo successivo.
Funzionò in 10 minuti e taglia il mio codice di un buon 50%, ora, nei differenziali.
Avevo bisogno di un'altra "idea" per risolvere un problema coi differenziali. Per determinare lo stato di un differenziale, TUTTI i 3 input devono essere conosciuti. Attualmente, quello che è veramente importante è avere gli input delle 2 "ruote". In nK 0.9.X il differenziale "registrava" la coppia proveniente dal pneumatico sinistro nella memoria aspettando il valore di quello destro per risolvere l'equazione. Questo approccio potrebbe essere ancora valido, ma introdurrebbe una sorta di lista di "attesa" nel network e, più importante, il sistema doveva mandare le coppie ai differenziali nell'ordine esatto.
Quello che sto facendo ora invece è un "buffered solver" (soluzione di buffer? nd rOOk). In parole povere, il differenziale sta decidendo come distribuire le accelerazioni usando le informazioni "dell'ultimo istante" del suo buffer di accelerazione. Questo introduce un leggero ritardo nel sistema, (lungo quanto una singola frazione fisica, che in nK è di 3ms) ma lo scostamento numerico è accettabile.

Oltre le mie migliori aspettative, stavo guidando un'auto a quattro ruote motrici "custom" in nKpro la scorsa notte, ed ero eccitato e affascinato da quanto velocemente questo "problema" era stato risolto. Il codice è ora dannatamente semplice, differenziali Open, Torsen e Salisbury sono stati implementati senza problemi in poche ore ed è stata fatta anche una base per un differenziale mappato elettronicamente. Devo ancora pensare alle implementazioni di differenziali a coppie separate irregolarmente, così importanti delle quattro ruote motrici, ma le cose stanno venendo così bene che non ci posso credere.

GRAFICA
Tornando al report, a parte gli ultimi 2 giorni, la settimana è stata ancora dedicata alla grafica. Ho implementato un sistema di shadow mapping, ma per gli spazi aperti è necessaria un'enorme "mappa d'ombra". Ho provato fino alla 1024x1024, ma l'ombra risultante sfarfallava ancora molto. Quello che è bello delle shadow maps è che sono indipendenti dalla geometria, tutto quello di cui hanno bisogno è di un passaggio addizionale per calcolare la "mappa d'ombra", ma sono facili da usare e capire. é un vero peccato che non funzionino bene per le luci direzionali e i grandi spazi.
Sono tornato alle lightmaps che appaiono molto più belle, anche se hanno il problema di essere statiche, mentre con le shadow maps, tu dici: bene, il sole è qui....andiamo e loro vengono fuori, incluso il self shadowing!
Probabilmente implementerò le ombre volumetriche stencil shadow alla Doom3, anche se, come ho già detto, non siano molto utili con oggetti come alberi e reti.

Outrunner sta sperimentando le normal maps al momento, per aggiungere dettagli agli oggetti senza incrementare il carico sul poly count, non vedo l'ora di vedere qualche risultato.

SETTEMBRE
Dalla prossima settimana sposterò la mia attenzione dalla grafica alla fisica e al multiplayer. L'aerodinamica sarà profondamente rimaneggiata, sto anche introducendo una struttura di sospensione McPherson reale e anche qualche geometria di sospensione posteriore vecchio tipo.

Alla prossima......"

(*) queste sono le cose che non ho capito bene o che non riesco a tradurre.....

[Vash88]

corro a comprarmi un volante

Comunque qello che gli servirebbe veramente è una persona abile nel 2D, per le texture che dalle fotonon sono esaltanti nella vecchia versione.

[REPSOL]

Io ho scaricato una volta netkar quando avevo la 8500, lo provai 5 minuti min qeui cinque minuti mi avrà fatto 50 frames

LOLOLOL