jstrecker's picture

Jaymie (@jstrecker)


  • Vuo Founder
  • Team Vuo
jstrecker's picture
Jaymie commented on alexmitchellmus's Feature Request, “Publish up-to-date backend on GitHub

Starting with Vuo 2.0, we'll be publishing the full source code for each Vuo CE release — including the editor source and without the 1-year delay — at https://github.com/vuo

Because of the issues I mentioned above, in between releases the Vuo team will continue to develop in a private repository. However, we'll be in a much better position to accept pull requests since our private repo will be more in line with the public one.

jstrecker's picture

The reason this workaround kinda sorta works is that the Render Layers to Windows/Image nodes disable depth-culling, so they always draw all of each object (rather than skipping drawing pixels that are behind another object).

The workaround only works well when both objects are 50% transparent. It doesn't solve the problem that Vuo doesn't know how to paint objects in the desired order, but it masks the problem because at 50% transparency the order in which objects are painted doesn't matter.

jstrecker's picture

To answer your original question, if you're open to other coloring besides flat/unlit, another option would be to use lighting to fade in objects as they move closer. Add a light to the scene and limit its range to cover only the closer objects.

jstrecker's picture

In your most recent composition, the problem is that the Make RGB Color node is executing too early. You're firing an event right when the composition starts, which goes down the line to create a random color, adjust its opacity, and render the colored square. That event slips in before the first event comes through Smooth with Duration. So before Smooth with Duration has a chance to set the opacity to 0, you've executed the node one time with opacity 1.

You can see this by feeding the output of Make RGB Color into Display Console Window or Record and Play Values. Look at the first line/item in the output: opacity (alpha) is 1. In subsequent lines/items, opacity goes to 0 and gradually increases from there.

When I have problems like this involving timing, I find that it usually helps to involve fewer events/triggers rather than more. You can get rid of the Fire on Start and Spin Off Event, and instead use an Allow First Event (Non-Flickering Layer Opacity Enqueue.vuo). That reduces your composition from 4 event streams down to 2. Oh, actually, you can reduce it further by replacing the Fire Periodically with an Allow Periodic Events (Non-Flickering Layer Opacity Enqueue 2.vuo). That brings you down to 1 event stream (Render Layers to Window : Requested Frame). That gets everything synchronized and it's easier to understand what's going on.

jstrecker's picture
Jaymie commented on lechbialek's Feature Request, “Apple Touch Bar support in editor

Open for voting.

@lechbialek, if you (or anyone else) have further thoughts on the aspects of the editor that the Touch Bar could control, let us know.

Your suggestion of sliders to control published input port values fits well with Apple's Human Interface Guidelines for the Touch Bar.