Dev Report 4: 26 Agosto 2004

[marcobrd]

fiiiico

[frenk67]

qualche buon anima può fare la traduzione?

[Guest Massi]

l'altro giorno stavo pensando di dire ad out "senti, ma alle normal maps non avete pensato? si fanno cose parecchio interessanti" ma poi sono stato zitto pensando che dopo i PS mi avrebbe solo insultato..

Non ce n'era bisogno, fanno da soli

[Guest rOOk]

qualche buon anima può fare la traduzione? 

214214[/snapback]

E come no?

"il 26 agosto 2004 PUNTI DELLA VISTA NELLA FISICA Stavo sedendosi in Starbucks che staring al "Computational Dynamics" di Shabana's; pensando alle implicazioni di una delle sue dichiarazione. Ha suonato molto simile a che cosa inoltre Katz spiega in suo libro a bassa velocità di Aereodynamics ed era, basicamente qualcosa come: i "Sometimes, in physic, scegliente la giusta struttura di riferimento potrebbero essere la differenza fra un problema con una soluzione e un problema without.". Avevo passare la notte prima di studiare fino a in ritardo per trovare una soluzione al mio codice di transmission/drivetrain. Ho scritto qualcosa circa questo una coppia degli anni fa ma ha ottenuto persa nel Internet, così, brevemente io ricapitola la situazione. Nel nK la trasmissione è simulata usando un "network" dei componenti innestati. L'influenza principale nella progettazione del questo senso è venuto da questa: http://www.bausch-gall.de/powertrn.htm La possibilità di organizzazione del numero infinito di combinazioni che collegano appena le parti di base insieme lo ha ottenuto eccitato, in modo da ho cominciato. Tutto è andato benissimo con i nodi di base dell'ingranaggio, frizioni, moltiplicatori dell'ingranaggio ma il hell si è rotto liberamente con i differenziali. Alla conclusione del giorno, la soluzione era un "hack" quello, de-facto-facto, reso impossible realmente usare la rete in un "creative" senso: il differenziale ha dovuto presupporre che ci fosse niente "after" loro ma un asse con il pneumatico. Quel wasn't un affare enorme, ha dato a nK la possibilità per simulare RWD ed il FWD nessun problema con una certa esecuzione ingannevole dei differenziali differenti. Ma il codice era REALMENTE complesso e scompigliato in su, ogni volta che ho dovuto avvicinarsi ad un certo lavoro sui diffs che sono stato spaventato dalla quantità di codice a "re-learn", Ho dovuto fare qualcosa circa questo in nKpro. Il primo metodo stava provando ad assimilare il differenziale ad un oggetto 3D, realmente, ad una leva con un perno nel centro ed agli input che vengono dalle rotelle. L'idea è venuto da Millikens' RCVD dove fa questo esempio per spiegare i differenziali. Era un mess, che esso il lavoro di didn't esso era comunque uno spreco enorme di alimentazione del CPU. Di nuovo al quadrato uno. Allora ho provato a pensare ad un sistema lagrangian costretto di base per rappresentare l'intera rete innestata e quella lo ha ottenuto nuovamente dentro il tomo di Shabana's fino a in ritardo alla notte. Era uno shot" del "long;, per riprogettare un sistema gradisca quello da zero usando le formule che non ho una conoscenza di con più stavo andando prendermi le età, ma ha dovuto essere fatto. Ma quella dichiarazione originale circa la struttura di riferimento lo ha mantenuto pensare ed allora mi sono chiesto: "are voi you're sicuro che analizza il problema dal giusto punto di view?". Essendo un analysis" difficile di "forward; la persona, l'unica possibilità per dimostrarla doveva sedere giù e provare a codificare un approach" "different;. Nel nK 0.9.x la rete della trasmissione è basata sulle coppie di torsione. Le parti singolari trasmettono l'un l'altro le coppie di torsione e reagiscono a queste coppie di torsione. Il trucco deve trasmettere il torque" "residual; alla fase seguente. Let's hanno un esempio: O1-O2-O3 Questi sono 3 oggetti di rotazione collegati insieme, che don't hanno tutto il moltiplicatore affatto così, infact fungono da un singolo oggetto, ma, nella rete è _ ancora _ separa. Se una coppia di torsione T fosse applicata su O1 come potrei sposti questa coppia di torsione verso il vario oggetto per ottenere le accelerazioni corrette e le velocità finali? A partire da O1 calcolo che cosa denomino il intertia "effective visto da O1", ciò è fatta che chiede agli oggetti collegati per segnalarlo, è come andare giù un albero ed accumulare un valore. Ora, se O1, l'O2 ed O3 avessero tutto un intertia di 1, il "seen" di inerzia; da O1 sia 3. Così applico la coppia di torsione T a questa inerzia ed accelero O1, destra che cosa dovrei fare con l'O2 ed O3, che coppia di torsione ricevo? Ricevono la coppia di torsione originale MENO la coppia di torsione usata accelerano O1 e la cosa accende durante la rete. L'inizio del mio "different" il metodo stava provando ad ottenere via dalla trasmissione delle coppie di torsione intorno ed a provare ad andare "up un level" e trasmetta le accelerazioni. Ciò presenta un vantaggio grande, una volta che ho il "seen" efficace di inerzia; dal "generator" di coppia di torsione; tutto che debba fare deve calcolare l'accelerazione e propagare QUEL valore attraverso la rete. Quando un oggetto riceve ed accelerazione che doesn't deve pensare al intertia di it's e quanta coppia di torsione it's che assorbe, ma appena acceleri e passi molto lo stesso valore di accelerazione sopra al nodo seguente. Ha funzionato in 10 minuti ed ha ridotto il mio codice da un buon 50%, ora, sui diffs. Ho avuto bisogno di un altro "idea" per risolvere un problema con i diffs. A determinato la condizione di un diff, TUTTI GLI 3 input deve essere conosciuta. Realmente, che cosa è realmente importante deve avere il "wheels" 2; input. Nel nK 0.9.x il diff era "recording" la coppia di torsione che viene dal pneumatico di sinistra nella memoria che attende per avere il valore dal pneumatico di destra realmente per risolvere l'equazione. Questo metodo potrebbe essere ancora valido ma introdurrebbe una specie di "waiting" elenchi nella rete e, più importante, il sistema ha dovuto trasmettere le coppie di torsione ai diffs nel giusto ordine. Che cosa ora sto facendo preferibilmente è a "buffered il solver". In un senso semplice, il differenziale sta decidendo come distribuire le accelerazioni usando le informazioni dal frame" del "last;, cioè dall'amplificatore di accelerazione di it's. Ciò introduce un molto piccolo fa ritardare nel sistema (finchè una singola struttura di fisica, cioè, nel nK, 3ms) ma la direzione numerica è accettabile. Oltre le mie aspettative migliori stavo guidando un "custom" l'automobile 4wd in nKpro la notte scorsa ed io è stato eccitato e stupito stato da quanto rapidamente questo "issue" è risolto stato. Il codice ora è semplice mortale, aperto, i diffs de Salisbury e di Torsen sono stati effettuati letteralmente senza i hassles in poche ore e una base per un diff elettronicamente tracciato inoltre è stata fatta. Ancora devo pensare alle implicazioni dei diffs spaccati di coppia di torsione irregolare, così importante in 4wd, ma le cose stanno osservando in modo da la buona I can't lo crede. GRAFICI Di nuovo al rapporto, oltre all'ultimo 2 giorni la settimana ancora è stata dedicata ai grafici. I've ha effettuato un sistema di tracciato dell'ombra, ma per l'ambiente dello spazio all'aperto un programma enorme dell'ombra è necessario. Ho provato fino a 1024x1024, ma l'ombra risultante era "flickering" tranquillo; mólto. Che cosa è piacevole circa i programmi dell'ombra è che sono indipendent dalla geometria, tutto che abbiano bisogno di è un passaggio supplementare per calcolare il programma dell'ombra, ma, they're facile usare e capire. It's uno shame lavoro di don't grande per le luci direzionali e gli spazi grandi. Sono di nuovo ai lightmaps che osserva il tho che uniforme molto più grazioso hanno il problema da essere statico mentre con ombra che li traccia dica; bene, il sole è là. accenda ed escono, compreso l'ombreggiamento di auto! Probabilmente effettuerò il tho they're dei volumi dell'ombra dello stampino di stile Doom3 persino, io detto questo prima, non realmente utile con le cose come gli alberi e le recinzioni. Outrunner ora sta sperimentando con i programmi normali per aggiungere i particolari ad oggetto senza aumentare il carico sul conteggio del poligono, attesa di I can't per vedere alcuni risultati. SETTEMBRE Dalla settimana prossima sposterò la mia attenzione dai grafici alla fisica e multiplayer. Aereodynamics sta andando essere ripreso mólto ed inoltre sto introducendo una sospensione reale del puntone di McPherson ed alcuni vecchi geometries della sospensione della parte posteriore di stile pure. di nuovo voi il tempo prossimo."

