Jarvis - versione dll

quando uno è furbo... quanti secondi ci sono in 5 minuti? 300... ma nella dll ho messo 500...  dopo lo correggo!

fred18 ha scritto:

quando uno è furbo... quanti secondi ci sono in 5 minuti? 300... ma nella dll ho messo 500...  dopo lo correggo!

    

E comunque complimenti per lo sbattimento. Se mi riesce lo provo nel weekend, sperando di trovare tutti i comandi.

Ho fatto altre prove.. tutto continua a funzionare perfettamente!

A questo punto c'è un'ultima cosa relativa al realismo che sarebbe giusto implementare. Vorrei tranquillizare Fred, non si tratta di nulla relativo al countdown o alle date di lancio.  
Per spiegarvelo vi propongo questo video:



E' il lancio dell'Apollo 11. Il primo stadio del Saturno V funziona esattamente come quello del nostro Jarvis. Noterete che con l'aumentare dell'altezza i getti di scarico aumentano di volume per la diminuzione della pressione, e la luce di incandescenza diminuisce.

Implementare una cosa del genere dovrebbe essere abbastanza semplice. Nella funzione che imposta gli attributi delle particlestream ci sono le variabili double srcsize (che determina la grandezza degli scarichi in metri) e lifetime (che determina la durata in secondi). Sarebbe sufficiente legarle alla pressione atmosferica e farle variare di conseguenza all'interno di clbkPostStep. Avremmo un bell'effetto spettacolare e realistico.

Per l'incandescenza invece non bisognerebbe toccare nulla. Se notate durante i lanci è Orbiter stesso che con l'aumentare dell'altezza fa diminuire l'intensità della sorgente luminosa degli scarichi. Dunque quella è un lavoro in meno da fare.

Bisognerebbe trovare la relazione matematica tra la pressione e l'espansione dei gas.
Analizzando il video ho notato che ad una pressione di 540 pascal (64 km di altitudine) il diametro  dei getti dovrebbe essere di circa 105 metri, mentre a 101100 pascal (livello del mare ) è 4,8 metri. Ciò significa che il diametro degli scarichi aumenta di 1 metro ogni -957,7 pascal.

Quindi il valore di SRCSIZE dovrebbe essere dato da 4.8+((101100-P)/957.7) dove P è la pressione atmosferica in pascal.

Questo è il valore più importante, per gli altri bisognerebbe fare delle prove.. forse anche sul valore growthrate (crescita del particle in m/s) bisognerebbe giocare, ma al limite ci do un'occhiata io.. Fred dimmi se hai voglia di fare questa ennesima aggiunta

eheh farò questo sforzo    

in realtà però c'è un problemino: le particlestreamspec sono statiche in c++, che io sappia il size non si può modificare dinamicamente.

infatti bisogna definire all'interno delle particle stesse la mappatura in funzione dell'atmosfera e del livello del motore.

il trucco potrebbe essere quello di aggiungere una particle e di impostare per essa una mappatura atmosferica inversa, che invece di diminuire di intensità con lo scendere della pressione aumenta, comparendo sempre più intensa man mano che il jarvis sale verso il cielo. tra oggi e domani ci provo, anche perché domenica parto e per una settimana non ci potrò mettere mano

ci avevo pensato anche io a questo effetto, ma io lascerei francamente tutto così... già adesso le particlestream dei nostri vettori sono molto realistiche...

Beh vedremo cosa riuscirà ad ottenere il nostro fred nazionale, se la cosa si rivelerà ardua lasceremo così senza nessun problema  

Amici,

un rapido aggiornamento: mi sono accordo di un bug  

chiudendo la simulazione con il secondo stadio in orbita e riaprendola me lo ritrovavo pieno zeppo di carburante, indipendentemente da come lo avessi lasciato.

Ho dato un'occhiata e mi sono accorto che nel codice la funzione che settava la modalità secondo stadio creava anche ex novo il serbatoio dell'HES. Insomma, ora non sto qui a spiegarvi tutto nel dettaglio che sarei noioso, comunque ho modificato il codice e ora funziona a dovere. L'unica cosa è che negli scenari di lancio non basta più che la riga del carburante sia:

PRPLEVEL 0:1.000000

indicando solo un serbatoio, ma deve diventare:

PRPLEVEL 0:1.000000 1:1.000000

indicando che entrambi i serbatoi (primo e secondo stadio) sono pieni.

in effetti questa modifica aggiunge in qualche modo un filo più di realismo, anche se ce ne accorgeremo in pochi :-)

ho già modificato tutti i file scenario, ed aggiornato il pacchetto.

Per quanto riguarda l'effetto che chiedeva fausto, ho fatto una prova, e l'ho inclusa qui. Non mi soddisfa granché, ci devo lavorare molto di più, ma non ho avuto un secondo  

Ecco il solito link:

JARVISs

Intanto sto provando ad implementare il sistema di guida PEG per i veicoli con più di due stadi (servirà per le versioni più grandi del Jarvis) ma è un bel po' difficile. Ho chiesto aiuto anche su OH, vedremo. In qualche modo comunque ci riusciremo, ho già qualche idea no worries  

