Jarvis - versione dll

Ho incominciato ad effettuare il test e gli FPS non sembrano influenzati in nessun modo.. non poteva essere altrimenti dato che durante la simulazione non vengono aggiunte particlestream, ma solo sostituite.. con un po di lavoro potremo ottenere un bell'effetto, spero che vi piacerà  

Ho finito di implementare la mia idea per aumentare progressivamente il diametro dei getti e questo è il risultato:



praticamente le particle stream vengono sostituite ogni 5 secondi e il loro diametro (e colore) varia in base all'altezza e alla pressione. L'effetto può essere reso ancora più fluido.

In questo filmato gli FPS sono bassi non a causa del nuovo codice ma perchè sto lavorando su una macchina lenta. In realtà le prestazioni non cambiano rispetto al getto uniforme.

Ditemi se vi piace e come lo cambiereste, o se secondo voi è da cestinare del tutto  

Mi sembra molto bello!  

mi pare però che si veda lo stacco ogni 5 secondi. Forse per qualche frazione di secondo le due particle invece che scambiate andrebbero sovrapposte per evitare che si veda il buco?

potrebbe bastare un decimo di secondo di sovrapposizione probabilmente.

Ehm, aiuto..  
Io uso questo sistema in prestep:

if(simt>=contnextstep){
RefreshContrail();
contnextstep=simt+dt;}

Come lo devo modificare per ottenere la sovrapposizione che suggerisci tu?

dipende da cosa c'è dentro refresh contrail  

mi immagino che al momento ci sia scritto tipo

DelExhaustStream(....)....

poi definizione nuove particles

e poi AddParticleStream(...)... etc

se è così, allora basta mettere DelExhaustStream alla fine, come ultimo passaggio, così prima fa i calcoli e crea quella nuova e un attimo dopo averla aggiunta cancella quella vecchia.

Se invece non è così allora bisogna giocare un pochino di più dentro prestep, però proviamo una cosa per volta  

uhm... carina, ma non sono completamente persuaso: a parte lo "stacco" ogni tot secondi, mi sembra che il cambio di particlestream non sia graduale ma vada un po' a scatti, in particolare se ben ricordo intorno al minuto e 27 diventa rossa tutto d'un tratto. Inoltre la "persistenza" della scia mi sembra aumentare anziché diminuire... mi aspetterei che, oltre ad allargarsi, tenda a diventare sempre più trasparente fino a quasi scomparire (a seconda della quota a cui arriva il primo stadio), mentre qui sembra che si allunghi sempre di più.

Quanto agli FPS: se già "scatta" in una prova senza scenario, senza base e senza niente (che sono le cose che appesantiscono di brutto), ho paura. Sarebbe interessante fare un test "full optional" e poi ripeterlo con una particlestream standard e prendere nota delle differenze di fps.

fred18 ha scritto:

se è così, allora basta mettere DelExhaustStream alla fine, come ultimo passaggio, così prima  fa i calcoli e crea quella nuova e un attimo dopo averla aggiunta cancella quella vecchia.

Eh già che idiota, era così difficile?   

Andrew ha scritto:

uhm... carina, ma non sono completamente persuaso: a parte lo "stacco" ogni tot secondi, mi sembra che il cambio di particlestream non sia graduale ma vada un po' a scatti, in particolare se ben ricordo intorno al minuto e 27 diventa rossa tutto d'un tratto. Inoltre la "persistenza" della scia mi sembra aumentare anziché diminuire... mi aspetterei che, oltre ad allargarsi, tenda a diventare sempre più trasparente fino a quasi scomparire (a seconda della quota a cui arriva il primo stadio), mentre qui sembra che si allunghi sempre di più.

Quanto agli FPS: se già "scatta" in una prova senza scenario, senza base e senza niente (che sono le cose che appesantiscono di brutto), ho paura. Sarebbe interessante fare un test "full optional" e poi ripeterlo con una particlestream standard e prendere nota delle differenze di fps.

Questo è solo un test: lo scatto può essere ridotto al minimo, il cambio di colore reso più "morbido (o forse anche eliminato). E' nettamente migliorabile insomma!

La questione della particle che non si attenua con l'altezza non l'ho ancora risolta. Vorrei che partisse a 30 km circa e che si attuenui sempre di più fino a scomparire a 90 km circa, ma tende a rimanere costante e a scomparire di colpo alla quota massima. Devo giocare con i valori amax, amin lmax, lmin eccetera ma ancora non ho ben capito come funzionano.. diciamo che questo effetto è frutto di valori sparati un po a caso.  

