Jump to content

Sviluppi SW per grafica 3D per simulatore timoneria TOTI


Recommended Posts

Ciao, comandanti!

 

Come deciso insieme al buon @vytek , ho creato una discussione specifica per i possibili nuovi sviluppi SW per il nostro simulatore di timoneria TOTI 1:1.

Ne abbiamo appena parlato in questa discussione:

 

mentre gli aspetti generali della costruzione del simulatore di timoneria sono descritti qui:

 

 

Visto il grande lavoro che sta facendo Vytek, stiamo ipotizzando di aggiungere questa grafica 3D a corredo del simulatore, mostrando il movimento del TOTI dall'esterno in un secondo schermo (o eventualmente, perché no, anche la vista dal periscopio...).

Certamente aggiungerebbe molte funzionalità all'uso del simulatore, non solo perché il movimento del battello sarebbe più fruibile, ma anche perché si potrebbe creare un vero ambiente marino 3D in cui muoversi, con conseguenti interazioni con il fondale, con la costa, con altri oggetti 3D in navigazione vicino al battello.

In questa sede potremo discutere le modalità con cui portare avanti tutto questo lavoro, pensando ai moduli SW già esistenti, da entrambe le parti, e definendo le logiche con cui questi moduli dovranno parlarsi fra loro e che informazioni si dovranno scambiare.  

Speriamo di farcela, certo sarà una bella sfida. 

 

Prima di iniziare a parlare di sviluppi, però, penso che sia indispensabile riassumere l'architettura e le funzionalità del simulatore TOTI nella sua forma attuale. Ecco quindi uno schema riassuntivo dei vari moduli, esistenti, in fase di ultimazione e possibili nuovi futuri.

Architettura-HW-SW-0.png

 

In questo post e in quelli immediatamente successivi vi descriverò un po' questi blocchi.

Come vedete, c'è un modulo principale, denominato "Flight Model" nella terminologia dei simulatori di volo, che simula il comportamento fisico del battello, restituendo i suoi parametri di velocità, rotta, quota ed angolo di bolla partendo dalle condizioni pregresse, modificate dagli input dati con i comandi.

