English | Mandarin | French | Spanish | Russian

• Hardware Setup
• Struttura della Directory
• Individuare gli Indirizzi IP del Server e dei Clients nella Rete Locale
• Preparativi per i Clients
• Preparativi sul Server
• Patchare in Boygroup
• I nodi blu
• Bridges, Ponti
• Avvisi, Warnings
• ClientID
• Clients in Fullscreen
• Riproduzione Video Sincronizzata
• Controllare in Remoto i Clients
• FAQ
• Perché Ctrl+B non funziona?
• Ma com'è che i bangs arrivano ai clients quando gli pare a loro?
• Quale Porta viene usata nel Boygrouping?
• Dippiù

Fino dalla vvvversione beta22 c'e la possibilità di avere un client che dipende da più servers; ci sono altre informazioni sul MultiBoygrouping, ma prima assicuratevi di comprendere bene il setup standard.

Hardware Setup

Il boygroup consiste di norma e regola di un pc server dedicato e qualsiasi numero di pc clients connessi tramite ethernet. Connessioni gigabit sono ovviamente da preferirsi, ma il boygrouping ha fatto la sua sporca figura anche con connessioni fast ethernet.

Il boygroup più semplice da immaginare consiste di un solo server e di un solo client. In questo setup si può usare anche l'output fullscreen del server come parte della proiezione, anche se questa scelta potrebbe non rivelarsi la migliore nel caso in cui calcolare le patches richieda molte risorse: spesso il server gira ad un framerate inferiore rispetto ai clients, visto che ha un po' più di lavoro da fare.

Struttura della Directory

Generalmente è buona pratica generare una struttura come la seguente quando si lavora ad un progetto in vvvv:

In un setup boygroup è specificamente indicato condividere la directory \MIOPROGETTO in rete e generare la stessa struttura per tutti i clients. Tenete presente comunque che i clients non avranno bisogno dei files .v4p nella directory \patches, dato che riceveranno i nodi dal server. In generale sarà comunque buona pratica copiare i files .fx o .dll in questa directory sui clients, nel caso in cui esistano anche nel server; anche nel caso in cui i files .v4p vengano salvati sul client non ci sono problemi, tanto non verranno usati.

Tramite boygrouping non trasferiamo alcuna risorsa (textures, filmati, files effetto...), ma solo dati (valori, stringhe, colori, enumeratori), di cui vvvv si occupa automaticamente; di conseguenza tutte le risorse a cui accede la patch sul server devono essere presenti anche nei clients. La sincronizzazione della struttura della directory può essere facilmente gestita utilizzando altri tools come RemoterSA o file modules di kalle.

Individuare gli Indirizzi IP del Server e dei Clients nella Rete Locale

Eseguire questa procedura su ciascun pc.

• Start > Esegui > cmd

oppure

• Windows+R > cmd

quindi digitare il comando

 ipconfig

Preparativi per i Clients

La parte del patching che riguarda il client è abbastanza semplice: non è affatto necessario patchare sui clients. Tutto quello che si deve fare è eseguire vvvv.exe con la riga di comando client [ServerIP]

 vvvv.exe /client 192.168.0.100

ammesso che 192.168.0.100 sia l'indirizzo ip del server. Noterete come vvvv sia in modalità client perché si aprirà una patch default con il titolo //CLIENT of 192.168.0.100.

Preparativi sul Server

Sul server eseguire vvvv con la riga di comando /server; notate come nella barra delle applicazioni il pulsante di vvvv mostri SERVER! per indicare la modalità in cui si trova.

Se il pc server ha più di una scheda di rete dovete specificare quale usare per le trasmissioni UDP: lo si può fare tramite il pin Broadcast IP (nascosto) del nodo Boygroup (VVVV Server).

Per dire al server con quali clients deve comunicare si deve generare un nodo Boygroup (VVVV Server). Collegare al pin Clients uno spread degli indirizzi ip di tutti i clients. Di solito l'aspetto della patch sarà simile a questo:

Notate come l'outlet del nodo Boygroup contenga uno spread di booleane che indicano se un client sia connesso o meno. Se tutto è impostato correttamente, pochi secondi (<10) dopo aver avviato vvvv sui clients, questi dovrebbero apparire come connessi.

Patchare in Boygroup

I nodi blu

