Guida del programmatore di scripting visivo mesh

Passare all'articolo Panoramica di Visual Scripting

Limitazioni

• Solo un subset di funzionalità di Unity viene esposto agli script visivi.
• Le variabili e le proprietà con tipi non semplici (inclusi i riferimenti agli oggetti) non vengono condivise automaticamente. Per altre informazioni su questo argomento, vedere Condivisione e rete .

Hello World

Lo script visivo più semplice che è possibile creare è uno che apre semplicemente una finestra di messaggio:

Questo è l'aspetto in Mesh:

Test degli script

Prima di caricare la scena in Mesh, è possibile sviluppare e testare gli script visivi, anche con più client in modalità schermata divisa, usando la modalità di emulazione mesh.

Diagnostica dello script visivo nell'editor

Quando un Oggetto GameObject con un computer script è selezionato nella gerarchia di trasformazione, Mesh visualizza il pannello Diagnostica scripting visivo mesh nella parte inferiore del pannello Controllo:

Il pannello di diagnostica fornisce commenti immediati su eventuali avvisi o errori che potrebbero impedire il corretto funzionamento degli script in Mesh.

Limitazione corrente: Le versioni future del pannello di diagnostica possono anche fornire informazioni dettagliate sull'uso dello script visivo di variabili e proprietà condivise e visualizzare ulteriori avvisi e diagnostica.

Caricamento in Mesh

Usare il caricamento mesh per caricare scene contenenti script visivi. Per aprire il caricatore, nel menu Mesh Toolkit selezionare Ambienti.

Nota: Il caricamento mesh convalida gli script visivi prima del caricamento e rifiuta di caricare quando si verificano errori di convalida in qualsiasi script visivo. La diagnostica dettagliata viene restituita alla console.

Condivisione e rete

Stato script condiviso e locale

Mesh usa lo scripting di Visual Script di Unity, progettato per funzionare senza rete. Gli script visivi vengono eseguiti in ogni client in modo indipendente. Tuttavia, l'esperienza mesh degli utenti è condivisa; tutti gli utenti riscontrano una singola scena condivisa che ha lo stesso aspetto su tutti i client.

L'effetto dell'esecuzione di uno script visivo è il modo in cui cambia lo stato della scena.

Per impostazione predefinita, Mesh replica automaticamente le modifiche della scena eseguite dagli script visivi in un client a tutti gli altri client. Oltre a tutto ciò che è condiviso in una scena, alcuni stati rimangono indipendenti su ogni client (in altre parole, locale).

Le modifiche locali hanno temporaneamente la precedenza sulle modifiche provenienti dai client. Esempio: se si mantiene l'animazione di un oggetto in locale, l'animazione locale non viene compromessa dalle modifiche provenienti da altri client.

Esiste una limitazione automatica della frequenza di aggiornamento. Un client non invia aggiornamenti aggiuntivi mentre uno è ancora in volo; è disponibile un aggiornamento inviato per giro di andata e ritorno tramite il server. Ciò equivale a circa cinque-sei aggiornamenti al secondo in situazioni pratiche. Ciò significa che un'animazione uniforme guidata da un client non sarà uniforme su altri client. La procedura consigliata consiste nell'eseguire animazioni fluide in locale, idealmente non tramite script visivi, ma tramite il normale sistema di animazione unity.

La coerenza finale dello stato condiviso è garantita (anche se gli stati dei client possono essere temporaneamente diversi).

Stato locale:

• Stato locale naturale: suoni, interfaccia utente, rendering.
• Stato locale controllato dall'utente: scene secondarie contrassegnate con il componente Ambito script locale .
• Stato locale tecnico: gli oggetti che non fanno parte della gerarchia della scena (ad esempio, materiali del renderer, asset).

Stato condiviso:

• Limitato alle variabili di script visivi e alle proprietà di GameObjects e componenti della scena che fanno parte della gerarchia della scena.
• È possibile replicare solo variabili e proprietà di tipi semplici: numeri interi, numeri a virgola mobile, booleani, stringhe, Color3/Vector24Quaternion/Matrix4x4e .Rect

Qualsiasi modifica allo stato condiviso viene inviata tramite la rete. Ciò aumenta il traffico di rete e, se usato senza attenzione, può utilizzare una larghezza di banda significativa.

Trigger di script condivisi e locali

Tutti i flussi di script visivi iniziano in risposta a un evento.

• Se l'evento ha origine in un singolo client, ad esempio l'utente fa clic su un pulsante, lo script visivo viene eseguito solo nel client.
• Se l'evento si verifica in tutti i client, lo script visivo viene eseguito su tutti i client (ad esempio, evento timer, modifica della proprietà condivisa, aggiornamento delle variabili condivise, avatar entra in trigger, corpo fisico tocca collider).