Questi input, per ora tutti del tipo on/off, sono raccolti dal modulo di gestione delle schede I/O, le quali ricevono i segnali dati dai comandi fisici (leve, interruttori, manopole). Al contempo, le schede I/O mandano in uscita dei segnali di output che, attraverso le stesse schede I/O, vanno ad accendere le gemme luminose disposte in diversi punti del simulatore, con vari significati sulla funzionalità del battello (apertura prese a mare, sfoghi d'aria, innalzamento periscopio, etc.).

Infine, vanno gestiti tutti gli output analogici, relativi alle informazioni sul moto del battello, quali quota, giri elica, angolo di bolla, ma anche informazioni ausiliarie quali gli angoli dei timoni orizzontali e verticali. Per tutto ciò sono stati esattamente riprodotti gli strumenti analogici del battello reale, ciascuno con una cornice fisica esterna attraverso la quale si vede una porzione dello schermo di un TV 55" 4K. Sullo schermo del TV vengono mostrati i quadranti degli strumenti, definiti con una bitmap con risoluzione 4K, sopra alla quale vengono mosse delle lancette analogiche vettoriali, il cui angolo viene opportunamente calcolato.

 

Questa è la configurazione di base della parte I/O, che ora descriverò nel dettaglio. Al contrario, rimandiamo la descrizione del Flight Model ai prossimi post.

 

Come avevte visto nello schema, la Scheda I/O n°1 è quella che gestisce i comandi fondamentali.

Essi sono costituiti dalle due leve e dai due pedali del timoniere orizzontale, e dalla leva singola del timoniere verticale. 

In aggiunta, ci sono due pulsanti per modificare i giri elica e quindi la velocità, nonché un singolo comando per allagare le casse di zavorra (se si lavora in modalità semplificata). La posizione delle leve della timoneria viene letta da una serie di sensori ottici a sbarramento, mentre gli altri comandi sono interruttori diretti. 

 Gli output sono invece costituiti da contatti optoisolati che alimentano le varie spie a 12V a LED, per le varie funzioni. 

Tutti questi input ed ouput confluiscono nella relativa scheda, che dispone di 24 ingressi e 16 uscite digitali, più 4 ingressi analogici finora non usati.

La scheda I/O n°1, con le funzionalità sopra descritte, è funzionante nel corpo centrale del simulatore.

Qui sotto la vedete da sola e montata nel relativo vano (nella seconda foto mancano ancora i cablaggi verso le leve e gli interruttori)

Post_210607_D.jpg

 

Post-210902.jpg

A breve riprenderò parlandovi della seconda scheda di I/O, relativa alle gemme dell'albero di Natale, ovvero QCAS (Quadretto Controllo Aperture a Scafo)
Ciao!

 

Link to comment
Share on other sites

Sì, effettivamente non faccio parte della band of brothers, della banda di fratelli che navigavano insieme su questi battelli.

Se poi aggiungo che ero ufficiale di complemento nel Genio Guastatori, ho detto tutto! :blink:

 

Invece, ti dico che molti anni fa mi sono avvicinato a Betasom in quanto modellista di sommergibili radiocomandati.

Poi da cosa nasce cosa, e grazie anche alla mia passione per l'ingegneria meccanica mi sono appassionato sempre più alla tecnica dei battelli.

Certo, progettarne uno in scala non è la stessa cosa che usarne uno reale, ma i principi e la fisica con cui funzionano sono gli stessi. E' questo che mi appassiona.

Quindi, puoi capire quanto per me sia stato sfidante realizzare un simulatore che fosse realistico per chi i battelli veri li conosce bene, come voi Totiani e Dandoliani.

A giudicare dai commenti del Dir @Totiano , il comportamento del simulatore finora risulta piuttosto realistico.

Ora vedremo come sarà la parte di assetto e casse, che spero di mettere a punto per bene anche grazie al vostro prezioso aiuto.

___________

 

Bene, ora posso passare ad introdurre il prossimo tema, legato alla seconda scheda I/O del simulatore.

Questa scheda gestisce i controlli posti sulla sinistra della timoneria principale, ovvero sulla paratia prodiera della camera di manovra.

Qui si trova il QCAS, ovvero il Quadretto di Controllo Aperture a Scafo, comunemente denominato Albero di Natale, che contiene 30+30 gemme rosse/verdi, che indicano lo stato delle aperture a scafo, siano esse prese a mare o sfoghi d'aria delle casse di zavorra, portelli, passaggi a scafo per l'uscita delle antenne o cappelli esterni dei tubi lanciasiluri. 

Molte di queste aperture sono comandabili, attraverso valvole o interruttori gestiti dalle Scheda I/O n°2 e n°3, e quindi il loro stato va monitorato da questo pannello. Oltretutto, molte di questa aperture condizionano l'assetto del battello: le casse si allagano o si esauriscono attraverso queste aperture, ma anche l'allagamento dei tubi lanciasiluri o l'esaurimento dello schnorckel porteranno a leggeri cambiamenti di assetto che il "Flight Model" dovrà simulare.

 

A tempo debito andrò più nel dettaglio, per ora vi basti sapere che tutta la parte di HW relativa a luci ed interruttori fisici è già completa, ed in effetti è stata anche già mostrata in occasione dell'evento in Calzoni di quanche mese fa. Anche la scheda I/O n°2 è installata e quasi completamente collegata, ma il SW non è ancora configurato per leggerla. Quindi, per ora il simulatore lavora in modalità basica e tutta la sezione di sinistra, comprensiva dell'Albero di Natale, è utilizzata solo per motivi scenici.

 

Ecco una foto della scheda I/O n°2 cablata in sede:

Post-220731-B.jpg
 

Qui invece c'è l'interno del QCAS, con i cablaggi delle gemme rosse e verdi:

Post-220731-C.jpg
 

Infine, ecco lo schema elettrico di tutti i componenti controllati dalla scheda I/O n°2

Post_220816_A.png
 

Lo so, finora è ancora solo HW, ma fra un po' arriveremo anche al SW...

 

Link to comment
Share on other sites

Scusate l'apprezzamento poco elegante: "Sti cazzi!!!"

Complimenti @Ocean's One!

Oltre che passione una bella dimostrazione di competenza e conoscenze.

Ho visto su you tube i tre filmati "didattica smg Toti", li hai visti? sicuramente ne trarrai qualche spunto, sono presenti anche altri filmati sempre a firma @Totiano

Buon lavoro!!!!!

Link to comment
Share on other sites

Ciao a tutti! Complimenti a @Ocean's One che ha fatto un lavoro favoloso! Dunque credo sia necessario iniziare a pensare all'interfacciamento in linea generale. Come prevediamo di poter far parlare i diversi moduli e soprattutto che dati passeranno? In generale  si usano solitamente tutti gli schemi del mondo UML (https://it.wikipedia.org/wiki/Unified_Modeling_Language), molti utili soprattutto i Diagrammi di Sequenza che dettagliano cosa viene inviato e ricevuto e le relative elaborazioni fatte. Io uso molto:

https://sequencediagram.org/

https://yuml.me/diagram/scruffy/class/draw

 

Il modulo "Flight Model" è un modulo logico oppure proprio un PC/Portatile con Unity che elabora il tutto? E come comunica con il resto? Immagino tramite appositi moduli arduino? Sistemi come: https://github.com/marcteys/Uduino ??

 

Un saluto e fateci sapere.

Vytek

Link to comment
Share on other sites

@vytek,

 

innanzitutto, benvenuto in questa discussione e grazie per tutti i contributi che ci stai dando.

 

Veniamo subito al dunque dell’architettura SW, che per ora è molto semplice.

Tutti moduli risiedono sullo stesso PC e si parlano fra loro attraverso variabili condivise a livello globale.

Il modulo “Flight Model”, come del resto tutti gli altri indicati in verde nel mio schema iniziale, è quindi soltanto un modulo logico all’interno del SW monolitico, per cui non servono particolari modalità di comunicazione dei dati.

 

Per ora, un centinaio di variabili globali condivise fra i vari moduli risulta sufficiente per gestire il tutto e, ad ulteriore semplificazione, molte variabili sono per giunta booleane, perché legate agli I/O digitali.

Per esempio, sono booleani tutti i valori delle uscite che determinano lo stato di una spia di segnalazione (accesa/spenta) ma lo sono anche i valori degli ingressi delle leve della timoneria, anche se questo ti può sembrare strano.

In effetti, le leve del Toti non erano come la cloche di un aereo, che determina una diversa rotazione dei timoni a seconda di quanto viene azionata; al contrario, le leve della timoneria aprivano le valvole del circuito oleodinamico e determinavano una rotazione dei timoni proporzionale al tempo in cui venivano mantenute attive (e non al loro angolo di rotazione, che era limitato e comunque mai parzializzato, ovvero con un tipico funzionamento on/off).

Oltretutto, ciò non garantiva il ritorno automatico dei timoni al centro al termine della manovra, ma al contrario doveva pensarci il timoniere dando il comando in direzione opposta.

Sorpreso, vero?

Questo era quanto si faceva in questi battelli degli anni ’70, con automazione pari a zero.

Poi, già con i successivi sottomarini classe Sauro, la timoneria assunse una forma simile al volantino dei velivoli, ovvero con un effetto proporzionale all’angolo di azionamento.

 

Concludendo, sul nostro simulatore del Toti abbiamo una serie di I/O digitali che corrispondono a variabili booleane all’interno del programma, condivise da tutti i moduli.

Qui non ti posso spiegare nel dettaglio come il SW comunichi con le schede I/O, ma al contrario vorrei citare tutte le variabili coinvolte nel processo di gestione degli I/O.

Riferendoci al mio schema iniziale, si tratta delle variabili scambiate in corrispondenza delle frecce rosse qui indicate:

 

Post-230210.png

 

 

Ora, anche senza addentrarci in troppi dettagli, ti fornisco una descrizione di massima delle variabili scambiate.

Ecco la scheda I/O n°1, che contiene le letture di tutte le leve e i pedali della timoneria (ci sono sia segnali NC che NO, per ridondanza); ci sono inoltre i comandi per incrementare/decrementare i giri elica e per l’allagamento simultaneo delle casse di zavorra, nella modalità di gioco semplificata.

Infine, destinati al menu principale, ci sono i comandi di start/stop gioco (“ChangeMachineState”) e le uscite per le spie per gioco in funzione e per allarme.

 

Post-230210-A.png

 

 

La scheda n°2 è in buona parte destinata agli output per le spie dell’ “Albero di Natale” o QCAS, Quadretto Controllo Aperture a Scafo, con 30 spie rosse/verdi per gli stati di tutte le valvole, le prese a mare, il periscopio, le altre antenne ed i portelli dei tubi lanciasiluri.

Per la parte input, ci sono invece le letture degli interruttori fisici (impulsivi o mantenuti) per l’azionamento di periscopio, schnorckel, antenne, prese d’aria Diesel, accensione Diesel, raffreddamento Diesel e macchine indietro.

Ci sono poi i comandi dei siluri: allagamento tubi, apertura portelli esterni e lancio siluro (ancora da capire bene cosa fargli fare). Chiudo con la sirena di fischia immersione, con il lancio di inganni sonori “pillenwerfen”, e con l’accensione dell’ecoscandaglio.

Per inciso, proprio l’ecoscandaglio richiederebbe al tuo modulo di ambiente marino 3D di ricevere come input una variabile con la profondità del fondale, in modo da generare una tacca di riferimento a video, sul manometro di profondità.

 

n.b. lo stato di tutto questo è: HW finito, scheda I/O ancora da configurare e SW di gestione ancora da scrivere.

 

Post-230210-B.png

 

 

Passo infine alla scheda di I/O n°3, quella per la gestione puntuale di tutti i comandi delle casse di immersione.

Qui la scheda non è ancora cablata e sto lavorando sul “ferro”, come vedi sul thread del Toti 1:1 dove il buon @S513 e il Dir @Totiano mi stanno dando una mano a definire uno per uno tutti questi comandi.

Ad ogni modo, in linea di massima le variabili saranno queste:

 

Post-230210-C.png

 

 

Devo terminare qui, anche se non ho ancora parlato del Flight Model e dei suoi algoritmi.

Lo farò la prossima volta.

Ancora un paio di considerazioni soltanto.

 

Come hai visto, il nostro SW è abbastanza monolitico e risiede su un unico PC.

Sarà quindi necessario definire tutte le variabili da scambiare all’interfaccia con la parte gialla, che riguarderà gli sviluppi per i quali potrai darci una mano. Sarà bene prevedere tutta questa nuova parte sotto un socket per lo scambio di dati con la parte già esistente (e nella fattispecie direi con il solo “Flight Model”, che potrebbe buttare fuori dati come rotta, velocità, quota, inclinazione, etc…).

Poi decideremo se mettere questo SW su un altro PC oppure sullo stesso a seconda della velocità di calcolo che ne risulterà.

 

Infine, grazie per le indicazioni per i diagrammi di sequenza.

Devo però dirti che io sono piuttosto vecchio stampo, per cui ho fatto molti passi a mente o sulla carta, un po’ come quando programmavo i videogiochi per il Commodore 64, più di trent’anni fa. :blink:

Poco professionale, ma tant’è…

Edited by Ocean's One
Link to comment
Share on other sites

 

19 hours ago, Ocean's One said:

Per inciso, proprio l’ecoscandaglio richiederebbe al tuo modulo di ambiente marino 3D di ricevere come input una variabile con la profondità del fondale, in modo da generare una tacca di riferimento a video, sul manometro di profondità.

 

Si è un problema che sto cercando di risolvere in generale anche se non contemplato nella simulazione. Sto pensando di utilizzare un semplice sistema  che calcola distanza dal sottomarino al terrain tipo: https://forum.unity.com/threads/solved-finding-the-distance-of-an-object-relative-to-a-plane.483413/

 

In realtà in giro non esiste nulla di già pronto e per ora non so bene come fare. In linea generale credo si tratti del classico problema distanza perpendicolare di un punto da un piano e molto probabilmente dovremmo usare le primitive che già mette a disposizione Unity.

 

19 hours ago, Ocean's One said:

 

Devo terminare qui, anche se non ho ancora parlato del Flight Model e dei suoi algoritmi.

Lo farò la prossima volta.

Ancora un paio di considerazioni soltanto.

 

Come hai visto, il nostro SW è abbastanza monolitico e risiede su un unico PC.

Sarà quindi necessario definire tutte le variabili da scambiare all’interfaccia con la parte gialla, che riguarderà gli sviluppi per i quali potrai darci una mano. Sarà bene prevedere tutta questa nuova parte sotto un socket per lo scambio di dati con la parte già esistente (e nella fattispecie direi con il solo “Flight Model”, che potrebbe buttare fuori dati come rotta, velocità, quota, inclinazione, etc…).

Poi decideremo se mettere questo SW su un altro PC oppure sullo stesso a seconda della velocità di calcolo che ne risulterà.

 

Infine, grazie per le indicazioni per i diagrammi di sequenza.

Devo però dirti che io sono piuttosto vecchio stampo, per cui ho fatto molti passi a mente o sulla carta, un po’ come quando programmavo i videogiochi per il Commodore 64, più di trent’anni fa. :blink:

Poco professionale, ma tant’è…

 

Non credere si continua ancora così, quando inizio un progetto i miei appunti sono pieni di frecce e pseudocodice, così troviamo un "linguaggio comune" 😉

 

L'unica criticità che vedo è integrare il tutto nel software monolitico che citi. Tecnicamente sempre di Unity si tratta ma non è facile integrarlo in un'unica scena. E come le gestiamo due camere con due scene diverse? Si può fare ma è veramente complesso, ed è un "debito tecnologico" che pagheremo più tardi. (L'ho fatto solo una volta per un spara tutto ma solo appunto per prova).  Si l'idea è magari avere due processi distinti che si parlano. 

Se dobbiamo usare un socket allora usiamolo REST che è semplicissimo:

 

https://github.com/stenosis/RESTful-Unity

 

Un saluto e attendo nuova parte di spiegazioni...

Link to comment
Share on other sites

@vytek ,

 

molto bene, sembra che stiamo procedendo nel modo migliore.

Anch'io sono perfettamente conscio della difficoltà di integrare tutto nel software monolitico, come dici tu.

Quindi, molto semplicemente, non lo faremo! :thumbsup:

 

Al contrario, lavoreremo su due programmi separati che, anche se sempre Unity, non dovranno affatto integrarsi in un'unica scena. La mia parte già scritta potrà gestire tutto il comportamento del battello, ma si limiterà ad un ambiente grafico 2D su cui visualizzare i quadranti degli strumenti.

Il tuo nuovo sviluppo, invece, gestirà in autonomia tutta la grafica 3D, comprensiva di ambiente marino.

I due SW si parleranno solo dove serve, ovvero si scambieranno le poche informazioni che serviranno per dire al tuo modello 3D cosa sta facendo il baricentro del battello (quota, velocità, rotta e inclinazione), e viceversa restituire al mio SW semplici info codificate sui pochi eventi critici (contatto con il fondale,  capocciata con una petroliera :biggrin:, spinta delle onde, etc...)

Ergo, il tuo SW potrebbe starsene benissimo sotto un altro PC. Sono due processi distinti che si parleranno, su questo sono assolutamente d'accordo.

_____________

 

Torno ora alla spiegazione della parte di SW già realizzata, sperando che finora risulti tutto abbastanza chiaro, anche se in effetti quanto detto fino a questo punto riguarda unicamente lo sviluppo attuale e non avrà ricadute sul SW futuro.
Infatti, tutti i dati di input di cui sopra vengono poi trasferiti al Flight Model che li elabora, generando quelle poche variabili sintetiche del movimento, come quota, rotta e velocità, che come ho appena detto verranno trasferite al tuo SW con grafica 3D dell'ambiente marino in cui il battello si muove.

 

Passo quindi a descriverti il Flight Model, riportando anche alcuni passi del programma, per mostrarti come lavora.

Questo modulo gira a 100 Hz, una frequenza certamente idonea a simulare il movimento di un oggetto relativamente lento come un sottomarino. Quindi, ogni centesimo di secondo questo modulo SW esegue una sequenza di operazioni, che ora passo a descrivere nel dettaglio.

n.b. Come potrai vedere, si tratta di classici calcoli derivanti dalla fisica, senza ausili di sorta per il calcolo automatico. Sono riuscito a modellare il sottomarino con pochi elementi su cui posso fare direttamente i calcoli; non mi servono quindi raffinate modalità di simulazione, magari FEA, che invece servirebbero per esempio per calcolare il comportamento di un’ala di aeroplano nell’intorno delle condizioni di stallo.

 

Ecco le azioni principali svolte dal Flight Model:

1) Dalle variabili di input calcola lo stato di timoni, motore e casse

2) Dopodiché, dallo stato delle casse e dalle eventuali falle calcola la spinta idrostatica e il peso per le diverse sezioni di scafo

3) Dallo stato dei suddetti timoni, motore, pesi e spinte indrostatiche, il Flight Model calcola le variazioni e quindi i valori aggiornati di quota, rotta, velocità ed angolo di bolla (ovvero pitch, inclinazione longitudinale)

4) Infine, il SW applica opportune correzioni ai valori di quota e bolla in caso di interazioni con la superficie del mare, se parte dello scafo emerge fuori dall'acqua e perde spinta.

Infine, il modulo di grafica 2D aggiorna la posizione delle lancette degli strumenti da proiettare sul TV.
A questo punto, il ciclo sarebbe finito e verrebbe reiterato.

 
n.b.
Nella versione evoluta, invece, dopo le elaborazioni di cui sopra il Flight Model potrebbe trasferire quota, rotta, velocità e inclinazione al tuo SW, che ne calcolerebbe la posizione orizzontale del battello nel tuo ambiente nautico e genererebbe il modello 3D che naviga.
Inoltre, eventuali interazioni con il fondale o con le onde possono essere trasferite indietro dal tuo nuovo modulo al Flight Model, per le azioni del caso (collisione, etc...) ed essere applicate ai miei parametri prima dell'inizio del nuovo ciclo del Flight Model 
______________

 

