In
ConcentricTori_2.vuo (9.89 KB)
, I wish to animate torus thickness. How can I animate the phase of the Wave without the annoying “gap” (which strangely does not show up in a screenshot)? How do I feed the Time on the Curve and/or Wave? Requested Frame or Process Item is not currently working for me.
Are you trying to do something like this (attached), but for all tori in sync?
AnimateTorusThickness.vuo (1.62 KB)
Yes, something like that. I want it to look like the screenshot (which was taken from this comp, and does not have the black gap, is this a clue?)
Seems it should work to use Process Item as timebase for the Wave node to distribute sinewave values across the tori thicknesses, and Requested Frame as timebase for Curve (or another Wave) node to animate phase? In fact the tori do animate the tori as I expect, except I get the unwanted black gap in CompositionLoader (see attached mov), which cycles at the same rate no matter what rates I change in Wave or Curve to animate the tori.
Any idea? Do you get the same behavior with the posted comp? Makes me wonder if it’s some weird refresh rate issue with CompositionLoader or something. Also starting to wonder if there might be a memory leak here, cuz after 20 mins or so, fans are firing up and Activity Monitor for CompositionLoader is at ~140%…
Problem solved. The Hold Value node needed to be there. Thanks again, Jaymie!
Edit: though CompositionLoader is still running at 140% cpu. Sample from Activity Monitor attached.
ConcentricTori_3.vuo (10.9 KB)
Sample_of_VuoCompositionLoader.txt (1020 KB)
My next step is to make it a subcomposition and add it to my node library. When I add it to a new comp with a Render Image to Window, it makes the black gap come back. Now what am I doing wrong? (And I realize this might be considered a third question…)
jersmi.toriRings.vuo (11.2 KB)
Subcompositions doesn’t really like event flows quite yet, so there are possibilities for feedback issues related to this (related bug report: https://community.vuo.org/t/-/5207). I put a hold node on the image output outside the composition, and triggered it from the requested frame output of the rendered layers that at least seemed to make it a bit smoother. Changing the output port from the node to drop events also seems to have a bit to say for efficiency.
Further, I started from the top to see if there were an input port that would indicate a problem. The “Rings” seemed to have something to do with it, so I removed the trigger input from the “process item” port and it seemed to resolve the moving flickering. It is however a bit flickery when adding more than 20 tori for some reason. This is persistent even when outputting the objects instead of the image so not sure why it happens.
Thanks so much for these solutions, Magneson. Still wrapping my head around event flow, then add to that subcomps and their newness and here I am, I guess…
How did you test the input ports (and why would ports be a spot for potential problems)?
Attached comp and subcomp confirming Magneson’s observations. Disconnected event connected to Make Points Along Curve, with noticeable change.
Could there be an event order issue here, or workaround?
Now, instead of the “gap” cycling through all the tori from outer to inner, which btw would be reverse order in the list, it appears the second to last in the list (largest/outer ring, and sometimes third to last) torus in the list start to flicker and not show up. Trying various combinations using the Hold node, no luck so far.
To bring it back to the beginning, this is an attempt to recreate a QC comp, and I’m about halfway there, with this subcomp issue the only roadblock at present.
jersmi.toriRings.vuo (10.6 KB)
toriRings_0.vuo (2.11 KB)
It’s a learning experience for us all! :) The fat cables carries data & events, the thin ones only events. Unless the node blocks events (indicated by kind of a parentheses on the port) it will trigger all nodes further down the chain. I mess this up all the time.
I just changed the values to see if it made any difference, the “Rings” port seemed to express some wonkiness when I changed it, so I assumed it had something to do with it. This won’t necessarily show anything under all circumstances, but is nice as a first step in troubleshooting.
There is something going on on a level I don’t understand though so it may be best if @jstrecker takes a look at it if possible. There is something about the “Make Points Along Curve” node receiving events from the outside (Rings) even though it’s just a static port. Further there is something about the “Process List” nodes enqueueing/dropping events that seems to misbehave a bit when inside the subcomp.
Thanks again, @MartinusMagneson. Your generosity is duly noted.
may be best if @jstrecker takes a look
@jstrecker, if you could, I would just like to know if this is my error or if you think it might be some problem beyond my control.
There is something about the “Make Points Along Curve” node receiving events from the outside (Rings) even though it’s just a static port.
Yes and no. I think this is the root of the confusion (and high CPU usage). Each time an event hits the subcomposition node (Tori Rings), the event goes into the subcomposition through all of its published input ports. Not just the one with the incoming cable (Time), butall of them (including Rings).
This may seem counterintuitive at first. It did to me (and still does sometimes). The reason we chose to implement it this way was because it’s more intuitive from the perspective of the top-level composition. Example:
When an event hits the Make Gradient Checkerboard node’s Square Size port in the top-level composition, both the Square Size published input port and the Radius published input port transmit the event into the subcomposition. Because they do, the subcomposition outputs an image containing both a checkerboard and a gradient. If the event were to only go in through the Square Size port, then the output image would only contain the checkerboard.
If y’all have any thoughts on how to make this behavior more intuitive/apparent on the subcomposition level, let me know. One thing that would help is expanding Vuo Editor support for compositions such that you can use Show Events mode and port popovers within the subcomposition while it’s being driven by the top-level composition. I’m wondering if there are any smaller-effort improvements that we could fit into the development schedule sooner.
RenderGradientCheckerboard.vuo (1.25 KB)
Ok. I need to rethink things here… Thanks again, @jstrecker.
One thing that would help is expanding Vuo Editor support for compositions such that you can use Show Events mode and port popovers within the subcomposition while it’s being driven by the top-level composition.
Yes. Would this mean keeping subcomps in the same Vuo Editor window, with option to save it or leave it in the parent comp, comps within comps, I guess like QC’s breadcrumb method?
Some success! The annoying gap is no more. I eliminated the time port and built out the subcomp a lot more than I originally intended, everything is working.
One thing I don’t get – why does CompositionLoader report 180% cpu in Activity Monitor with fans a-blazing, even though Render Image to Window requested frame reports ~60 fps? What can I look for to optimize?
toriRings_1.vuo (4.18 KB)
jersmi.toriRings.vuo (22.6 KB)
Another question regarding events, I am fuzzy on how to insure published ports update in real time (i.e., without stopping/restarting rendering). This comp is working now, but I wonder if sending events from requested frame is inefficient. Any tips?
Okay, as I enter the next phase of animating the comp by sending Curve nodes to published ports (see pic), the gap problem comes back and it makes the CompositionLoader very unstable.
Try inserting hold nodes on the ins & outs of the “Tori Rings” outside the subcomp.
Well, I thought I tried that, as it seems to be the go-to thing to try, maybe I didn’t, I’ll try again!
Edit: tried it, unless I am missing something, did not solve the gap problem. Maybe it helps rendering stability?
Well, I keep coming back to this with hope that I am doing something stupid, but I cannot get the flashing/gap + fragile CompositionLoader + cpu load to behave. For one, I wish I knew if it was my error or the newness of precomps to Vuo. Does it have to do with how all the precomp ports fire at start? Me not understand…
Ps. Have I said how much I love Vuo? Team Vuo seriously rocks.
Pretty sure I found the issue with the flashing gap – there’s a bug when the torus’ Columns port is published, happens in a precomposition as well as Image Generator. Bug report: https://community.vuo.org/t/-/5338. Definitely a learning experience.
1 Like
[me] One thing that would help is expanding Vuo Editor support for compositions such that you can use Show Events mode and port popovers within the subcomposition while it’s being driven by the top-level composition.
[@jersmi] Yes. Would this mean keeping subcomps in the same Vuo Editor window, with option to save it or leave it in the parent comp, comps within comps, I guess like QC’s breadcrumb method?
I created feature requests Open subcomposition in same window as composition and Ability to create composition-local subcompositions.