English | Mandarin | French | Spanish | Russian
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.
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.
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.
Eseguire questa procedura su ciascun pc.
oppure
quindi digitare il comando
ipconfig
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.
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.
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:
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.
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:
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.
Vantaggi:
Questo è anche un buon sistema per distribuire dati Audio-FFT a tutti i Servers\Clients.
Visitare BoyGrouping.UserTutorials per ulteriori informazioni.
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...)
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.
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.
Vedere: video synchronization
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.
Questo comando funziona solo in modalità server. Eseguite vvvv con la flag /server per abilitare il boygrouping.
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.
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
Vedere change-log-vvvv33beta15
anonymous user login
~3d ago
~3d ago
~12d ago
~22d ago
~1mth ago
~1mth ago
~2mth ago
~2mth ago
~2mth ago
~2mth ago