A presto!

 

Sono curioso: perché il PEG dovrebbe andare in difficoltà con più di due stadi? Qual è la differenza? Lo chiedo perché mi ricordo che anche il LAUNCH MFD funziona solo per veicoli con massimo due stadi.

Spero che la cosa non sia uno scoglio insuperabile; in ogni caso secondo me la risoluzione del problema ha la priorità sulla ricerca dell'effetto particlestream (che sarebbe bello senz'altro, ma non è fondamentale).

In realta' il sistema Peg implementato nel jarvis e dal launch mfd e' per un SSTO, ma in quasi tutti i vettori (shuttle, saturn e falcon compresi) il primo stadio funziona per portare il veicolo abbastanza in alto e abbastanza velocemente da far entrare in azione il peg. Il jarvis s durante il primo stadio fa in pratica solo una lunga gravity turn, e appena accende il secondo stadio il peg inizia a fare il suo mestiere.
Le equazioni del peg sono parecchio complicate, ma con l'opzione SSTO, alcune cose si semplificano. Usando invece piu' stadi iniziano a farsi un po' piu' complicate: bisogna includere le discontinuita' dovute allo staging, imponendo la continuita' nel tempo dell'andamento del pitch... il che aggiunge N altre equazioni da utilizzare.

In realta' il problema non sta molto nella difficolta' di programmare la cosa nella dll, perche' in realta' ho gia' implementato tutto, quanto nel fatto che seguendo il procedimento sia della documentazione nasa ufficiale, sia di chi ci ha provato prima di me qualcosa alla fine non torna... su OF Enjo, il creatore di launch MFD mi ha praticamente confermato che anche lui ha fatto tutti i passaggi ma poi la cosa non funzionava e non ha piu' avuto tempo di capire il perche'. Ho fatto un po' di test e la cosa che funziona meno con la versione multistadio del peg sono i cosiddetti steering integrals, che restituiscono valori totalmente fuori range... nonostante per la versione ssto funzionino perfettamente.

Questo pero' non mi fa disperare: nella dll del jarvis mi sono costruito un po' di funzioni che semplificano molto i calcoli e che sono convinto di poter utilizzare al posto degli steering integrals, devo solo mettermi li e fare un po' di prove. A far funzionare il Peg ci ho messo una vita perche' e' molto complesso da comprendere, ma ora che ho studiato e sono preparato le cose sono molto piu' chiare di prima e sono molto fiducioso. Al mio rientro sara' comunque una priorita' venire a capo della cosa!

Ho condotto altri beta test e non sono riuscito a trovare ulteriori bug a parte quelli già segnalati (e risolti). Ottimo lavoro!

Per il discorso delle particlestream mi è venuta in mente un'idea per ottenere l'effetto di espansione anche se il parametro SCRSIZE non è dinamico. Per non caricarti di altro lavoro ho deciso di crearmi una mia piccola dll che utilizzerà il primo stadio del Jarvis sul quale farò delle prove. L'unica cosa che ti chiedo è passarmi l'attuale PARTICLESTREAMSPEC con la mappatura atmosferica inversa che non ho ancora ben capito come funziona.. da quella proverò ad implementare la mia idea e se funziona come io spero potremo trasferirla sul Jarvis.

Domanda da profano: non rischiamo di appesantire troppo la dll?
La fluidità di simulazione deve essere la massima priorità, anche perché da essa deriva la realisticità di funzionamento dell'autoguida.
IMHO naturalmente...  

Con il sistema che ho in mente non credo proprio che l'appesantiremo.. ma è un mio tarlo e chissà magari poi è inattuabile.. vedremo

fausto appena ho sottomano un qualsiasi pc ti mando tutto!

Eccomi, allora, di seguito ti incollo la parte delle particle stream relative al main engine:

Codice:

//PS1
SURFHANDLE Jcontrail1 = oapiRegisterExhaustTexture ("Jarvis\\Jcontrail1");
static PARTICLESTREAMSPEC con1 = {
   0,      // flag
   4.8,   // size
   1500,      // rate
   160.0,       // velocity
   0.05,    // velocity distribution
   0.35,      // lifetime
   -0.4,   // growthrate
   0.5,    // atmslowdown
   PARTICLESTREAMSPEC::EMISSIVE,
   PARTICLESTREAMSPEC::LVL_PSQRT, 0, 0,
   PARTICLESTREAMSPEC::ATM_PLOG, 1e-4, 1.0,
   Jcontrail1
};



//PS2
SURFHANDLE Jcontrail2 = oapiRegisterExhaustTexture ("Jarvis\\Jcontrail2");
static PARTICLESTREAMSPEC con2 = {
   0,      // flag
   4.8,   // size
   1000,      // rate
   140.0,       // velocity
   0.0,    // velocity distribution
   0.2,      // lifetime
   -5,   // growthrate
   2,    // atmslowdown
   PARTICLESTREAMSPEC::EMISSIVE,
   PARTICLESTREAMSPEC::LVL_PSQRT, 0, 0,
   PARTICLESTREAMSPEC::ATM_PLOG, 0.7e-7, 1.0,
   Jcontrail2
};

