Moving the camera node to second place in the objects drawer seems to solve the problem of the render window going black.
Is this a bug? I think the camera/object and blackout scenario is a bug. Can this thread be spun into a bug report with admin tools here or should I file it manually?
If one gtoledo3 writes up a bug in the middle of the forest and no one is there to read it, was it really ever a bug at all?
I guess this one person conversation quickly morphed to a different topic than "mouse". But I am still wondering about the initial question as well.
Come to think of it, as the OP I feel a little responsible for wrangling the concepts as well, to not lose sight of my awesome FR. :-)
I was super excited when Jean Marie presented
Fire When Value Changes, even felt a little bad for saying, "That's great, but...". So I'll just point to my last suggestion from above:
Fire When Value Changeshas already proven itself awesome, what about the knob that stays on screen version as
Fire When Knob Changes(which then of course spawns other Vuo graphical nodes that could fire when changed, slider or button or color, etc.)?
Thanks for the input, Jaymie. Yeah, the convo here has expanded and contracted, demonstrates the power of the underlying concepts.
The original FR focuses on productivity while building a comp.
But as pointed out, having a few well placed "graphical objects" in a comp would also help the "readability" of a comp. In this regard, think Vuo before and after being able to add comments. GUI is a tried and true tool in the UX/UI toolbox.
Regarding "if anyone in the world can agree" on general principles of UI design, that sounds hopeless. I consider most FR's to be about hope and promise for something I really love -- Vuo.
Just a quick observation — Seems like different people are talking about different end-users of the composition. Could be the composition author themself, or a composition operator who uses someone else's composition within the Vuo editor, or the user of an exported app. While general principles of UI design (if anyone in the world can agree on what those are) would apply to all, the solution that seems most intuitive or fits best with the composition author's + end user's workflow could be specific to each.
Nice response to the mock up -- it was a thought that came together in a few minutes. Occurs to me that the response demonstrates a point of the FR -- potential strength of visual tools, a picture is worth a thousand words and all that.
Of course the Vuo editor is a visual tool as well. In that, Chris , this FR is based on the premise that well designed GUI clarifies and strengthens and makes things easy to read. The FR speaks to the idea of using all available tools for translating information into human readable stuff, where it all adds up, synergistically speaking.
Simplifying again -- since
Fire When Value Changes has already proven itself awesome, what about the knob that stays on screen version as
Fire When Knob Changes (which then of course spawns other Vuo graphical nodes that could fire when changed, slider or button or color, etc.)?
That is, this idea for a new "UI protocol" could/should be a separate FR.
It occurred to me how this request developed across repeated use of Vuo, often/always wishing a
Share Value node could just be a knob or slider that I could tweak asap, like max graphical objects, I guess.
I remember that I was using blend with feedback on the results of a shadertoy node. I would feed output of feedback to the Blend Images node…while also sending output from feedback to various blurs, and then to the other input of Blend Images. I was basically wanting to composite the results of feedback unblurred and blurred, to create some kind of glow/halo effect.
While toggling through blend modes, every so often I would see the render screen kind of white out, as though too much brightness was taking place within the feedback loop itself, even though this composite node was past the feedback node in the chain.
And it wasn’t just brightness or inversion from the blend mode itself…the actual feedback loop would not recover rendering quality. It was obvious that somehow the loop itself was being affected by nodes after it.
However…may be irrelevant now. Just getting it jotted down here while I’m thinking of these particular details.
Yes, and this is another thing that may not be an issue in the most recent version.
I will go back to the composition I was encountering this with, add the parts back in that I think may have caused it, and try to capture video or have a clearer example.
The issue with providing the example immediately is that I had deleted those bits before saving a version, so I have to try to back into it. At the same time, I thought it would still be worth mentioning…sometimes a cause to glance across some code has something glare out, and it can still lead to a fix without a great example of the bug.
This seems like the proper way to attach the objects from the enqueue as well as the camera to the object graph.
But now I have the rendering of the spheres stop after a few mouse moves...I go from seeing the spheres to blank rendering and can't really figure out why. And on one start, I was hovering over the objects node at the window input port, and couldn't see any rendering after I went to "draw" spheres at mouse position.
Is this all hooked up correctly?
Sign up for the Vuo announcements mailing list to get news and join the community. We post about once per month.