vytek

Un caro saluto a tutti e Buona Pasqua! Sfortunatamente sono stato molto indaffarato negli ultimi tempi, ma riporto comunque qui qualche aggiornamento. Per prima cosa il file ArmorPaint aggiornato all'ultima versione: TotiS506WithTexture.arm Volevo inoltre farvi sapere che il GRILL ha rilasciato l'esempio per la libreria DIS di cui vi ho raccontato: https://github.com/AF-GRILL/DISForUnityExample Sono state inoltre annunciate le nuovi possibilità di Unity, già integrate nel sistema. riguardo appunto il Water System, Sky, etc..potete vedere qui in anteprima il tutto:

OK, adesso ci siamo:

Vi ringrazio tutti, ma non sono molto contento di quanto da me fatto. La vena artistica mi manca proprio e ci sono delle tecniche che conosco teoricamente, ma non nella pratica ahime. Devo rispondere su molti punti, iniziamo: @Totiano "il radome del sonar attivo" è dipinto di bianco nella parte superiore o mi sto completamente sbagliando? Qualora mi fossi sbagliato di che colore è? Dipinto come lo scafo? @Vo Faust hai sicuramene regione e sarebbe la scelta migliore. Infatti a questo proposito propongo di mettere tutto il materiale su un repository unico pubblico così ci possiamo lavorare tutti insieme (usare ad esempio github...). A questo proposito dall'immagine vedo che hai applicato le foto come texture al modello (fantastico..) ma volevo sapere: 1) Hai fatto già unwrap o stai usando nodi di Blender per la semplice applicazione alle diverse componenti delle texture? 2) Sono texture semplici o PBR (https://www.adobe.com/it/products/substance3d/discover/pbr.html) ? 3) La soluzione migliore sarebbe campionare le singole texture prendendole direttamente sul TOTI attraverso strumenti ad esempio come: https://tenebrislab.github.io/livenormal/ con cui è possibile fotografare la superficie che viene immediatamente convertita in texture PBR. E' necessario ovviamente uno smartphone di fascia medio-alta e qualcuno che vada al museo della scienza a Milano a fotografare le varie superfici 😉 4) L'invecchiamento, ruggine etc potrebbe essere fatto digitalmente usando appunto ArmorPaint o SubstanePainter, ma devo essere sincero ci vuole un professionista... 5) Per le texture non PBR si potrebbe usare invece: Materialize (http://www.boundingboxsoftware.com/materialize/index.php) 6) Hai provato a vedere come usare le tue texture in Unity?? Un saluto, grazie di tutto e fatemi sapere.