static PARTICLESTREAMSPEC con3 = {
   0,      // flag
   4.8,   // size
   1500,      // rate
   160.0,       // velocity
   0.05,    // velocity distribution
   0.35,      // lifetime
   25,   // growthrate
   0.5,    // atmslowdown
   PARTICLESTREAMSPEC::EMISSIVE,
   PARTICLESTREAMSPEC::LVL_PSQRT, 0, 0,
   PARTICLESTREAMSPEC::ATM_PLOG, 1.0, 1e-4,
   Jcontrail1
};

e poi la ovvia assegnazione al motore principale (l'handle si chiama th_h[0]):

Codice:

AddExhaustStream(th_h[0],_V(0,0,-19.7),&con1);
AddExhaustStream(th_h[0],_V(0,0,-19.7),&con2);
AddExhaustStream(th_h[0],_V(0,0,-22),&con3);

La specifica che ho aggiunto è la con3, le altre 2 sono quelle standard con le specifiche prese da ms2

Per quanto riguarda quella che ho chiamato la "mappatura atmosferica inversa" mi riferisco al fatto che la mappatura atmosferica è impostata a PLOG e ma con i valori invertiti, cioè 1 e 1e-4. Il che significa che le particle non appariranno al livello del suolo, con pressione atmosferica standard e man mano che ci avvicineremo allo zero di pressione atmosferica appariranno sempre di più. Normalmente è alla rovescia.

Fammi sapere se poi ci riesci (senza massacrare gli fps ovviamente)! :-)

Mi volete stravolgere le particlestream che ho curato con tanto amore   

Immagino però che facendo così si percepisca molto bene che si tratta di due stream diverse, quella solita che gradualmente scompare e l'altra che appare, anziché una stream unica che si allarga, come dovrebbe essere. Mi sono fatto un'immagine mentale della cosa e secondo me non viene bene. Magari mi smentirete!

Comunque tre particlestream per ogni motore sono un massacro! Quando avremo il Quasar con 4 motori F-1 e un totale di 12 particlestream il mio computer sputerà sangue.

Andrew ha scritto:

... Quando avremo il Quasar con 4 motori F-1 e un totale di 12 particlestream il mio computer sputerà sangue.

 Si aprirà il case e verrà fuori una mano che ti dirà:

"Ahò, ma che vvoi da me?"
 

Andrew ha scritto:

...Quando avremo il Quasar con 4 motori F-1 e un totale di 12 particlestream il mio computer sputerà sangue.

Questa frase mi fà pensare che forse ci potrebbe essere spazio per un thread "tecnico" (pensato più per un uso tra voi developer) dove ognuno posta (e aggiorna) le caratteristiche del suo pc, in base ad uno schema uguale per tutti...
Giusto per avere idea del "parco macchine" FOI.

l'effetto delle due particle diverse fose un po' si vede, non so, comunque il primo rapido tentativo è inserito nell'ultima versione del pacchetto, ora vediamo se fausto riesce nell'intento :-) sennò lasciamo le originali! eventualmente si può decidere di escluderle con l'opzione lowres, non so,ditemi voi :-)

Devo dire che il mio pc sputa sangue durante il lancio con tutto quel fumo in giro, rallenta fino a 10-20 FPS se rimango vicino...

L'idea di ripley mi sembra ottima, così facciamo un database e scegliamo anche un target a cui puntare con gli addon!

Una causa pesante di rallentamento sono le mesh delle rampe, soprattutto la base Capo Passero... non so se siano state usate textures particolarmente pesanti o cosa... sta di fatto che quando ci si allontana la situazione migliora. Io agirei su quello... e terrei le particlestream originali.  

Francamente toglierei anche la scia di condensazione (non ricordo ora se l'avevi implementata o no). Io non l'ho mai voluta mettere proprio per questo motivo.

Per dire una mia considerazione personale, non mi piace dover selezionare l'opzione lowres e perdere TUTTI gli effetti: mi piacerebbe una unica impostazione ragionevole che consenta comunque di avere gli effetti più belli scartando quelli ridondanti e mantenendo una buona fluidità.

Mi pare che l'idea delle particlestream vada verso la bocciatura:bgrin: Temo che dovrò rassegnarmi!  

Le rampe sono state fatte un po di tempo fa. Oggi le farei sicuramente diverse, utilizzando molto di più le trasparenze!

Demolizione e ricostruzione?  
Scherzo!

A proposito dei rallentamenti, state facendo prove con/senza D3D9 & 11? (...e qui riciccia l'idea del thread "hardware parco macchine": chi è tra di noi che ha un pc potente D3D11?)

Io per i lanci uso D3D9, ma in alcuni casi di incompatibilità devo passare al motore grafico di base.. comunque si in genere lo uso per la maggior parte del tempo.
D3D11 sinceramente non lo uso, troppi ancora i problemi (anche se le ombre locali sono bellissime)

Io il D3D9 non son mai riuscito a farlo girare.

Io il D3D9 lo uso praticamente sempre senza problemi (a parte i bug noti tipo quello di Antares con i pannelli neri). Il D3D11 non proprio mai provato ad installarlo.