Special limitations in boygroups?

I am wondering if there are any special limitations in boygroups concerning boygrouping of spreaded EX9 objects.
I tried to display “a pool filled with balls” (similar to the demo patch “blender”) distributed on three displays. Everything works fine as long as the spreadcount of the spheres is not bigger than 52. As soon as the number gets bigger the image on the render clients suddenly starts to stutter or even freezes.
It does not seem to be a problem of network, CPU or the graphics card performance as all values are far below 100%.
Another strange thing is that I can add a new spread with objects on top of the 52 objects in the first spread without any performance problems.
To make sure that it not has to do with something special in my spread, I simply “boygrouped the Blender” and increased the number of spreads and found the same limit of 52 spheres in one spread on the renderclients.

Any Ideas about the reason for this behaviour ?


ah. yes the 52!..

mm. no. sory. no limitation. sounds very strange. does the performance also go down on the server or only on the clients? and what does Renderer (TTY) say to this?


  • performance only goes down on the client side
  • the Renderer (TTY) does not show any problems and does not say anything when increasing the spreadcount from 52 to 53
  • I already swapped machines between server and client - no changes


m…have you opened a tty on the clients. and they don’t output anything?


this is what the TTY-Renderer on the client side outputs:

00:00:18 * : swapeffect copy: only one backbuffer is created.
00:00:18 * : swapeffect copy: only one backbuffer is created.
00:00:18 - : resetting directx-device
00:00:18 * : swapeffect copy: only one backbuffer is created.
00:00:18 - : directx-device has been reset
00:00:18 - : resizing dx window to top: 0; left: 0; bottom: 300; right: 400
00:00:18 : WINDOWED backbuffer: 1 x 1, -format: X8R8G8B8, -count: 1, multisample: 0, multisamplequality: 0, swap: copy, window: D00AE, autodepthstencil: -1, depthstencilformat: D16; flags: 0, refresh rate: 0 hz, sync: default

The renderer does not show any new messages when increasing the number of objects from 52 to 53 or more.


ok. guess i’ll try such a setup here.
should it happen with even one client only?

comes time. i try.

Yes - one client is enough !

Perhaps you can contact me if you try the setup.
… ich könnte kurz vorbeikommen !?



i have blender boygrouped here now without problems. spherecounts above 53 don’t behave differntly.

make sure you are using Boygroup (Server) and Boygroup (Client)
(ServerSetup, ClientSetup are depricated and should no longer work anyway)

on the Boygroup (Server) node you could try switching between TCP and UDP connection (which should not make any difference) and if you boygroup the Boygroup (Client) and set the LogMode to Full you should also see nothing unusual in the Renderer (TTY). among all the flush messages you should see the the correct spherecount being transmitted.

… the new boygoup nodes Boygroup (Server) and Boygroup (Client) … that was the right hint !

I still used the old ones … has the existance of the new ones been mentioned somewhere ?
(By the way - the vvvv33beta8 demo patch “TakeThat” also still uses the old ones)

switching between UDP and TCP mode makes THE difference !
In UDP-mode I still have this magical 52-limitation, in TCP-mode higher numbers of objects work without a problem.



glad we got it.
obviously we didn’t mention the new boygroup nodes in an appropriate way. do we allready have a HowToBoygroup? i will remove the old nodes since they are useless anyway…

but still strange.
udp and tcp mode shouldn’t really make a difference. did you have a look at the messages that arrive on the clients? can you see in udp mode that the spherecount arrives correctly?

Hi Joreg,

thanks for your great support !

No, I was not able to check the correct spherecount on the TTY-renderer as I was not able to isolate the “spherecountinformation” from all the othe information displayed in Log Mode Full !? And the number of values in one “block” do not seem to match the number of objects.

But anyway - I am not sure if I used the TTY-renderer correct:
I placed the GDI renderer in the server patch and boygrouped it - it only showed information on the server side
I have set Log to TTY on Boygroup (VVVV Server) to Full - many information displayed
Changing Log to TTY on Boygroup (VVVV Client) did not change or add anything in the GDI Renderer !?



the output should be in a TTY on the clients.
create a Boygroup (VVVV Client) (on the server) boygroup it and set its logmode to “full”. also boygroup a tty. now there should be many messages. but if you transmit nothing else but the change of the spherecount you should be able to distinguish this message from the others.

UUPS - mixed up GDI and TTY !

Now I am receiving (to) many values on client side.

Still not able to see the sphere count ( sehe den Wald vor lauter Bäumen nicht)


you could stop logging after having changed the spherecount and then scroll up a little on the client. there is only this one message that should look different. and the question is if it shows the same count that you sent or a random number.

just for testing don’t send any other values to the clients (like lfos…)

sorry - I can´t find any number in the TTY Renderer that seems to show the “sphere count value”.

In the attached Textfile you find some parts of typical contents of the TTY renderer on client side for different combinations of UDP/TCP/spherecounts.
As they look significantly different this might help you to find the reason for the magical 52-limitation:


hallo. this is the boygrouping spezi speaking.
unfortunately you hit a missing issue in the udp implementation by now.
large spreads are going to be broken, depending on yout network configuration (keyword is mtu size). as tcp is not packet-oriented but stream-oriented this makes the difference. sorry for that. we try to fix this next week. sven.