Quando si aggiunge un nodo per rilevare se è selezionato un oggetto, è importante scegliere quello corretto. Sono disponibili due opzioni : Corpo interagiscibile mesh: è selezionato localmente e il corpo interagiscibile mesh: è selezionato. Si supponga, ad esempio, di avere un pulsante che può essere fatto clic per attivare il teleportazione. Per avere il partecipante fare clic sul pulsante e trasportare solo se stessi, usare il nodo Mesh Interactable Body: è selezionato localmente .

Per avere il partecipante fare clic sul pulsante e teleportare tutti nell'esperienza, usare il nodo Mesh Interactable Body: Is Selected . In ogni caso, il testo sopra il nodo indica il comportamento previsto:

Se uno script locale imposta una variabile condivisa e un secondo script ascolta le modifiche apportate a questa variabile (usando il trigger On State Changed ; vedere di seguito), il secondo script verrà eseguito in tutti i client.

Mesh offre alcuni nodi di script speciali:

• In Intervalli attivati a intervalli regolari in modo sincrono su tutti i client.
• In State Change triggers when its inputs change (ad esempio, proprietà condivise, variabili condivise, local).
• Mostra finestra di dialogo visualizza un dialogo di messaggio con testo personalizzato che può facoltativamente fornire pulsanti come opzioni di risposta.

Mesh rende alcuni compromessi a favore della semplicità:

• Se più client tenta di modificare gli stessi dati, l'ultimo client vince (anziché usare un modello di aggiornamento dati basato su transazioni).
• Per garantire la coerenza dei dati, gli script visivi eseguiti in tutti i client non devono leggere e quindi scrivere proprietà o variabili condivise. In questo caso, attiva un errore di runtime e interrompe l'esecuzione del flusso di script.

Procedure consigliate

Gli script visivi sono significativamente più lenti rispetto al codice C# nativo. Inoltre, Mesh aumenta gli script visivi con rete e altre funzionalità di integrazione e, apparentemente, le azioni di script visivi con sovraccarico ridotto potrebbero causare il traffico di rete.

I problemi di prestazioni negli script visivi sono quasi sempre causati dagli script che eseguono aggiornamenti ad alta frequenza delle variabili o delle proprietà dei componenti condivisi per impostazione predefinita.

• Usare i componenti ambito script locale in modo liberale per assicurarsi che solo le variabili e le proprietà dei componenti che devono essere sincronizzate tra i client incorrono in sovraccarico di rete. Qualsiasi elemento animato in locale con uno script visivo non deve essere condiviso.

• Usare il trigger script On State Changed per avviare i flussi di script in risposta alla modifica delle variabili o delle proprietà del componente. Ciò funziona sia per lo stato locale che condiviso. È anche il modo consigliato per sincronizzare le animazioni locali.

• Usare il trigger di script On Interval anziché un trigger ad alta frequenza, ad esempio On Update per avviare i flussi di script in intervalli regolari e controllabili.

Cose da tenere a conoscenza:

• Se possibile, evitare di attivare script visivi ogni frame. Invece di usare On Update, usare On State Changed o On Interval.

• Se è necessario attivare uno script visivo ogni frame, eseguirlo nel minor numero possibile di oggetti.

• Non aggiornare le proprietà condivise ad alta frequenza. Si consideri invece di rendere locali le proprietà aggiornate ad alta frequenza usando il componente Ambito script locale . Tenere presente che le variabili di script visivi sono condivise anche per impostazione predefinita.

• Non usare le variabili oggetto se le variabili di flusso funzionano.

• Evitare di aggiornare le proprietà o le variabili condivise negli script visivi attivati simultaneamente in tutti i client.

• Evitare di impostare le proprietà fisiche (trasformazione e velocità) nello stesso corpo fisico su più client contemporaneamente. Ciò può verificarsi facilmente per incidente negli script visivi che rispondono ai trigger di modifica della scena condivisa.

• Non provare a risolvere i problemi di prestazioni consolidando diversi flussi di script che funzionano su singoli oggetti in un singolo flusso di script che funziona su molti oggetti. Il sovraccarico dell'avvio di un flusso di script è trascurabile e la complessità aggiunta che è necessario aggiungere per consolidare lo script può negare molto facilmente qualsiasi vantaggio di prestazioni leggermente ridotto che si potrebbe ottenere riducendo il numero di ScriptMachines.

Suggerimenti