Passo allora a mostrarti un po' di listato.
Ecco un esempio dal blocco 1)

 

        if ((uiInputs & Contr.uiITOAVBassoC) != 0)
            fAngTOAV -= fTOAVAngRatio * fTimePassed;
        if ((uiInputs & Contr.uiITOAVAltoC) != 0)
            fAngTOAV += fTOAVAngRatio * fTimePassed;

        if ((uiInputs & Contr.uiITOADBassoC) != 0)
            fAngTOAD -= fTOADAngRatio * fTimePassed;
        if ((uiInputs & Contr.uiITOADAltoC) != 0)
            fAngTOAD += fTOADAngRatio * fTimePassed;

 

In questo caso, l'azionamento a salire della leva dei timoni orizzontali Avanti (TOAV) ne fa crescere l'angolo per tutto il tempo che il comando viene mantenuto.
Naturalmente, in altri passi viene poi imposto un limite alla rotazione dei timoni (+/-20°).
Lo stesso approccio si ha per giri elica, timoni orizzontali addietro (TOAD) e timoni verticali.
______________

 

La gestione delle casse di zavorra è più complessa, anche perché le casse sono ben otto, con diversa funzione.
Ecco un estratto dal blocco 2), che non pretende di essere esauriente:

 

        if ((uiInputs & Contr.uiIComandoSvuotaCE) != 0)
        {
            fNormAriaCE += 40 * fTimePassed;
            fNormAria12 += 40 * fTimePassed;
            fNormAria34 += 40 * fTimePassed;
        }
        else
        {
            fNormAriaCE -= 150 * fTimePassed;
            fNormAria12 -= 150 * fTimePassed;
            fNormAria34 -= 150 * fTimePassed;
        }

        if (fNormAriaCE > 300.0f)
            fNormAriaCE = 300.0f;
        if (fNormAria12 > 300.0f)
            fNormAria12 = 300.0f;
        if (fNormAria34 > 300.0f)
            fNormAria34 = 300.0f;

        fAriaCE = fNormAriaCE / ((fQuota / 10.0f) + 1.0f);
        fAria12 = fNormAria12 / ((fQuota / 10.0f) + 1.0f);
        fAria34 = fNormAria34 / ((fQuota / 10.0f) + 1.0f);

        if (fAriaCE > 100.0f)
        {
            fAriaCE = 100.0f;
            fNormAriaCE = 100.0f * ((fQuota / 10.0f) + 1.0f);
        }
        if (fAria12 > 100.0f)
        {
            fAria12 = 100.0f;
            fNormAria12 = 100.0f * ((fQuota / 10.0f) + 1.0f);
        }
        if (fAria34 > 100.0f)
        {
            fAria34 = 100.0f;
            fNormAria34 = 100.0f * ((fQuota / 10.0f) + 1.0f);
        }

 

Qui c'è un bel po' di sana fisica "calcolata", che ti ho mostrato solo in parte.
In pratica, all'azionamento dei comandi io impongo l'immissione di un quantitativo di aria noto e definito in condizioni "normali" (ovvero volume riferito ad 1 bar di pressione assoluta).
Quest'aria immessa prenderà il posto dell'acqua contenuta nella cassa, espellendola, ma solo con riferimento al volume di aria alla pressione corrispondente alla quota a cui si trova il battello.
Ovvero: se butto dentro la cassa la stessa quantità di aria ma mi trovo a quota più profonda, riuscirò ad espellere meno acqua.
Qui sono indicate le casse 1-2, 3-4 e la cassa espulsione C.E., ma in effetti ce ne sono anche delle altre, a riproduzione del battello reale.
______________

 

Nel blocco 3) vado invece a valutare gli effetti delle grandezze di cui sopra sul moto del battello.
In questo listato vedi come varia l'angolo di bolla (pitch), come effetto degli angoli dei timoni orizzontali (TOAV e TOAD), e quindi come varia la quota in funzione di tali parametri e della velocità del battello. (p.s. l'altezza metacentrica definisce invece la capacità autoraddrizzante del sottomarino.)

 

        fPitch += (fAngTOAV * fTOAVPitchRatio * fAutoritaTOAVPitch + fAngTOAD * fTOADPitchRatio * fAutoritaTOADPitch) * fRPM * (fRPM / 120.0f) * fTimePassed;
        fPitch -= Mathf.Sin(fPitch * 3.141592654f / 180.0f) * fGM * fAltezzaMetacentricaGM * fTimePassed;
        fQuota -= Mathf.Tan(fPitch * 3.141592654f / 180.0f) * fScalaVel * (fRPM / 250.0f) * fTimePassed;   // fScalaVel * (fRPM / 250.0f) era fScalaVel
        fQuota -= (fAngTOAV * fTOAVQuotaRatio * fAutoritaTOAVClimb) * fRPM * fTimePassed;

 

A ciò dobbiamo poi aggiungere la salita o la discesa per effetto dell'assetto non neutro, se peso e spinta idrostatica non si equivalgono e quindi il battello è "leggero" oppure "pesante".

 

        fDeltaQuota = 20.0f * Mathf.Sin(fPitch * 3.141592654f / 180.0f);

        fCasseAV = fCassa12 - fCassaAssetto;
        fCasseC = fCassaCE + fCassaCD;
        fCasseAD = fCassa12 + fCassaAssetto;

 

        fPesoNomC = 1000000.0f * (1.0f - (fRisSpinta * (1.0f - fCasseC / 100.0f)));
        fPesoNomAV = 2000000.0f * (1.0f - (fRisSpinta * (1.0f - fCasseAV / 100.0f)));
        fPesoNomAD = 2000000.0f * (1.0f - (fRisSpinta * (1.0f - fCasseAD / 100.0f)));

        fPesoTotC = fPesoNomC + fFallaC;
        fPesoTotAV = fPesoNomAV + fFallaAV;
        fPesoTotAD = fPesoNomAD + fFallaAD;

 

        fForzaC = fSpintaC + fResIdrC - fPesoTotC;
        fForzaAV = fSpintaAV + fResIdrAV - fPesoTotAV;
        fForzaAD = fSpintaAD + fResIdrAD - fPesoTotAD;

 

        fVVertC += fForzaC * fTimePassed / 100000.0f;
        fVVertAV += fForzaAV * fTimePassed / 200000.0f;
        fVVertAD += fForzaAD * fTimePassed / 200000.0f;
        fVVert = (fVVertC + fVVertAV + fVVertAD) / 3.0f;

 

        fQuota -= fVVert * fTimePassed;
        fTemp = (180.0f / 3.141592654f) * fTimePassed * (fVVertAV - fVVertAD) / 40.0f;
        fPitch += fTemp;

______________

 

Infine, e questo è veramente l'ultimo esempio, ecco cosa succede in caso di interazione con la superficie del mare, ossia il punto 4 di cui sopra)

 

        if (fQuota > 8.6f)
            fSpintaC = 1000000.0f;
        else
            fSpintaC = 1000000.0f * fQuota / 8.6f;

        if ((fQuota - fDeltaQuota) > 4.5f)
            fSpintaAV = 2000000.0f;
        else
            fSpintaAV = 2000000.0f * (fQuota - fDeltaQuota) / 4.5f;

        if ((fQuota + fDeltaQuota) > 4.5f)
            fSpintaAD = 2000000.0f;
        else
            fSpintaAD = 2000000.0f * (fQuota + fDeltaQuota) / 4.5f;

 

In pratica, se la quota della sezione centrale con la torretta è minore di 8,6 m, oppure se la quota delle sezioni di prua o poppa è minore di 4,5 m, significa che parte dello scafo è fuori dall'acqua.
Il sistema quindi ricalcola la spinta effettiva delle diverse sezioni e la impone nelle equazioni di cui sopra, modificando di conseguenza il comportamento del battello.

 

Esempio più calzante: la "delfinata" che si ottiene arrivando in velocità in superficie, con angolo di bolla molto positivo.
Immagino che tu abbia già un'idea di questa spettacolare manovra ma, nel caso, chiedi e sono certo che una foto del "TOTI DELFINANTE" non tarderà ad arrivare... 

 :smiley22:

 


E con questo è veramente tutto.
Spero di averti dato un'idea di come lavora questo Flight Model.
Ciao!
 

Edited by Ocean's One
Link to comment
Share on other sites

Ho letto tutto e comincio a capire come funziona il sistema.

 

Come ti dicevo io mi immagino di lavorare usando come hai detto tu con un "socket" più precisamente un micro-servizio che potrà esporre un micro server REST tramite: https://github.com/stenosis/RESTful-Unity

 

I client possibili sono molti e dipendono un po' dal tipo di architettura che si vuole scegliere:

 

https://github.com/dilmerv/UnityRestClient

oppure: https://github.com/proyecto26/RestClient

 

(per il momento la scelta la mettiamo da parte ma dobbiamo ragionarci sopra essendo Unity mono-Thread e quindi dovendo noi gestire o tramite apposite co-routine oppure tutto in maniera asincrona così da non creare problemi al Thread principale di elaborazione ed avere un calo di velocità di renderizzazione da parte di Unity).

 

Concettualmente:

 

 

Untitled.png.8bacd4291762a389f3dac0923e0ad7f3.png

 

 

Vedi: https://sequencediagram.org/index.html#initialData=C4S2BsFMAIBUHlYEloGUQFsCu4CGwB7AJwCgSAxcEAcwAthoBZAgEx0gFoA+dbPQok1bsAXNADOkYKiwZcREADtIAEUgAHYLWgAKAEoBRVLDEAFAKqwAlNCJSsRRdABuucFhgAzcAXzQl0BhSkKS8OPjEQmxQ3GH8kczRkGKowPIMGKwgngCe0GqatCRxEYKJ7BzclDT0UaLQ1FIyAEZyCsoFWgD0ADyuPnb+TkHAClwABfpGJtAA4gbWFFR0DOUxXNUrdVBiAMZuu+HAMMoA7hLH6kA

 

La prima chiamata dovrebbe essere da quello che mi hai delineato ovvero invia profondità desiderata (set) e ricevi (get) attuale profondità:

 

getSubmarineDepth/<valore in metri> (REST: GET)

setSubmarineDepth (REST: PUT) return value float in meter

 

Me ne vengono in mente cento altre 100 ma dobbiamo a mio parere iniziare a scendere nel dettaglio.

 

Un saluto e fatemi sapere che ne pensate...

 

P.S. suggerisco una sessione su Zoom, Skype o Meet per vederci/sentirci ed iniziare ad entrare nel discorso...

Edited by vytek
Link to comment
Share on other sites

On 11/2/2023 at 14:31, vytek said:

