Large composition that fetches many images on startup sometimes loses contact with Vuo Editor

Status: 

Vuo version: 

Fixed in Vuo version: 

OS version: 

  • Mac OS X

Steps causing the bug to occur: 

This bug was initially reported by cwilms-loyalist on https://vuo.org/node/670:

If you delete the Render Image to Window node called "Test Image Resolution Output" from this composition and Run the composition notice that the Vuo Editor stops being able to control the VuoCompositionLoader. The Stop button is disabled, The Run button can be used to start a second VuoCompositionLoader instance and there is no feedback on any of the nodes in the Editor. I have also copied and pasted the contents of the Editor into a new composition and it does the same thing. I believe the main Render Image to Window node is at fault as it seems to only do this when the Requested Frame port is set to Enqueue events. I haven't been able to replicate this issue in other compositions.

On my computer, the "Test Image Resolution Output" node and Enqueue vs. Drop don't seem to make a difference. The following steps often make it happen:

  1. Open "Domino Type of Effect.vuo" from https://vuo.org/node/670.
  2. Open port popovers for a couple of the green nodes, e.g. Render Scene to Image: Image and Make Scaled Layer: Image.
  3. Run the composition.

After several seconds, the Vuo Editor loses contact with the composition (popovers don't show any events, Stop button disabled, etc.). Just speculating, but it seems like a race for the images to load before the composition-editor communication times out.

How did the result differ from what you expected?: 

The Vuo Editor and composition shouldn't lose contact.

Many events dropped by composition that changes the color of a 3D object

Status: 

Vuo version: 

Fixed in Vuo version: 

OS version: 

  • Mac OS X

Steps causing the bug to occur: 

  1. Run Lights test.vuo (from bsampson, https://vuo.org/node/609) or the attached simplified composition, ShaderCreationTest.vuo.
  2. Open the popover for the 'Requested Frame' port. Observe that it's dropping a lot of events (45% on my computer).

In ShaderCreationTest.vuo, if you remove the cable from Curve to Hold Value, so that Render Scene to Window is no longer getting a new shader with each frame, then it hardly drops any events.

How did the result differ from what you expected?: 

It should be possible to change the color of a 3D object within the time of one display refresh. It's surprising that it takes more like 2 display refreshes (on my computer), and therefore drops about every other frame.

Have you found a workaround?: 

Unfortunately, I can't think of any way to achieve exactly the effect that bsampson was going for in "Lights test.vuo" without dropping frames — smoothly changing the opacity of one 3D object within a scene.

In other situations, you might be able to work around the problem by using lighting to change the color of all 3D objects in a scene, or by working in 2D (layers) instead of 3D.

Compositions: 

AttachmentSize
Binary Data ShaderCreationTest.vuo3.01 KB

Error in the manual (page 14 – 4.1.2 Output ports

mnstri's picture

Status: 

Vuo version: 

OS version: 

  • Mac OS X

Steps causing the bug to occur: 

I think that there is an error on the manual on page 14. The green texts with arrows should be opposite, I think? See the picture.

EDIT: Actually no, the text on the right is correct. The text on the left should point to the image output port, not to the done port.

How did the result differ from what you expected?: 

...

Screenshots: 

Pages

Subscribe to RSS - Mac OS X