Un saluto a tutti! Tra un colpo di tosse ed una pasticca passo nelle corsie tra i malati in famiglia 😉 Siamo ormai convalescenti e quindi ho avuto un po' di tempo per portare a termine le textures del modello del TOTI. Per creare le texture ho usato il programma Open Source ArmorPaint (https://armorpaint.org/) Per la modellazione ho invece usato, come già detto, Blender nella sua versione 2.93.5 (https://www.blender.org/download/releases/2-93/) Condivido il tutto anche per chiedere una mano a chi voglia cimentarsi con eventuali modifiche o migliorie. TotiS506FromGLTF.blend (Questo è il file per Blender, da questo è possibile esportare nei diversi formati usati dai Motori Grafici 3D) TotiS506FromGLTFVer4.fbx (Mesh 3D in formato FBX per il caricamento su Unity) TotiS506WithTexture.arm (Progetto ArmorPaint per la creazioni delle textures e la sua eventuale modifica) TOTITexturesv4.7z (File compresso delle Textures PBR ad 1K create tramite ArmorPaint, sono state esportate per singolo oggetto della mesh 3D in formato FBX. Questo vuol dire che deve prima essere creato un Material per ogni parte dell'FBX inserendo le diverse Textures PBR secondo lo standard di Unity e poi assegnate al singolo componente visibile in Unity. Il nome del file ricalca il nome della gerarchia visibile in Unity. Per la decompressione del file: https://7-zip.org/download.html) E' al meglio delle mie possibilità e non credo di poter fare di meglio. Concettualmente so per certo che un modellatore non sarebbe contento del lavoro fatto. Il motivo è che la proiezione delle singoli parti della Mesh 3D non è stata fatta a regola d'arte. Il problema è che deve essere fatta una vera ottimizzazione delle singoli componenti ricreando correttamente la geometria tramite una tecnica che si chiama "Retopology". Tecnica che io non conosco molto bene e quindi ho ottimizzato i componenti con troppi poligoni usando un sistema automatico molto semplice come: https://www.simplygon.com/ Questo ha portato ad una mesh con meno poligoni, ma con una geometria non ottimizzata e soprattutto non facilmente "apribile" e "proiettabile" sulla texture. Abbiamo quindi un UVMap (la mappatura delle superfici della mesh da oggetto 3D a 2D sull'immagine della texture) fatta veramente male tanto che ho dovuto fare diverse prove per ottenere le vari scritte, colorazioni, etc... Ci vorrebbe la mano di un professionista con un tocco di arte 😉 Penso che per ora sia tutto. Un saluto ed alle prossime. P.S. Per rispondere ad si è possibile fare un'unica mesh 3D (la geometria) e diverse textures così da modificare la scritta 506 con il numero dei diversi modelli della classe TOTI. Bisogna ripetere quindi il lavoro fatto per N texture diverse. Il risultato per il TOTI è il seguente:

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 😞

Ciao a tutti, pur facendo molta attenzione sono risultato positivo a covid. Per ora tutto bene, un saluto ed alle prossime.

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

@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:

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

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

Grazie! Info favolose. Mi metto all'opera!

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 😉

Invoco @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...

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.

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/

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: Fonte ufficiale: https://www.sisostds.org/DesktopModules/Bring2mind/DMX/API/Entries/Download?Command=Core_Download&EntryId=42916&PortalId=0&TabId=105 Per chi volesse approfondire consiglio: https://github.com/open-dis/dis-tutorial

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.

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 😞 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:

Ciao a tutti! Dunque parto da quanto da te scritto: 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

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.

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.

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

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

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

Vi ringrazio tutti e mi scuso per la confusione. Ho mischiato fantasia con realtà, reale con il virtuale 😄 Grazie di tutto, ma per ora ho fatto veramente poco, spero di essere utile e di poter combinare qualcosa di utile tempi ed impegni permettendo. Vi lascio con una breve registrazione della Demo in tempo reale, ho aggiunto la visione sott'acqua della telecamera e sto lavorando alla propulsione, timone, immersione. etc. Ho anche importato in Unity il TOTI che vi ho fatto vedere e l'ho aggiunto agli altri modelli che ha in dotazione la demo. Ho da poco messo la FTTH a casa e posso finalmente caricare video ed immagini avendo molta più banda di prima: Per rispondere ad @Ocean's One: si credo sia meglio un luogo più adatto per l'ulteriore discussione, scegliete pure voi quale sia la sezione migliore, vi seguirò subito. Nota per tutti che mi riservo magari per il futuro: in uno delle miei primi post avevo parlato di una vera e propria piattaforma per la simulazione della propagazione in acqua profonda. Dalle mie ricerche è una delle più precise ed avanzate e, pensate, è stata utilizzata veramente in un "gioco" per allievi e studenti. Ho provato a capirci qualcosa, ma devo essere sincero supera tutte le mie conoscenze. Mi era venuta in mente una mezza idea di contattare i vari autori, ma sinceramente mi è mancato il tempo. Riporto qui i riferimento al post: Magari può essere d'interesse e con il vostro aiuto si potrebbe pensare anche di integrarlo. Un saluto e grazie ancora di tutto...