Si è un problema che sto cercando di risolvere in generale anche se non contemplato nella simulazione. Sto pensando di utilizzare un semplice sistema  che calcola distanza dal sottomarino al terrain tipo: https://forum.unity.com/threads/solved-finding-the-distance-of-an-object-relative-to-a-plane.483413/

 

In realtà in giro non esiste nulla di già pronto e per ora non so bene come fare. In linea generale credo si tratti del classico problema distanza perpendicolare di un punto da un piano e molto probabilmente dovremmo usare le primitive che già mette a disposizione Unity.

 

Intervengo solo per dire un'ovvietà che sicuramente avrai già considerato...

Ma convertire le coordinate nello spazio dell'heightmap (se simuli, una copia in memoria di sistema alla fine ti conviene tenerla), samplare 4 valori e andare di interpolazione bilineare?

Link to comment
Share on other sites

On 14/2/2023 at 21:31, CubanFoxtrot said:

 

Intervengo solo per dire un'ovvietà che sicuramente avrai già considerato...

Ma convertire le coordinate nello spazio dell'heightmap (se simuli, una copia in memoria di sistema alla fine ti conviene tenerla), samplare 4 valori e andare di interpolazione bilineare?

 

Unity già è in grado di fare questa approssimazione. No il mio problema è molto più semplice, ho un piano di riferimento a quota 0 che per me è il livello del mare. Devo calcolare la distanza da zero alla profondità in un punto oppure la stessa distanza sottomarino punto perpendicolare sul fondo marino. Credo di dover lavorare di normali e vettori o qualcosa del genere ma usando ovviamente le primitive di Unity. Ogni consiglio è ben accetto.

Link to comment
Share on other sites

On 14/2/2023 at 21:39, CubanFoxtrot said:

Confesso anche qui la mia sostanziale ignoranza in materia, ma API stile REST non sono pensate per cose un filo meno "realtime"? TCP...

 

Ovviamente l'unica reazione possibile all'ultimo (e non solo) post di Ocean's: :smiley22:

 

Ni, nel senso che dipende. Dovessi fare la parte di Networking hai ragione userei UDP e per il comandi TCP al massimo RUDP. Ma in questo contesto lo sto usando come IPC (https://en.wikipedia.org/wiki/Inter-process_communication) sulla stessa macchina in localhost. E' un approccio che molti daeomni usano localmente per parlare appunto con altri processi (Redis, MySQL, etc...). Certo qualcosina si perde, ma è tutto locale è quindi latenza minima, velocità di comunicazione massima. Perdiamo veramente molto poco, ma guadagnamo in semplicità di sviluppo. Ci sarebbero altri metodi più performanti in Windows, ma poi rischiamo appunto di non essere cross-platform.

Link to comment
Share on other sites

13 hours ago, vytek said:

 

Unity già è in grado di fare questa approssimazione. No il mio problema è molto più semplice, ho un piano di riferimento a quota 0 che per me è il livello del mare. Devo calcolare la distanza da zero alla profondità in un punto oppure la stessa distanza sottomarino punto perpendicolare sul fondo marino. Credo di dover lavorare di normali e vettori o qualcosa del genere ma usando ovviamente le primitive di Unity. Ogni consiglio è ben accetto.

 

Per avere la profondità da quota 0, non ti basta prendere la coordinata Y della transform dell'entità in questione?

 

Per la depth under keep, io ti riconsiglio di samplare l'heightmap.

O comunque di avere una rappresentazione 100% in memoria di sistema (una zuppa di triangoli dell'area attorno al sub? vale la pena?).

Non sai mai poi con quale tecnica finisci per renderizzare le geometrie del fondale marino (o addirittura se tutte le entità simulate avranno contemporaneamente una geometria 3d sotto, vedi scenari di vaste dimensioni).

Magari un'implementazione tutta in GPU ti finisce pure per creare problemi nell'ottenere risposte a query del genere.

Just my 2 cents.

 

Poi dipenderà anche dal fatto se vuoi considerare la curvatura della terra, immagino?

 

Ciao ed in bocca al lupo. 😉

Edited by CubanFoxtrot
Link to comment
Share on other sites

@CubanFoxtrot, @vytek

 

Ma quanto siete attivi!

Mi sto rendendo sempre più conto della “potenza” che potete manifestare in questo sviluppo.

 

Per la distanza dalla chiglia, ad ogni modo, una soluzione molto semplice ve la posso proporre io, perché la mia parte di SW già calcola la quota proprio con riferimento alla chiglia.

Pertanto, ciò che effettivamente mi serve è solo il valore puntuale della profondità (coordinata Y come dice @CubanFoxtrot), calcolata riferendoci al centro della chiglia del battello.

Se tu @vytek mi trasferisci quel valore di profondità del fondale (riferito alla superficie del mare), poi io potrò calcolare per differenza quanta acqua c’è sotto al battello, visto che di quest’ultimo conosco la quota istantanea.

 

Poi, è vero che il battello non è un punto e occorrerebbe una funzione che ne calcoli la profondità della sezione più immersa, ma non vorrei scomodare le complesse funzioni che tu @vytek certamente conosci. Vorrei invece sfruttare, con approssimazione accettabile, il modello “lumped” con cui già gira l’attuale Flight Model.

Mi spiego meglio con questo schema:

 

Post-230216-A.png

 

Vedete, ho schematizzato il battello con tre soli punti, riferiti alla chiglia del battello, che impongo sempre allineati e distanti 20 m l’uno dall’altro, in coerenza con le dimensioni del Toti, che è lungo circa 46 m.

 

Al punto centrale C riferisco il valore della variabile fQuota, mentre l’inclinazione della congiungente dei tre punti mi definisce l’inclinazione, o “pitch” con termine aeronautico.

La variable fPitch è espressa in gradi ed è positiva con lo scafo inclinato a salire.

 

Con un po’ di trigonometria possiamo quindi calcolare la quota dei punti AV ( = AVanti ) ed AD ( = ADdietro )

Posto:

        fDeltaQuota = 20.0f * Mathf.Sin(fPitch * 3.141592654f / 180.0f);

ne risulta che:

la quota del punto AV è pari a (fQuota - fDeltaQuota);

la quota del punto AD è pari a (fQuota + fDeltaQuota);

 

Come vedete, queste due quantità sono ciò che ci interessa e vanno confrontate con la profondità del fondale, per capire se pensiamo di sbattergli contro.

(Poi, è vero, questa info non accuratissima servirà per l’ecoscandaglio, mentre immagino che per l’urto vero e proprio ci sia un registro di collisione in Unity o qualcosa del genere.)

 

Ad ogni modo, la quota delle sezioni AV ed AD è già stata usata nel Flight Model per l’interazione con la superficie del mare, per esempio per simulare la "delfinata" in emersione.

Come vedete dallo schema, ho assegnato ai tre punti AV, C e AD tre diversi valori di peso (corretti poi dallo stato delle casse e da eventuali falle), che sono compensati da tre valori di spinta idrostatica, per la sola altezza immersa dei loro volumi di riferimento. Vedete in figura i volumi di riferimento, alti rispettivamente 4,5m , 8,6m ed ancora 4,5m, colorati in rosso per la parte immersa ed in arancione per la parte fuori dall’acqua.

La spinta idrostatica di ciascun volume verrà quindi ridotta in proporzione a quanto il volume stesso emerge rispetto alla sua altezza totale (sono le variabili fSpintaAV, fSpintaC ed fSpintaAD). Da qui nasceranno gli effetti correttivi dell’assetto del battello, sia a livello di momento raddrizzante che riduce fPitch, sia a livello di correzione di fQuota, visto che il battello non deve certo volare fuori dall’acqua!  :biggrin:

 

        fPesoNomC = 1000000.0f * (1.0f - (fRisSpinta * (1.0f - fCasseC / 100.0f)));

        fPesoNomAV = 2000000.0f * (1.0f - (fRisSpinta * (1.0f - fCasseAV / 100.0f)));

        fPesoNomAD = 2000000.0f * (1.0f - (fRisSpinta * (1.0f - fCasseAD / 100.0f)));

 

        fPesoTotC = fPesoNomC + fFallaC;

        fPesoTotAV = fPesoNomAV + fFallaAV;

        fPesoTotAD = fPesoNomAD + fFallaAD;

        (…)

 

        fForzaC = fSpintaC + fResIdrC - fPesoTotC;

        fForzaAV = fSpintaAV + fResIdrAV - fPesoTotAV;

        fForzaAD = fSpintaAD + fResIdrAD - fPesoTotAD;

 

        fVVertC += fForzaC * fTimePassed / 100000.0f;

        fVVertAV += fForzaAV * fTimePassed / 200000.0f;

        fVVertAD += fForzaAD * fTimePassed / 200000.0f;

 

        fPitch += (180.0f / 3.141592654f) * fTimePassed * (fVVertAV - fVVertAD) / 40.0f;

 

Questo e molto altro è già presente nel modulo Flight Model.

Basta quindi che voi mi diate la profondità del mare nella posizione in cui si trovano i tre punti AV, C ed AD del battello, ed il gioco è fatto.

 

Per le coordinate dei punti AV, C ed AD sulla carta nautica, potremo pensare come segue:

 - Coordinate espresse in metri;

 - Il punto C è l’effettiva posizione del battello (x positiva in direzione Est, y positiva in direzione Nord)

 - Coordinate di AV:      xAV = xC + 20 * sin(rotta) ; yAV = yC + 20 * cos(rotta)

 - Coordinate di AD:      xAD = xC - 20 * sin(rotta) ; yAD = yC - 20 * sin(rotta)

 

Poi va deciso se le coordinate del battello sulla carta nautica vadano calcolate dall’attuale SW Flight Model oppure dal nuovo SW con ambiente 3D aggiuntivo. Questa scelta va ancora fatta, parliamone...

___________

 

Torno ora all’architettura dei moduli per parlare delle loro modalità di comunicazione.

Ho leggermente rivisto il mio precedente schema.

In pratica, per i dati scambiati vogliamo limitarci soltanto a:

- un blocco di info passate dal Flight Model al programma con l’ambiente 3D (freccia rossa)

- un blocco di info passate dal programma con l’ambiente 3D al Flight Model (freccia blu)

 

Post-230216-B.png

 

Ora, io vorrei che questi due flussi di dati fossero completamente disgiunti.

Ovvero, il programma di ambiente 3D riceverà quota, velocità, inclinazione e rotta dal Flight Model (freccia rossa), ma NON li modificherà né li restituirà modificati al Flight Model.

Dopodiché, il programma 3D elaborerà eventuali warning o info di interazione con l’ambiente (es. profondità in quel punto) che il Flight Model riceverà (freccia blu) ma NON dovrà restituire modificati in alcun modo.

 

@vytek : probabilmente questo è un po' diverso dal flusso che hai mostrato più sopra, dove setSubmarineDepth e getSubmarineDepth fanno "rimbalzare" avanti ed indietro la stessa variabile, che viene modificata da ciascuno dei due programmi.

Oppure ho capito male? Grazie per il chiarimento che mi darai.

 

In pratica, il mio desiderio è che la stessa variabile non vada avanti ed indietro ad ogni ciclo.

La mia idea è che tutte le variabili di interfaccia generate da uno dei due programmi siano disponibili in lettura per l’altro programma, e vengano lette non appena l'altro programma sarà pronto.

Piccoli ritardi non influiranno e penso proprio che a quel punto non servirà lavorare in sincrono.

 

Non dimentichiamo infatti che lavoriamo a 100 Hz e che un sottomarino è piuttosto lento rispetto alle sue dimensioni.

Quindi, il warning di collisione con l’eventuale petroliera arriverà magari 3 cicli dopo, ma questo vorrà solo dire che l’equipaggio sarà vissuto 3 centesimi di secondo più a lungo, il che non sposta i termini del problema… :doh:

Nemmeno il trasferimento delle coordinate del battello al modulo grafico impatterà più di tanto.

Pensiamo al Toti, che va a circa 5 m/s e quindi percorre la sua lunghezza in quasi 10 secondi.

Se la sua immagine a video è grande 500 pixel, ad ogni centesimo di secondo viene percorso soltanto mezzo pixel! Quindi, anche con un ritardo di sincronismo di 2-3 cicli, il movimento sullo schermo sarà sufficientemente fluido, credo.

 

 

Qui mi fermo, in attesa di vostri commenti.

Vi ripeto soltanto i miei messaggi più forti: ognuno dei due programmi deve avere compiti ben precisi ed il più possibile indipendenti dall'altro, bisogna minimizzare le variabili scambiate, evitiamo di aver bisogno di un trasferimento sincrono dei dati.

Ciao!

 

 

 

p.s. @CubanFoxtrot  La curvatura terrestre...!   :doh:

 

 

Edited by Ocean's One
Link to comment
Share on other sites

Ciao a tutti!

 

Dunque parto da quanto da te scritto:

 

Quote

 

Ora, io vorrei che questi due flussi di dati fossero completamente disgiunti.

Ovvero, il programma di ambiente 3D riceverà quota, velocità, inclinazione e rotta dal Flight Model (freccia rossa), ma NON li modificherà né li restituirà modificati al Flight Model.

Dopodiché, il programma 3D elaborerà eventuali warning o info di interazione con l’ambiente (es. profondità in quel punto) che il Flight Model riceverà (freccia blu) ma NON dovrà restituire modificati in alcun modo.

 

 

Il problema è che il "modulo" grafico 3D NON è solo un modulo di rappresentazione passiva allo stato attuale. E qualora lo fosse avremmo altre gatte da pelare ;_) Mi spiego: nella situazione attuale tutto il comportamento fisico viene calcolato dall'Assets Water Dynamics Phisics 2.0 che gestisce praticamente tutto. Per poter "pilotare" il tuo mezzo lo sviluppatore ha messo a disposizione proprietà, metodi ed eventi appositamente calibrati nell'ottica di una guida molto semplice tramite comandi Unity. Per intenderci (alla fine sempre di un oggetto stiamo parlando in ottica di programmazione OOP) immaginati una scatola nera (oscura per lo sviluppatore, ma che effettua calcoli etc..) a cui è possibile fornire:

1) Profondità: intesa come comando scendi o sali di ne metri. Sarà poi il modulo in autonomia a far scendere il mezzo di N metri calcolando inclinazione, inerzia etc.., interfacciamento delle superfici con l'acqua etc... Ovviamente hai sempre a disposizione (ma con un po' di calcoli la puoi, come avete fatto voi, derivare il tutto dalla coordinata Y) una proprietà che legge l'attuale profondità.