• Le proprietà dei componenti e le variabili di script visivi con tipi semplici vengono condivise automaticamente tra i client in una sessione. Per ridurre il sovraccarico limitando la quantità di condivisione, aggiungere un componente Ambito script locale all'oggetto GameObject pertinente e quindi eseguire una delle operazioni seguenti:

  Per condividere le variabili di script visivi, ma non le proprietà del componente o le variabili di script o le proprietà del componente degli oggetti figlio:
  Nel componente Ambito script locale selezionare Condividi variabili dello script visivo in questo oggetto Game.

  

  Per mantenere tutte le variabili dello script visivo e le proprietà del componente per l'oggetto corrente e i relativi oggetti figlio locali:
  A questo scopo, è sufficiente aggiungere il componente Ambito script locale e mantenere deselezionate Condividi variabili di script visivi in questo oggetto game .

  

  È possibile visualizzare diversi esempi di come viene usato il componente Ambito script locale nel capitolo 3 dell'esercitazione mesh 101 incentrata sullo scripting visivo.

• Per eseguire un'operazione a intervalli di tempo regolari in sincronizzazione tra i client, usare il nodo trigger On Interval .

• Per eseguire un'operazione in risposta a determinate proprietà del componente o variabili dello script visivo che cambiano (ad esempio, perché questo o un altro client le stava impostando in uno script visivo), usare il trigger On State Changed

• Sono disponibili altre funzioni di Visual Scripting fornite da Mesh. Vedere le sezioni MicrosoftMesh e Microsoft>>Events>Mesh nel Finder Fuzzy.

Sicurezza

Mesh protegge gli utenti da scenari di minaccia come questi:

• Contenuto della scena compromesso, ad esempio tentativi dannosi di accedere ai dati locali sensibili.
• Canale di trasporto o client compromesso, ad esempio tentativi dannosi di leggere o scrivere dati remoti inaccessibili in altri client.

A tale scopo, Mesh esegue script visivi in una sandbox ,ad esempio JavaScript in un Web browser.

All'avvio della scena Mesh usa un elenco di elementi consentiti curato per convalidare gli script visivi per limitare l'accesso a determinati tipi di componenti unity e a un subset sicuro delle relative proprietà.

In fase di esecuzione della scena, mesh limita l'accesso a determinate parti della scena:

• Localmente: impedendo l'accesso agli elementi interni mesh e ad altri dati sensibili.
• In remoto: verificando che l'autore della scena intenda modificare questa parte della scena. Questa operazione viene eseguita analizzando in modo statico gli script visivi sul lato del ricevitore per le scritture potenziali della scena.

Esempi:

• Uno script visivo locale dannoso vuole assegnare a tutti gli avatar teste bobble. A tale scopo, tenta di analizzare l'intera scena per i GameObject che rappresentano la testa dell'avatar. Mesh filtra automaticamente i risultati dell'analisi per escludere il sistema avatar.
• Un client remoto dannoso vuole defacere la scena capovolgendo tutti gli oggetti GameObject. A tale scopo, invia un aggiornamento della proprietà che imposta la scala verticale di ogni GameObject nella scena. Tuttavia, poiché non è stato progettato alcun script visivo nel client ricevente per eseguire operazioni simili, il client locale ignora l'input remoto.

Integrazione di mesh

Limitazione corrente: Questa sezione descrive un'anteprima delle funzionalità ancora in corso.

In genere, l'integrazione con altri componenti viene spesso eseguita modificando e ascoltando le modifiche delle proprietà dei componenti. Ad esempio:

• Interazioni: osservare le proprietà "Is Hovered" e "Is Selected".

• Interazioni di fisica: osservare i corpi nel volume trigger o in contatto con il collisore.

• Avatar: leggere posizione avatar, rotazione della visualizzazione e lastra dei nomi. (Non ancora disponibile.

• Stato sessione: elencare i partecipanti e leggere le informazioni sui partecipanti. (Non ancora disponibile.

• Scripting cloud: operano in combinazione con gli script cloud in grado di leggere e scrivere variabili e proprietà dei componenti. (Non ancora disponibile.

Alcuni componenti forniscono azioni locali:

• Gestione audio
• Sequenza temporale
• Animatori
• Rendering: proprietà materiale e shader di lettura e scrittura

La fisica viene gestita appositamente perché la simulazione per qualsiasi oggetto di fisica specificato viene sempre eseguita in modo autorevole da un solo client: il proprietario. Per eseguire questa operazione, l'impostazione delle proprietà di fisica attiva un trasferimento automatico della proprietà al client che applica la modifica.

Passaggi successivi

Informazioni di riferimento sul nodo