Infine, ribadisco che gli FPS non sono influenzati in alcun modo da queste particles: la lentezza che si vede nel video è dovuta ad una macchina lenta usata insieme a FRAPS ed ad una scheda video di poco valore.. inoltre qui nemmeno usavo D3D9

Fausto ha scritto:

La questione della particle che non si attenua con l'altezza non l'ho ancora risolta. Vorrei che partisse a 30 km circa e che si attuenui sempre di più fino a scomparire a 90 km circa, ma tende a rimanere costante e a scomparire di colpo alla quota massima.

Se ti devo dire la verità, una cosa simile capitava anche a me quando provavo (in gran segreto  ) gli stessi effetti su Multistage un sacco di tempo fa... la scia diventava rossa e si allargava di colpo... non avendo mai trovato la quadra, non ho mai implementato questo effetto. Che ci sia qualche impostazione proprio nel core di Orbiter che ostacola i nostri sforzi? Magari dico una vaccata

Per l'effetto richiesto bisogna giocare coi valori di mappatura ed in particolare di mappatura atmosferica.

Lmin ed Lmax sono relativi alla mappatura del livello del motore. significa che definiscono quante particle vengono emesse in funzione di quanta "manetta" sto dando. Visto che i motori F1 sono accesi praticamente sempre al massimo o quasi secondo me si può semplicemente mettere LVL_FLAT 1, cioè sempre al massimo.

La mappatura atmosferica coi valori di Amin e Amax ci dice quante particle emettere (in realtà quante particle sono visibili e quante trasparenti, ma il concetto è lo stesso) a seconda della pressione atmosferica esterna.

le opzioni come sapete sono ATM_FLAT, cioè costanti per qualsiasi pressione, ATM_PLIN, cioè che variano linearmente con l'andamento della pressione, e ATM_PLOG, cioè che hanno andamento logaritmico.

un'opzione classica può essere mettere semplicemente ATM_PLIN, 0, 1 che significa che al livello del suolo la trasparenza delle particles è 0, quindi sono tutte visibili, mentre in assenza di atmosfera la trasparenza della particles è 1 (cioè 100%) e quindi sono tutte invisibili.

Se così non è soddisfacente allora si può provare con ATM_PLOG, 1e-4, 1. Visto che l'andamento è logaritmico e il logaritmo di 0 non esiste, allora al posto di 0 bisogna mettere un numero molto piccolo al primo valore (1e-4 ad esempio).

spero che questa spiegazione aiuti!

fred18 ha scritto:

spero che questa spiegazione aiuti!

Aiuta eccome! Ora ho alcune idee per migliorare l'effetto! 

Io proporrei, per venire incontro ai gusti grafici di ognuno, di impostare nel file scenario una voce che permetta di scegliere il tipo di particle, se uniforme o variabile in base alla pressione. Quindi non incluso nel parametro LOWRES ma proprio una stringa dedicata. Poi l'effetto di default se l'utente non seleziona volontariamente nessuno delle due possibilità lo lascerei decidere ad Andrew, mi sembra giusto

uhm francamente non so, non andrei a impostare variabili anche su questo... non ancora perlomeno! Vediamo se viene fuori un effetto credibile e fluido e se si, teniamo solo quello! Altrimenti impostiamo le due possibilità come suggerisci tu!

Sono d'accordo con Andrew: se mettiamo troppe opzioni nel file scenario poi diventa complicato. Almeno per ora, c'è ancora tanto di quel lavoro da fare per i prossimi...  

Intanto ho una breaking news... il PEG per multistadio... funziona    

A quanto ho visto nemmeno su OF c'era mai riuscito qualcuno a farlo funzionare, ho trovato una marea di errori su orbiter wiki, sui documenti di chi ci ha provato prima di me e addirittura sulla documentazione ufficiale nasa... Corretti quelli, ora va! e anche bene! Cioè... almeno così mi sembra!!

Ora devo solo "pulire" il codice perché ho piazzato variabili e test un po' ovunque, e per il buon utilizzo della dll è meglio non lasciare sporcizia in giro, ma entro sera posto il link alla dll aggiornata con autoguida a loop chiuso PEG che si attiva quindi a 35 mila metri e prosegue anche attraverso lo staging etc fino al raggiungimento dell'orbita desiderata. Tra l'altro a questo punto non c'è più quel passaggio non molto gradevole dopo lo staging in cui il secondo stadio si "impennava" per un po' di secondi in attesa della convergenza del sistema di guida! In realtà per il Jarvis-S non è una gran conquista, ma per i vettori con più di due stadi è una super news  

  

Eccolo:

LINK

novità:

- Da 35mila metri in poi parte il PEG multistadio. Mi pare che funzioni a dovere.