2) Potenza motore e propeller (elica, lo dico per me che ogni volta mi sbaglio): ovvero viene definito un intervallo minimo e massimo di RPM (si può persino impostare un ritardo o una curva per arrivare dal minino al massimo) di conseguenza puoi configurare la potenza da 0 a 100 osservando il movimento del mezzo. Sarà poi sempre il modulo ad applicare una forza di spinta (non a caso nella configurazione bisogna identificare il vettore di spinta inizio, intesità, etc...sulla mesh del sottomarino) al mezzo che tramite l'interazione delle vari parti con l'acqua simula la navigazione. Sarà sempre il modulo Dynamics a far ruotare l'elica (o le eliche...) ed a decidere in base alla potenza configurata la sua velocità di rotazione tanto che nella  configurazione iniziale vuole sapere il transform dell'elica ed il suo asse di rotazione.

3) Rudder, timoni e loro posizione: non è possibile avere una rotta precisa, per intenderci nessun metodo per impostare nella scatola nera vai a 122 Gradi, ma puoi soltanto configurare massimo e minimo angolo di rotazione del timone o dei timoni ed azionarli dando l'angolo oppure muovendoli passo passo tramite le frecce o classici tasti A e D (considerate che stiamo pensando in ottica di giocatore che vuole "pilotare" da tastiera il sottomarino a video). Come sempre navigazione, interazione con le onde (non con correnti sottomarine, questo NON viene simulato), interazione delle forze di galleggiamento, spinta etc... tutto viene calcolato dal modulo Dynamics che si interfaccia frame by frame con il sistema interno di simulazione/visualizzazione dell'ambiente marino Crest Ocean System.

 

Ripensandoci sembrano proprio i comandi base per un modellino e venendo tu da questo magnifico mondo magari puoi ipotizzare qualcosa al riguardo. 

 

Il problema è subito visibile: 1) non ho modo di ribaltare i tuoi parametri sulle interfacce prevista da Dynamics 2) Anche riuscendoci avremmo una non sincronizzazione tra i due moduli. Se il Flight Module dice al 3D Module ok vai a -100 metri, il 3D Module lo farebbe con i suoi tempi simulando l'inerzia del mezzo, interazione, magari un' inclinazione completamente diversa da quella il Flight Model simula ed invia come visualizzazione agli strumenti visualizzati a video dal modulo Grafica 2D.

 