In un'istanza di vvvv eseguita in modalità server la combo Ctrl+B consente di applicare il boygrouping a singoli nodi. I nodi in boygrouping sono colorati di blu, il che indica come siano duplicati nei clients (anche quando non siano visibili) e come ora siano calcolati lì.

Normalmente si comincerebbe col mettere in boygroup un renderer. Notate come vvvv automaticamente applichi il boygrouping anche ad alcuni nodi vicini: questo accade perché nodi come transform, textures, audio, video, layers..., devono essere connessi sullo stesso lato della rete. Questo succede in automatico, e difficilmente sarà necessario pensarci ulteriormente.

Ciò che richiede invece maggiore attenzione è capire quali nodi, oltre a quelli in boygrouping automatico, debbano essere impostati manualmente per il boygrouping per ottenere il risultato migliore: non esiste una regola generale tipo "metti in boygroup più che puoi" o "meno nodi in boygrouping ci sono meglio è".

Bisogna comunque tenere presente che tutti i dati che viaggiano sulla connessione tra nodi blu, boygroup, e nodi grigi, "normali", vengono trasferiti sulla rete ogni frame (solo se cambiano, ovviamente): dovreste quindi occuparvi che queste connessioni non trasportino spreadcounts troppo elevati e piuttosto mettere in boygroup i nodi che generano gli spreadcounts.

Diamo uno sguardo a 3 differenti scenari in cui viene utilizzato il boygrouping e che potreste affrontare mentre patchate:

• Il nodo che invia (grigio) esiste solo nel server mentre il nodo che riceve (blu) è nel client. Non appena cambiano, tutti i valori vengono trasmessi via UDP per ogni frame. Dato che UDP non può garantire né una velocità né una latenza fissa dei dati, si noterà un piccolo ritardo o una certa ruvidezza nell'animazione. Nel caso in cui quindi si trasmettano dati per l'animazione dal server al client è buona pratica mettere in boygroup il nodo Damper (Animation) come primo nodo sul client.

• Entrambi i nodi esistono nel client. In questo caso nessun dato viene trasmesso. I nodi nel client sono connessi localmente ed i dati vengono trasferiti internamente. L'animazione sarà quindi fluida come al solito.

• Il nodo che invia è in boygroup (blu) mentre il nodo che riceve no (grigio). Qui nessun dato viene trasmesso. Sul server vedrete sempre i valori calcolati localmente. Non è possibile recuperare alcun dato dai clients.

Capire quali nodi debbano essere messi in boygroup necessità un po' di pratica, ma in generale non è possibile fare errore marchiani. Se il risultato è inadeguato, provate a mettere in boygroup nodi differenti o aggiungete un nodo Damper (Animation)blu.

Bridges, Ponti

I Bridges, Ponti, sono connessioni tra nodi grigi e blu, links che trasmettono dati attraverso la rete.

Il nodo BoyGroup (VVVV Server) ha due output che ci danno informazioni sui Bridges:

• Bridge Count, Numero dei Ponti
• Active Bridges, Ponti Attivi

I Bridges Attivi sono quelli che trasmettono dati esattamente in questo frame.

Mostrare i bridges è utile soprattutto per il debug: aiuta a capire grossomodo quante connessioni stiano trasmettendo dati; di norma vorrete che il loro numero non sia molto alto.

Avvisi, Warnings

Se il pin Warning del nodo BoyGroup (VVVV Server) emette qualcosa come

 msg too big for UDP; was sent via TCP: /4/14/139/ Scale XYZ

significa che:

 /4/14/139

è il percorso verso il pin

 Scale XYZ

dato negli id dei nodi da punto di vista della ROOT.

Così si può identificare il punto della patch in cui questo messaggio troppo grande deve essere inviato tramite TCP e controllare quindi se sia davvero necessario oppure provare a migliorare la patch.

Notate inoltre che si può aumentare la dimensione dei pacchetti UDP attraverso il nodo Boygroup (VVVV Server), anche se questo richiede particolare attenzione, dato che, stando alle esperienza di alcuni utenti, maggiore è la dimensione del pacchetto UDP, maggiore è la possibilità che questo si perda (il che non è necessariamente un problema, a seconda del tipo di patch...)

ClientID

