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.
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?
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)
But:
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?
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.
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.