Adesso ipotizziamo di eliminare il modulo Dynamics; avremmo un semplice GameObject, obbligatoriamente Kinematics (https://docs.unity3d.com/ScriptReference/Rigidbody-isKinematic.html) perchè tutta la fisica NON è gestita. Cadremmo a mio parere dalla padella nella proverbiale brace: abbiamo perso galleggiamento, interazione con Crest Water System e tutta la fisica. Che forze applichiamo? Potremmo applicare una spinta certo, ma il sottomarino si comporterebbe come una palla da biliardo non come un mezzo immerso o sommerso. Ci riscriviamo tutta l'interazione? Oddio possibile, ma sinceramente non saprei da dove partire e nemmeno come farlo. Una mezza idea dovrei fare un po' di "ingegneria inversa" sullo script di interfacciamento scritto dallo sviluppatore di Dynamics oppure sentire quelli di Crest Ocean System, fattibile, ma molto molto oneroso in termine di impegno/sforzo di sviluppo (effort direi nel pessimo linguaggio degli analisti software).

 

Altro problema: quando dici che lavorate a 100Hz non capisco bene come. Nel senso se usate FixedUpdate allora il loop -thread è stabile a 30 FPS quindi 30Hz se usate Update allora sarete variabili dai 60 ai 100 FPS a seconda delle prestazioni della macchina e della complessità della screna. Usate questo ? O non ho capito proprio nulla 😄?

 

In linea generale mantenendo almeno i collider del sottomarino e del fondo marino (simulato con un terrain e quindi usando un terrain collider) le collisioni dovrebbero essere salve. Sinceramente non ho mai approfondito la questione, ma ho trovato una possibile bella spiegazione qui:

 

https://www.immersivelimit.com/tutorials/closestpoint-and-contactpoint-collision-in-unity

 

Un saluto e fatemi sapere.

Vytek

 

 

 

 

Edited by vytek
Link to comment
Share on other sites

On 16/2/2023 at 11:49, CubanFoxtrot said:

 

Per avere la profondità da quota 0, non ti basta prendere la coordinata Y della transform dell'entità in questione?

 

Per la depth under keep, io ti riconsiglio di samplare l'heightmap.

O comunque di avere una rappresentazione 100% in memoria di sistema (una zuppa di triangoli dell'area attorno al sub? vale la pena?).

Non sai mai poi con quale tecnica finisci per renderizzare le geometrie del fondale marino (o addirittura se tutte le entità simulate avranno contemporaneamente una geometria 3d sotto, vedi scenari di vaste dimensioni).

Magari un'implementazione tutta in GPU ti finisce pure per creare problemi nell'ottenere risposte a query del genere.

Just my 2 cents.

 

Poi dipenderà anche dal fatto se vuoi considerare la curvatura della terra, immagino?

 

Ciao ed in bocca al lupo. 😉

 

Aspetta, aspetta sono molto indietro. Per ora riesco solo ad avere un terrain (inteso come oggetto gestito da Unity) con il relativo Terrain Collider. L'importazione è un "mappa" molto limitata di qualche chilometro quadrato. 

 

In teoria esistono servizi e piattaforme molte più precise che gestiscono dati GIS anche per motori grafici. Una delle migliori è sicuramente Cesium.

 

https://cesium.com/

 

Cesium simula tutto ed anche la curvatura terrestre. Solamente che il relativo modulo di interfacciamento non ha i dati batimetrici dei fondali marini. Ho provato ad importarli sulla piattaforma, ma con ottima probabilità la sto utilizzando male. Ho anche scritto un post al riguardo dicendomi di caricare i dati sulla piattaforma e poi utilizzarli, ma devo essere sincero non è molto chiaro come farlo. Leggete per favore:

 

https://community.cesium.com/t/underwater-sea-floor-using-unity-3d-in-underwater-warfare-simulation/22087

 

Ho caricato i dati di Gebco ma non ho capito se la piattaforma li abbia correttamente interpretati e soprattutto come poterli sfruttare tramite il loro componente per Unity (ho iniziato a studiarlo, ma sono troppi gli argomenti da studiare non ce la faccio da solo nel mio tempo libero 😞

 

chrome_2023-02-17_11-56-50.thumb.png.74f0b973e924100835ca403e60298bd3.png

 

Non mi hanno risposto e credo in generale non abbiano molto tempo per rispondermi. Sono sicuro che il sistema sia fantastico soprattutto perchè è in grado di inviare in streaming i dati al tuo client Unity in maniera intelligente (ovvero solo dandoti i dati per un raggio limitato all'attuale posizione in Lat, Long)

 

Ritorna il problema di tutti i progetti amatoriali. Se non si ha una motivazione forte anche come progetto non si va molto lontano. Non è tanto una questione economica, ma se un tizio come il sottoscritto si presenta e dice ok voglio fare questo, cercano nel limite delle disponibilità di darti una mano, ma se dietro non vedono un progetto solido, organizzato, etc... beh non è che ci perdono molto tempo. E tuttavia Cesium è  il sistema perfetto e viene attualmente utilizzato sia in ambito militare che civile da numerose simulazioni. 

 

Vi dico questo perchè a mio parere è inutile reinventare la ruota, forse è meglio utilizzare quello che già esiste.

 

L'ipotesi che tu mi proponi direi che è fattibile, ma mi sembra (ignoranza mia ci mancherebbe..) troppo complessa. Ho un terrain sotto il mio GameObject non mi resta che proiettare un vettore ogni volta che faccio la misurazione con origine la mesh del mio Toti virtuale che incide perpendicolarmente con la superficie del fondale marino (probabilmente userò il punto pivot della mesh, od il baricentro virtuale calcolato...). Ne calcolo la distanza e lo sottraggo all'attuale profondità del mio GameObject. Non so bene come fare per il momento, ma l'idea è grosso moda quella che ti ho detto. Sto sbagliando tutto?? Vi va di darmi una mano a capire come usare questo sistema?

 

In pratica per ora ho questo:

 

Unity_2023-02-17_12-08-48.thumb.png.adee299a53e965728ce25f3976b1e0ba.png

Edited by vytek
Link to comment
Share on other sites

Consigli sparsi e rapidi, sia per mancanza di tempo, ma soprattutto perchè la mia esperienza con Unity è limitatissima e nemmeno troppo felice.

 

1) Partirei con una rappresentazione totalmente locale/piatta/rettilinea/ENU, sia grafica che fisica.

Solo l'origine avrebbe un corrispettivo geografico.

Un po' come DW ma in scala più piccola (qualche decina di km?).

Altrimenti hai pure il discorso della precisione numerica dei valori in virgola mobile da affrontare, la precisione del depth buffer stesso se i clipping planes devono coprire vaste distanze, etc.

Oltre allo streaming dei dati in background...

2) Creerei una serie di oggetti terrain, setterei heightmaps, colormaps, etc. da dati reali, tutti dati precaricati, e orchestrerei questi tiles (costituenti una griglia logica) offsetandoli/cambiandone stato visibilità attorno alla posizione della camera.

3) Farei funzionare il tuo plugin di ocean rendering su questo sistema.

 

Buon weekend, 😉

 

Edited by CubanFoxtrot
Link to comment
Share on other sites

In effetti, di fronte alla vostra competenza informatica, non posso aggiungere quasi nulla.

L’unico contributo che posso dare a @CubanFoxtrot è la conferma sulle dimensioni dell’area di gioco.

Supponendo una velocità media di 11 nodi, 30x30 km sarebbero sufficienti per un paio d’ore di navigazione. Di più non penso che serva.

Anche solo 10 miglia nautiche (ovvero 18 km) sarebbe già un bel simulare.

_________

 

Ora, invece, mi vorrei dedicare alla risposta a @vytek, che sarà necessariamente molto articolata.

Infatti, purtroppo, sono convinto che l’unica soluzione compatibile con ciò che abbiamo già fatto sia non usare il modulo Dynamics, ma limitarci alla cinematica.

 

Tu @vytek dici che cadremmo dalla padella nella brace, ma io penso che questa brace non faccia poi così male e che, viceversa, sia la “padella” a porci troppi vincoli.

Vedi, rinunciare ad un modulo che simula il galleggiamento, l’inerzia e tutta la fisica è possibile, perché la fisica ce la possiamo riscrivere noi!

Quello sarà compito del sottoscritto, ed in effetti buona parte del lavoro è già stata fatta. 

Oltretutto, qui a Betasom di esperti della dinamica di navi e battelli ce ne sono (siamo tutti discepoli del grandissimo @Varo5; se vuoi fai una ricerca per renderti conto della portata dei suoi post...).

 

Mi piacerebbe farti vedere le reazioni del battello simulato sin d’ora: anche se potresti solo guardare gli strumenti, troveresti comunque una bella inerzia e dei tempi di risposta ai comandi allineati con il battello reale. 

I nostri“tester”, veri sommergibilisti, hanno approvato la cosa.

 

Immagino di sembrarti un po’ troppo ambizioso e so bene che qualche problema rimarrà, come per esempio l’interazione con le onde.

D’altra parte, usare un modulo dinamico non ottimizzato per i veri sommergibili probabilmente creerebbe problemi maggiori.

 

Ti do qualche esempio.

L’ottimo calcolo FEA del modulo Dynamics che simula il rollio è semplicemente superfluo, perché lo scafo tondo non rolla se immergo di più un lato dell’altro.

Al contrario, non sono certo che il SW simuli correttamente il momento raddrizzante dato dall’altezza metacentrica, né che si possa simulare una densità differenziata del contenuto dello scafo, né i volumi vuoti all’interno di quest’ultimo.

Però i volumi vuoti sono indispensabili, perché è molto più facile fare emergere le struttura a libera circolazione d’acqua (che si svuotano quando emergi) rispetto allo scafo stagno.

Anche sulla resistenza idrodinamica avrei qualche dubbio: magari il modulo Dynamics calcolerà anche una resistenza proporzionale al quadrato della velocità, ma lo farebbe anche In direzione verticale?

Oggi il mio sottomarino può immergersi verticalmente da fermo, grazie all’allargamento delle casse, raggiungendo una velocità limite dettata da questa resistenza verticale.

E se, in questa discesa verticale, io riempio di più la cassa assetto di prora, il maggior peso porterebbe il battello ad appruarsi, e quindi a guadagnare velocità “scivolando” in avanti nella sua discesa, anche a motore fermo.

Tutto questo si può simulare con una buona dose di equazioni, ma lo farebbe altrettanto bene il modulo Dynamics?

 

Aggiungo anche un’altra necessità, secondo me imprescindibile: i timoni di profondità devono necessariamente essere indipendenti e sdoppiati, ovvero due a prora e due a poppa. I primi regoleranno principalmente la quota, i secondi l’angolo di bolla. Un sottomarino si pilota così.

È possibile angolare tutti i timoni a salire, guadagnando quota ed anche inclinazione, oppure mettere i timoni avanti a salire e quelli dietro a scendere, per una dolce traslazione a risalire, rimanendo orizzontali e paralleli a sé stessi.

Tutto questo è indispensabile, altrimenti il simulatore di sommergibile non è realistico.

 

Chiudo con un ultimo esempio, datomi da un anziano ex-timoniere che si era cimentato con il nostro simulatore. Ha settato il battello leggermente pesante, con i timoni avanti 6 gradi a salire e quelli addietro 3 gradi a scendere. Ebbene, il sottomarino procedeva ad una quota esattamente costante, pur mantenendo un paio di gradi di bolla a scendere. Tutto ciò lo avrebbe reso prontissimo ad un’azione di disimpegno: bastava ridurre appena i timoni avanti e dare motore, e l’immersione era velocissima.

Secondo te, il modulo Dynamics potrebbe riprodurre tutto ciò? 

Io ho molti dubbi...

_________

 

Chiudo infine con i 100 Hz.

Quella è solo la frequenza con cui il sistema lancia il ciclo di aggiornamento dei parametri fisici. 

Poi, da lì alla rappresentazione grafica ce ne passa. Non mi ricordo esattamente quanto siano i fps (chiederò a @The Aviator) ma non devono necessariamente essere 100. Penso che in realtà siano di meno...

Edited by Ocean's One
Link to comment
Share on other sites

Ciao @Ocean2s One, ho letto il tutto con molto interesse. Il problema che io identifico non risiede nella qualità della simulazione fisica, ma nella sua diversità. Mi spiego: è indubbio che la qualità (intesa come vero-somiglianza) e quantità dei parametri gestiti dal "Flight Model" è ineguagliabile e direi ovvia, tuttavia converrai con me che non usa il paradigma delle funzionalità ipotizzate nell'ambiente virtuale progettato e predefinito in Unity 3D.  Questo debito (inteso in termini informatici, come appunto prezzo, scotto da "pagare" in termini di sviluppo) è veramente molto alto, forse troppo alto. Come analista ne ho probabilmente una visione parziale e forse anche errata e quindi questo mi fa drizzare le mie antenne di "analista" 😉 Io sono super sicuro, stra sicuro, che la vostra conoscenza della cinematica e dinamica dei mezzi immersi sia mille volte superiore tuttavia dovete calarla negli strumenti messi a dispozione da Unity che potrebbero esser parziali, completamente insufficienti o persino errati per le vostre esigenze. E' il superamento di questo "golfo" che mi impensierisce perchè potrebbe essere richiesto un impegno/sforzo troppo altro per i miei tempi in particolare e per il progetto in generale. La mia esperienza inoltre conosce casi di questo tipo che non hanno raggiunto il proprio obiettivo perchè ritenuti troppo complessi in termini di tempo. Si veda ad esempio l'ottimo progetto JSBSim integrato (da una grossa azienda...) in Unreal (https://www.unrealengine.com/en-US/blog/antoinette-project-tools-to-create-the-next-generation-of-flight-simulators) ma NON in Unity. JSBSim è esattamente un Flight Model all'ennesima potenza utilizzato da molti simulatori di volo tra cui anche FlightGear (https://github.com/JSBSim-Team/jsbsim). C'è stato un unico tentativo di utilizzarlo in Unity, ma i vari Team hanno gettato la spugna (da quello che so io...) perchè troppo complesso (inteso come troppo oneroso in termini di tempo e risorse) adattarlo alle caratteristiche di Unity. Questo certo non mi conforta 😉 
Eliminare il modulo Water Dynamics è ovviamente possibile ma a questo punto abbiamo ovviamente la NON facile esigenza già evidenziata nei miei post precedenti di: 1) Tradurre quanto calcolato in Fligh Model in un insieme di forze agenti sul modello tridimensionale (il cuore del problema...) utilizzando il motore fisico di Unity3D e non solo 2) Studiare, capire ed implementare l'interfaccia Crest Ocean e le sue ripercussioni sul modello 3D del Toti (inteso onde, etc, ma NON correnti marine che non vengono proprio prese in considerazione 3) Interfacciare i due moduli, per ora abbiamo una mezza idea, ma deve essere calata in esigenze più dettagliate 4) Studiare tutto la parte di collisione e comunicazione con il Flight Model. 

 

Vediamo che eventuale aiuto potrò darvi, non conosco proprio tutto nell'ambito della fisica su Unity. Invoco anche io @The Aviator anche come "mediatore culturale" per vedere se il mio punto di vista e le loro eventuali ripercussioni a livello Unity quali siano, avendo lui una visione dei "due mondi" sicuramente molto migliore della mia. Come avrete sicuramente capito il mio studio è stato molto specifico su Unity, ma sono molto curioso del come si potrà fare convivere o tradurre il tutto su Unity partendo dal Flight Model 🙂

 

In ogni caso vi anticipo il modello del TOTI che ho esportato dal sito: https://www.turbosquid.com/it/3d-models/free-enrico-toti-ssk-506-3d-model/785555 in vari formati tra cui anche FBX per Unity 3D e non solo.

Per l'utilizzo non dovrebbero esserci problemi ma vi invio la licenza per ogni problema: https://blog.turbosquid.com/turbosquid-3d-model-license/

 