- Non funzionavano bene i failures negli ultimi 10 secondi. Ora qualsiasi cosa stia succedendo, se il conto si blocca negli ultimi 10 secondi si spegne tutto e il razzo non parte, quindi ora tutto a posto

- Nel caso di lancio con Antares funziona anche il tasto J, quindi ora la capsula si separa e tutto funziona normalmente come ogni payload.

Attendo il pacchetto delle particles da fausto per dichiarare il Jarvis-S finito ufficialmente!

Chiunque abbia qualche altra idea da aggiungere... è pregato di non dirmela    

Inanzitutto complimenti a Fred!
L'ho provato velocemente e mi pare che funzioni bene. Una cosa che per me è migliorata è il pitching più lieve del secondo stadio, che evidentemente nella versione precedente doveva andare a cercare un'assetto "più forzato" e dunque per alcuni secondi arrivava a pitch +70.

Il pacchetto delle particle è in fase di elaborazione magari entro sera dovrei aver concluso qualcosa!  

non ho ancora avuto modo di provare nulla  ho meno tempo libero di prima e quello che ho lo sto usando per chiudere Efesto e consegnarla a Fausto!

aspettatemiiiii

Eheh tranquillo, anche perché c'è ancora tanto lavoro e non sempre avrò il tempo che sto riuscendo a ritagliarmi in questo periodo (anzi, è questo periodo che è una rarità).

Intanto comunque inizierò a guardare avanti verso il Jarvis-L. Prima di iniziare però ho una domanda importante: nei prossimi Jarvis ci sarà per tutti l'opzione di Antares, completa di modulo di servizio, LES e quant'altro. Io non riesco a capire come funziona il LES com'è progettato ora... se si accende si porta via i fairing con dentro il modulo di servizio e il modulo di comando e poi si separa tutto dopo? come funziona? come mai è stata scelta questa strada e non quella di un les attaccato solo al modulo di comando come negli apollo, mettendo magari un fairing attorno solo al modulo di servizio per proteggere pannelli etc?

Chiedo perché penso che sia il caso avere da subito chiare quali sono tutte le opzioni

Il LES si porta via solo il modulo di comando; le ogive ora sono come sono per una questione di semplicità (perché il LES con multistage è "finto") ma teoricamente dovrebbero aprirsi o comunque essere espulse contestualmente allo sgancio del LES con la capsula

In realtà il LES al momento fa da tappo ai fairing quindi non so come facciano ad aprirsi e a far si che la torre si porti via solo il modulo di comando. L'idea per la resa con Multistage era ottima, però ora visto che c'è la possibilità di riprogettarlo non si potrebbe fare più realistico? mi immagino una cosa tipo Orion, con fairing fatti a semplici pannelli attorno al modulo di servizio e "cappuccio" con torre sul modulo di comando che si porta via solo quello in caso di emergenza.

Poi dite voi ovviamente ma potrebbe essere l'occasione di ottimizzare la cosa e aumentare molto il realismo!

Allora, inizialmente era esattamente come dici tu, preciso preciso! Pannelli laterali che venivano espulsi e cappuccio che copriva la capsula. Poi l'ho riprogettato così per poter tenere la copertura attorno alla capsula più a lungo durante il volo, anche dopo il distacco del LES, in modo da poter evitare di visualizzare la capsula (la cui mesh è pesante) e quindi evitando di caricare gli fps per assicurare stabilità alla capricciosa autoguida di Multistage.

E' stata una scelta "funzionale" consentita dal fatto che il LES era solo "eye-candy". Ora sarà senz'altro necessario tornare alla impostazione precedente: devo solo cambiare le mesh con quelle vecchie, che non ho buttato via! Quando sarà il momento provvederemo!

Oki, perfetto.

Il momento sara' molto presto :-)))

Amici,

sono sempre io...

quando si lavora bene si raccolgono facilmente i frutti: il vostro lavoro su mesh e rampe era impostato in maniera perfetta, e la mia dll creata ad hoc per essere poi modificata ha fatto il resto...

E' bastata una sola ora di lavoro e il Jarvis L è già realtà e perfettamente (credo e spero) funzionante...

buon divertimento:

JARVIS Pack

c'è anche lo scenario con entrambi i Jarvis sulle loro rampe a capo passero pronti al decollo, ho provato ed è davvero carino

grande!
Il pacchetto è cumulativo? Nel senso che comprende sia il J-L, sia il J-S?

Sisi, tutto insieme cosi si scarica uno e si prende tutto :-)

Uhm, ho provato ma mi va in crash.. il log non mi dice nulla.. non è che hai sbagliato a caricare la dll