A questo punto tutti i clients dovrebbero realmente fare tutto completamente in sincronia, cosa che non è di grande utilità. Pensate a Justin, Lance, JC, Joey e Chris che ballano tutti esattamente nello stesso punto del palco: sebbene questo possa essere un'interessante alterazione della realtà, non è possibile nel nostro mondo a 3 dimensioni. Per questa ragione il boygrouping presenta una funzione chiamata "ClientID", che è l'unico modo per poter distinguere tra i vari clients (ed il server, appunto) dal punto di vista di una patch.

Il nodo Boygroup (VVVV Client) restituisce un ID diverso che va da 0 al Numero dei Clients, ClientCount, meno 1 per ogni client. L'ordine dipende dallo spread di indirizzi ip che è stato inserito nel nodo Boygroup (VVVV Server). Lo IP nella slice 0 sarà ClientID 0, lo IP nella slice 1 sarà ClientID 1, e così via. Notate che sul server il nodo Boygroup (VVVV Client) restituisce qualsiasi valore si imposti nel pin ServerID e che qualsiasi valore venga scelto per il ServerID, questo non influenzerà i clients. Cambiando il ServerID si potrà però simulare qualsiasi client sul server.

Per un semplice esempio aprite la patch

 girlpower\takethat.v4p. 

Noterete il nodo Boygroup (VVVV Client) in azione. Nell'esempio viene usato per impostare la camera ad un offset differente per ciascun client.

Clients in Fullscreen

Capiterà molto spesso che vogliate patchare sul server mentre i clients sono in fullscreen: vorrete quindi che i pins Fullscreen dei Renderers siano impostati su 1 nei clients, ma su 0 nel server. Tenendo presente come l'unico modo per distinguere il server dai clients, e per distinguere tra i clients stessi, sia il ClientID, si può patchare qualcosa come mostrato nell'immagine qui sotto per avere un renderer in Windowed Mode sul server e Fullscreen su tutti i clients.

Riproduzione Video Sincronizzata

Vedere: video synchronization

Controllare in Remoto i Clients

Quando si ha a che fare con un gran numero di clients è spesso utile eseguire\terminare vvvv.exe o altri processi con un solo clic dal server; si potrebbe anche volere Riavviare\Spegnere\WakeOnLan singoli clients o stabilire una connessione VNC verso uno di loro a scopo debug: tutto questo ed altro ancora può essere fatto con questo tool: RemoterSA.

In alternativa alcune di queste funzioni possono essere patchate usando il nodo RSh (Network), Remote Shell. Vedere inoltre RSH HowTo.

FAQ

Perché Ctrl+B non funziona?

Questo comando funziona solo in modalità server. Eseguite vvvv con la flag /server per abilitare il boygrouping.

Ma com'è che i bangs arrivano ai clients quando gli pare a loro?

Eh già. Possibile. La soluzione è tuttavia semplice: invece che avere un bang tra un nodo blu ed uno grigio fate sì d'avere solo un valore che cambia che viene trasmesso attraverso la rete. Il primo nodo potrebbe essere quindi un Change (Animation) per convertire il cambio di valore in un bang.

Il perché di tutto ciò? Presto detto: servers e clients non sono sincronizzati dal punto di vista dei frames. Ci sono ottime probabilità che i clients girino più velocemente del server, che di norma ha sempre un po' di overhead, e non c'è acido acetilsalicilico che tenga in questo caso. Sebbene il bang di sicuro venga inviato dal server, può arrivare ai clients tra due frame, e quindi andare perso. Un bang è essenzialmente una variazione a 1 seguita da una variazione a 0 nel frame successivo: se entrambi i messaggi arrivano al client nello stesso frame, solo l'ultimo dei messaggi viene preso in considerazione, con il risultato che il bang si perde ed il colpo di scena va a farsi friggere.

Quale Porta viene usata nel Boygrouping?

Per default vvvv stabilisce una connessione TCP sulla porta 3333 verso ciascun client per trasmettere tutte le variazioni del grafico. Tutte le variazioni di valore sono trasmesse sulla porta UDP 3333. Si può cambiare la porta di default nel pin Network Port del nodo Boygroup (VVVV Server). Si deve notare come in questo caso si debba avviare vvvv nei clients con un comando come questo:

 /client 192.168.0.100:4444

Dippiù

Vedere change-log-vvvv33beta15