Saluti ed alle prossime.

 

Edited by vytek
Fare riferimento al link turbo squid
Link to comment
Share on other sites

Ho avuto un'idea e la riporto qui anche a futura memoria. Ricorderete che vi ho parlato del modulo DIS (Distributed Interactive Simulation) reso completamente gratuito ed open source per Unity. 

Si veda: https://en.wikipedia.org/wiki/Distributed_Interactive_Simulation

 

Ebbene secondo me sarebbe perfetto per risolverci molti problemi:

 

1) E' un standard militare ben riconosciuto ed utilizzabile con molte piattaforme (Unity, Unreal, etc...)

2) Possiamo usarlo come interfaccia per passarci tutti i dati necessari tra il Fligh Model ed il 3D Graphics (Localmente ed anche tramite Internet)

3) Ha il vantaggio di essere interfacciabile anche con eventuali altri sistemi nell'ipotetico campo di battaglia virtuale interfacciando il TOTI 1:!1 con mezzi virtuali simulati da altri computer

4) Ci risolve il problema della fisica perchè è stato pensato proprio per la comunicazione tramite tracciamento ovvero dando coordinate LAT, LONG e la relativa altitudine dal Centro della Terra (perfetto anche quindi per il tracciamento sott'acqua)

5) Si, gestisce ovviamente un geoide standard e la curva della superficie terrestre tramite https://it.wikipedia.org/wiki/WGS84

 

Se come si diceva pensiamo al Flight Model che gestisce posizione geografica etc, tutti i dati, alla frequenza  che vogliamo, possono essere comunicati tramite modulo DIS al 3D Graphics module.

 

Che ne pensate? Questi risolverebbe un sacco di problemi. Questa mattina ho avuto l'illuminazione andandomi a rivedere e studiare più attentamente il modulo di cui vi invio tutti i dati con la codifica ufficiale per l'Enrico Toti:

 

https://assetstore.unity.com/packages/tools/network/grill-dis-241766

https://github.com/AF-GRILL/DISPluginForUnity

Documentazione: https://drive.google.com/drive/folders/1GzFa-WQ3FS73pqUXopmW7kD6rAU8SWr7

 

Video di presentazione:

 

Ovviamente la codifica con il relativo codice identificativo è stato già scelto ed utilizzato ed infatti risulta per l'Enrico Toti:

 

image.png.3b6b70ab2b0dd409802aa46fd2c42c3b.png

 

Fonte ufficiale:

https://www.sisostds.org/DesktopModules/Bring2mind/DMX/API/Entries/Download?Command=Core_Download&amp;EntryId=42916&amp;PortalId=0&amp;TabId=105

 

Per chi volesse approfondire consiglio:

 

https://github.com/open-dis/dis-tutorial

 

Edited by vytek
Link to comment
Share on other sites

On 18/2/2023 at 12:17, CubanFoxtrot said:

Consigli sparsi e rapidi, sia per mancanza di tempo, ma soprattutto perchè la mia esperienza con Unity è limitatissima e nemmeno troppo felice.

 

1) Partirei con una rappresentazione totalmente locale/piatta/rettilinea/ENU, sia grafica che fisica.

Solo l'origine avrebbe un corrispettivo geografico.

Un po' come DW ma in scala più piccola (qualche decina di km?).

Altrimenti hai pure il discorso della precisione numerica dei valori in virgola mobile da affrontare, la precisione del depth buffer stesso se i clipping planes devono coprire vaste distanze, etc.

Oltre allo streaming dei dati in background...

2) Creerei una serie di oggetti terrain, setterei heightmaps, colormaps, etc. da dati reali, tutti dati precaricati, e orchestrerei questi tiles (costituenti una griglia logica) offsetandoli/cambiandone stato visibilità attorno alla posizione della camera.

3) Farei funzionare il tuo plugin di ocean rendering su questo sistema.

 

Buon weekend, 😉

 

 

Metodo sicuramente valido in generale, ma vi annuncio che Cesium ha finalmente pubblicato vari tutorial sul suo utilizzo e sono fantastici:

 

https://cesium.com/learn/unity/

 

Risolvono sicuramente molti dei problemi che avevo avanzato e sarebbero perfetti da utilizzare per il nostro progetto. Rimane il problema che l'SDK di Cesium gira con le pipeline evolute come URP ed HDRP mentre il Crest Ocean System è gratuito solo per versione BIRP. Sto sinceramente pensando di passare ad URP:

 

https://assetstore.unity.com/packages/tools/particles-effects/crest-ocean-system-urp-141674

 

QUESTO SIGNIFICA POTER MUOVERSI IN OGNI PUNTO DELLA TERRA IN MNIERA GEOLOSCALIZZATA in un ambiente ricreato su dati GIS REALI! 

 

Un saluto ed alle prossime...

 

P.S. Notate l'uso di Cesium con il modulo DIS che vi ho segnalato (foto finale):

 

https://cesium.com/blog/2023/02/09/cesium-certified-developer-program-update/

 

In gambissima hanno anche pubblicato come hanno realizzato il loro sistema di interfacciamento con Unity ed il motore grafico O3DE: https://cesium.com/blog/2023/01/26/developing-for-unity/

 

 

Edited by vytek
Link to comment
Share on other sites

Un piccolo aggiornamento sulla parte grafica che aldilà di tutto ha una sua utilità indubbia. Come forse avete notato ho dovuto eliminare il file con le varie trasformazioni che avevo fatto partendo dal file originale in formato Cinema 4D. Sfortunatamente ho provato l'importazione in Unity3D e la mesh è praticamente ingestibile. I nomi e l'organizzazione è tutta sbagliata seconde le nostre esigenze e l'UVMap delle texture non stranamente. Sono quindi ripartito da zero importando in Blender e modificandolo a mano. 

 

Ho anche provato a contattare il suo autore che da quello che sono riuscito a capire è https://www.artstation.com/mabeldesign1 (Claudio Bellone di Torino) chiedendo il suo permesso alla modifica del modello 3D. Vi farò sapere cosa mi risponderà, spero che in ogni caso di avere una mano da qualche modellatore 3D in Blender perchè le mie capacità sono veramente basilari. 

blender_2023-02-28_14-21-34.thumb.png.8af01cb5966d5334f0050f6afae26510.png

Link to comment
Share on other sites

Ciao @vytek

Innanzitutto, troverai un mio pm per procedere con le attività.

 

Per il modello 3d non ti posso aiutare, ma spero che qualcun altro qui alla Base lo faccia.

Invece, sul piano puramente “emozionale”, vedere quel tuo ultimo Toti mi appaga molto! Il colore è ancora un po’ chiaro, ma certamente il battello è ben riconoscibile...

Riuscirai anche a far girare l’elica?

 

Link to comment
Share on other sites

blender_2023-02-28_20-04-16.thumb.png.1dfc8ed166e227d60728ced02421952a.pngInvoco @Totiano ed @Ocean's One, 

potete darmi una descrizione di questi vari tipologie di "periscopi" perchè sto letteralmente impazzendo. Esistono planimetrie un po' più dettagliate perchè rifare con quello che è stato modellato non è semplice. La notizia veramente ottima è che l'autore del modello originale mi ha dato la sua benedizione a trasformarlo completamente secondo le mie esigenze. L'ho assicurato che ovviamente lo citerò e lo ringrazierò, ma posso fare tutte le modifiche che voglio. Mentre scrivo ho visto la tua risposta. L'elica gira perfettamente e l'asse di rotazione (pivot) è perfetto. Sto riorganizzando tutto il modello, l'importazione ha fatto un disastro. Tra le altre cose vorrei usare vari sistemi per ottimizzare la geometria. Per le texture sono tutte da rifare. O meglio in Blender funzionano, ma non credo che sia state "portate" bene in Unity (questo un po' mi preoccupa perchè sul quel fronte sono una schiappa, ma vediamo...). Ti rispondo in privato...

blender_2023-02-28_19-39-18.png.286e4e5ead6a0dda002cddb0854567fb.png

 

Edited by vytek
Link to comment
Share on other sites

https://www.delfinidacciaio.it/caratteristiche.html

 

Ciao @vytek

eccoti questa pagina web che descrive bene le antenne del Toti.

Da prora a poppa le antenne sono quindi:

1. Periscopio

2. Radar

3. ECM / ESM

4. Snorkel

5. Telecomunicazioni 

 

Però vedo che l’ultima antenna verso poppa, quella delle Telecomunicazioni, non è estratta nel tuo modello 3d e probabilmente andrà ridisegnata da zero.

Spero che tu ce la faccia, magari con le indicazioni della pagina di cui sopra o con l’aiuto di qualche altro Comandante in lettura.

______

 

Veniamo ora alla funzionalità:

 

L’elica gira da zero a 250 rpm, con un range tipico da 100 a 180 rpm.

L’ideale sarebbe che il Flight Model ti trasmettesse gli RPM e che tu regolassi la rotazione dell’elica in base a questi.

(Ah già, può esserci anche macchine indietro: non so esattamente fino a quanti giri, ma potrei buttare lì un limite pratico di -100 rpm...)

 

Secondo punto: le antenne.

Io le gestisco tramite input/output digitali, interfacciati ai comandi e alle spie fisiche.

Per semplificare ne gestisco solo tre, visto che ho accorpato le antenne due a due, lasciando soltanto il periscopio da solo.

Ci sono quindi i seguenti tre flag (0 = ammainato, 1 = alzato)

Flag periscopio (posiz.1)

Flag snorkel+ECM (posiz.4+3)

Flag telecom+radar (posiz.5+2)

 

Il nome esatto delle variabili va ancora definito (poco male) ma questi sono i dati che il tuo SW dovrà ricevere.

Ciao!

 

(P.S. ricevuto tuo pm. Ok. Poi ti rispondo, grazie)


 

EDIT: ora che ci penso, posso anche comandare l’apertura dei portelli esterni dei quattro tubi lanciasiluri (tutti insieme).

Se ti piace l’idea, c’è anche questo!

Edited by Ocean's One
Link to comment
Share on other sites

6 minutes ago, Ocean's One said:

https://www.delfinidacciaio.it/caratteristiche.html

 

Ciao @vytek

eccoti questa pagina web che descrive bene le antenne del Toti.

Da prora a poppa le antenne sono quindi:

1. Periscopio

2. Radar

3. ECM / ESM

4. Snorkel

5. Telecomunicazioni 

 

Però vedo che l’ultima antenna verso poppa, quella delle Telecomunicazioni, non è estratta nel tuo modello 3d e probabilmente andrà ridisegnata da zero.

Spero che tu ce la faccia, magari con le indicazioni della pagina di cui sopra o con l’aiuto di qualche altro Comandante in lettura.

 

 

Ok, adesso è più chiaro!

 

No la quinta "antenna" proprio non è stata modellata, non esiste nemmeno nel modello originale 😞 e questo è un grosso problema perchè io sono un pessimo modellatore. Vedremo, cerco per ora di mettere apposto quello che so fare poi vedremo. Come prima versione è già tanto, servirà ulteriore lavoro per migliorarlo ancora. 

 

1) Finisco la riorganizzazione ei vari moduli ed oggetti e finiamo la modellazione 3D.