P.S. per le cose serie se quacuno non fa prima vedo di farla più tardi......

[Guest 17mika]

Faccio un riassunto brevissimio che poi devo studiare..

FISICA

Si parla della trasmissione e del differenziale..

in nkla trasmissione è simulata come un network di componenti collegati.. quando un paio di anni fa kunos la codificò ci furono casini col differenziale per cui in buona sostanza non si riusciva a mettere niente dopo al differenziale (a parte semiase e ruota) e questo rendeva una bel caos creare differenziali diversi, per non parlare della macchina con + differenziali. bisognava risistemare il tutto.

La prima idea è stata quella di creare un modello in 3d, ma non andava un grran che e spendeva una sacco di cpu, la seconda di usare un sistema lagrangiano per l'intera trasmissione, ma era un casino anche quello.

Quindi l'idea di ripensare completamente la trasmissione. se in nk prima i vari ingranaggi si mandavano l'un l'altro una certa coppia e reagivano di conseguenza, l'idea è stata quella di basare il modello sulle accelerazioni, anzichè sulla coppia. e questo ha risolto un pò d problemi. kunos è riuscito x esempio a fare una macchina con un bel torsen in mezzo senza nessun problema, e con un codice relativamente semplice.

In particolare è stato poi cambiato come il differenziale distribuisce le accelerqazioni. Prima si memorizzavano i valori di coppia della ruota sinistra in una waiting list e si aspettavano i valori della destra per risolvere l'equazione. Ora invece il differenziale (detto semplicemente) guarda i valori di accelerazione dei 2 semiassi del "ciclo" precedente... fa così tutto con 1 ciclo di ritardo, ma visto che si parla di ms, non è un problema.

Grafica

Evito che non saprei tradurre, non capenndoci proprio una cippa di grafica

Settembre

L'attenzione si muoverà soprattutto su fisica e Multi.

Kunos rifarà buona parte del modello aerodinamico e lavorerà su un modello del McPherson e di alcune sospensioni posteriori di qualche anno fa.

[Guest rOOk]

Sto facendo la traduzione.....non vi azzardate a precedermi

[Guest rOOk]

Ecco qua.....non l'ho nemmeno riletta, spero vada bene

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 ingranaggio.

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 multiplicatore, 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(*) 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ì il 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? Non so come tradurre 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 mapa, 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 polygon 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.....

[Guest Vange]

ma lol...

qiuanti volenterosi!

[frenk67]

kunos sei un grande

[Guest Fisichella]

A parte Kunos i miei complimenti sempre....

Ma questa volta un bell applauso anche a 17mika e rOOk per l'impegno nel mettervi a tradurre