2) Passiamo alla texture vediamo se posso farle io o cerco di farmi aiutare da qualcuno. Provo a chiedere a dei professionisti perchè mi piacerebbe avere delle texture PBR quindi multistrato ad altra definizione. Se è un costo abbordabile magari spendo qualcosa io per migliorarlo, ma vediamo per ora vado avanti con quello che so fare

3) Riporto tutto in Unity e vedo la resa del tutto.

 

Abbiamo ancora molto lavoro 😉

Link to comment
Share on other sites

Confermo quanto detto da Ocean's per i mast (quelli che chiami periscopi) e aggiungo qualche foto dell'antenna mancante

tot31.jpgtot33.jpg

Nella prima manca lo snorkel ma si vede bene l'antenna TLC totalmente estesa e l'IFF (quella specie di clessidra), a foto dovrebbe essere stata scattata a Milazzo nel 1991. Nella seconda manca l'ESM (Malta 1990)

 

Snorkel

qui, meglio spiegate, sono tutte estese (o alzate)

 

Sulla bellissimo modello realizzato (ancora complimenti!)  mancherebbero l'antenna VLF (quella specie di pallone da rugby) e il Velox, una sorta di  sonar early warning (il parallelepipedo sull'altro lato del pallone da rugby.Invece andrebbbe tolto il cavo (è un'altra antenna) che parte dalla cima della vela e arriva sul timone, tolto a fine anni '70 assieme alla pinna posteriore  alla vela (che non hai messo) ed altri "ammenicoli"

Ma sono fesserie  

 

Link to comment
Share on other sites

@Totiano

 

@Ocean's One

Ok, ho:

1) Aggiunto la parte AntennaTLC (E' il meglio che riesco a fare)

2) Eliminata cavo d'antenna tra torretta e timone (spero di aver capito bene 😉

3) Sto controllando le texture e la relativa mappatura UV, ma molto probabilmente chiederò un aiuto al mitico 3DSkillUP (https://3dskillup.com/)

 

Vi aggiorno...

blender_2023-03-02_18-31-15.png

Link to comment
Share on other sites

49 minutes ago, Totiano said:

Anche se l'immagine non è chiarissima direi che ci possiamo ben accontentare! Grazie Vytek!

 

Scusate era in wireframe perchè mi sembrava più chiara. Ecco un'immagine più chiara (fatemi sapere):

 

image.thumb.png.b0dd6c6601808661d9cf3e4debe691e8.png

Link to comment
Share on other sites

10 hours ago, vytek said:

 

Scusate era in wireframe perchè mi sembrava più chiara. Ecco un'immagine più chiara (fatemi sapere):

 

Grazie Vytek, molto meglio!

credo di avere dimenticato idi evidenziare una cosa che forse avevate già percepito. L'antenna stilo, quell'antenna lunga a lato del mast, quando è tutta alzata raggiunge una elevazione (ruotando) di circa 90° (un po meno, in effetti), quando il mast è ammainato l'antenna è orizzontale (escludendo la curca per la flessione della stessa, ovviamente). spero ci essere stato chiaro. allego una foto molto vecchia dove si vede l'antenna ammainata. E' ancora priva di gondola (una sorta di rinforzo aggiunto ai primi anni 80 in prossimità del fulcro) e per questo forse troppo inclinata verso il basso.

img015.jpg

 

Link to comment
Share on other sites

@Totiano

Ne parlavamo proprio ieri sera con Ocean e The Aviator anche se magari perla prima versione faremo in modo che sparisca quando entra nella torretta. Vedremo 😉

@Ocean's One

Piacere mio, mi sono divertito moltissimo!

 

Ok, ho:

1) Rifatto proprio tutto l'oggetto: ora l'antenna è separata dal mast e quindi in teoria da Unity può essere ruotata, etc.

2) Ocean mi ha fatto invece notare una mancanza molto grave, il modellatore originario non ha proprio fatto le "alette" a prua (perdonatemi se non uso uan terminologia corretta...). Proprio non ci sono ed ora devo capire come aggiungerle e modellarle. Mi ci vorrà tempo perchè come vi ho detto sono un pessimo modellatore. A questo proposito avrei bisogno di un riferimento, una classi proiezione sui tre assi della prua in modo da capire dove metterle e soprattutto che forma debbano avere. Sono sicuramente una specie di ala molto corta, ma dovrò fare in modo che ruotino su di un asse comune e siano posizione. Un saluto e fatemi sapere per favore...

 

Ecco l'attuale situazione:

blender_2023-03-03_09-31-11.thumb.png.2f8961494ee0c8ba8b0cb5cab1a0aeed.pngblender_2023-03-03_09-31-18.thumb.png.49b9cd1b154af00927a15615ddd9f730.pngblender_2023-03-03_09-31-49.thumb.png.4b85b9426d4f2ac280b51f1d39fe5f05.pngblender_2023-03-03_09-34-06.png.ad655d5420f07cdea83e73a52f60f32d.png

 

Edited by vytek
Link to comment
Share on other sites

Che bella foto!!!! L'avevo scattata io con lo zoom dalla nostra camera alla palazzina dragaggio, ex caserma Sommergibili di Spezia. Per quanto riguarda "l'aletta" (paura!!!) cioè i timoni di prua posso consigliare a @vytek di fare riferimento ai disegni presenti sul sito di @Totiano Delfini d'Acciaio, saranno sicuramente esaustivi.

Link to comment
Share on other sites

Piccola mancanza: la pinnetta rotonda orizzontale degli idrofoni sul lato poppiero della vela, sotto ai due corni di scarico de motori.

Piccola critica: il periscopio mi sembra troppo lungo, le antenne avevano tutte circa la stessa altezza.

Complimenti a priori comunque!

 

Link to comment
Share on other sites

4 hours ago, S513 said:

Piccola mancanza: la pinnetta rotonda orizzontale degli idrofoni sul lato poppiero della vela, sotto ai due corni di scarico de motori.

Piccola critica: il periscopio mi sembra troppo lungo, le antenne avevano tutte circa la stessa altezza.

Complimenti a priori comunque!

 

Ciao, i tuoi disegni sono super esplicativi e molto chiari, grazie! Sto provando a fare tutte le modifiche necessarie, ma devo essere sincero non sono un modellatore 3D e sono veramente pessimo nel disegno. Sono uno sviluppatore prestato alla modellazione 3D in Blender e quindi per me non è assolutamente facile ricreare quanto si vede nei disegni e foto. Mettici pure che Blender non usa il paradigma punto e linea dei CAD, anzi direi che è proprio anti CAD 😉 La sua logica può sembrare contorta ma è tipica di chi lavora secondo strumenti più per la scultura che per il disegno questo perchè gli oggetti in 3D nei computer hanno un sistema di renderizzazione davvero particolare. In ogni caso mi ci vorrà tempo, molto tempo. Un saluto ed alle prossime...

Edited by vytek
Link to comment
Share on other sites

Ho scritto una stupidata! La foto non è stata scattata dalla caserma Sommergibili ma dalla corvetta Chimera che era in disarmo ed ormeggiata vicino a noi alla banchina ottica, dove adesso ci sono i nuovi moli per i battelli

Link to comment
Share on other sites

23 hours ago, S513 said:

Piccola mancanza: la pinnetta rotonda orizzontale degli idrofoni sul lato poppiero della vela, sotto ai due corni di scarico de motori.

Piccola critica: il periscopio mi sembra troppo lungo, le antenne avevano tutte circa la stessa altezza.

Complimenti a priori comunque!

 

Fabio: da fine anni 70 l'idrofono dietro alla vela non esiste piu e visto che hanno inserito il piastrone per il DSRV invece della tartauga l'idrofono (come l'antenna filare) non deve esserci 

Link to comment
Share on other sites

@S513

non ti preoccupare per la "paternità" della foto sopra. Sappiamo che ne hai tantissime altre, insieme ad una grande dose di aneddoti e di esperienza che, pian piano, ci trasferirai...

________

 

Invece, in merito all'altezza dei mast, forse posso dire io qualcosa di piuttosto preciso a @vytek .

Infatti, quando ho riprodotto gli schermi dei manometri di profondità, ho prestato particolare attenzione alle tacche che indicano l'immersione di periscopi e snorkel.

Ebbene, dalla chiglia (punto più basso) risulta:

Altezza periscopio = 11,8 metri

Altezza snorkel = 11,2 metri

 

Quindi lo snorkel (ovvero il 4° mast da prora) è più basso del periscopio di circa 60 cm.

In effetti, dal modello 3D postato, se le sue tacche sono da 50 cm, il periscopio è quasi giusto rispetto allo snorkel, magari solo un 20 cm troppo alto.

Invece, direi piuttosto che nel modello 3D sono radar (2° mast), ESM (3°) e TLC (5°) ad essere forse un po' bassini. Infatti, nella terza foto del post di @Totiano del 1° marzo, sembra che i mast dal 2° al 5° sono più o meno alti uguali, nella loro parte cilindrica.

So che queste finezze comporteranno ulteriore lavoro di modellazione, ma spero che aggiustare la loro altezza estesa sia una correzione facile.

________

 

Infine lasciatemi fare una domanda, sempre a @vytek.

Secondo te, Enrico, sarebbe possibile fare un secondo modello 3D, identico ma con identificativo "513" anziché "506"?

Così, all'atto dell'avvio del gioco, potremmo decidere se trovarci a bordo del Toti oppure del Dandolo!

Non so come mai, ma percepisco che questa opzione sarebbe gradita ad un Comandante che sta partecipando attivamente a questa discussione... :biggrin:

O sbaglio?

Link to comment
Share on other sites

Perbacco sono rimasto indietro! non sapevo della rimozione degli idrofoni a poppa della vela, mi scuso con @Vytek.

Certo , la personalizzazione del numero sulla vela sarebbe bella, però a questo punto i numeri sono quattro: 505, 506, 513 e 514 per non far torto a nessuno!!

Link to comment
Share on other sites

Grazie a tutti degli auguri! Adesso sto abbastanza bene tra tosse ed astenia,  sfortunatamente ho contagiato tutti pur facendo molta attenzione. Quindi adesso sono positivi mia moglie e mi figlia 😞 Ormai sembra di essere più in un lazzaretto che altro... saluti ed alle prossime.

P.S. Non immagino in un sottomarino cosa possa fare un'epidemia 😞

Link to comment
Share on other sites

8 hours ago, vytek said:

P.S. Non immagino in un sottomarino cosa possa fare un'epidemia 😞

 

Successe (anche) sul Toti nel 92, fui il primo a cui venni l'influenza e in quella settimana di navigazione furono tutti "impestati"  All'arrivo a Taranto chiamarono i rimpiazzi per chi non era ancora guairito... 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Forum Statistics

    • Total Topics
      45.1k
    • Total Posts
      522.7k
×
×
  • Create New...