- Vuo Founder
- Prefers to be called
- Uses pronoun
- Perth Australia
- 4 years 5 months ago
- Last seen
- 25 min 56 sec ago
I had a visual concept for collapsing all nodes irrespective of their functionality, inputs used or unused, outputs purely for the sake of saving screen real-estate. Especially as 'macros' (in QC speak) don't really exist in Vuo yet and even sub comps have the event-sharing-to-input-port dilemma that prevents its use in many contexts. In a way this is probably a separate FR but putting it down here for context. Happy to make new FR if asked.
My idea is that you just double click on the node anywhere below the title area (which double clicking in is reserved to change the name) and it collapses then click the squished area b/w title and input and output ports (which I've shown with a little triangle icon) to expand it. Dragging a cable over an input or output port would either instantly expand the node or bring up a port sector contextual menu, similar to the converter contextual menu when you drag a cable from a 2D point output port onto a 3D Point input port.
Obviously nodes with multiple input wires would have the wires all entering the same port in collapsed appearance of node, which is fine by me. If there is only one input and/or output port being used then those port labels could be used in the collapsed appearance. Many nodes only have one output port used in most compositions so often that label would appear under this concept. The idea of the animation to expand would be the lower section goes up into the title bar and then comes down again like a blind with all the inputs and outputs in their normal place. When collapsing it would do opposite animate up to hide all ports then come back down with single input and output and all wires attached to them. Maybe even the node class descriptor could be removed to shrink it further.
In the example mockups on this page I'm noticing that the input and output port labels are a long way away from the ports themselves. To me this is not ergonomic and my designer's eye doesn't like it either. I imagine it stems from the large corner radius on the node outline and how that restricts the left margin of the node title (b/c it is left justified) then in turn the port labels want to line up with the title so they get tab a long way into the node.
here's an alternative using the concepts I think have been decided on by people as being desirable. I'm not a big fan of having the data hanging off the nodes, I much prefer the way FB did it with their Origami QC plugin and now stand alone app of pretty printing the data to the right of the port label but I concede Vuo has locked a lot of IP into the collapsed converter concept and having data hanging off ports. It would be great if it was easier to use the keyboard to navigate not just between ports on a single node but between nodes themselves, with via arrow keys selecting cables then nodes or just going from node to node when not going from port to port (if that makes sense, i know what I mean and might prototype it some day!)
Okay I've had a think about this Jaymie and I have a suggestion for the inputs and output(s). But I'm realising the way VUO makes objects is a bit more complex than a simple Renderer patch in QC. This means that you may not be able to simply replicate the Kineme Triangle Family patch (or Quads) quite so easily as 'porting' the concept.
I guess Vuo uses a workflow that's a bit closer to how GPUs actually process geometry into images. Creating 3D objects (that have an opaque datatype in Vuo called "Scene Object" in the 'tooltips') typically have a single shader input for describing the colour and/or lighting for these objects in any given scene.
The only exception I found was the Make Cube with Materials which has a material input for each face of the cube. So I can't find an example anywhere in Vuo of applying different colours to the one object except by applying a gradient image or something convoluted like that.
Anyhow please let me know if you think this is doable, it seems so straight forward to the uninitiated :-)
If we had a single Triangle patch "by vertex" with color inputs for each vertex then a Process List could build the 3D Object list of triangles. I realise in theory one can use the Make Triangle (primitive) node and apply individual transformations for translation, scale, and rotation with the Copy 3D Object node but:
- it's not how I tend to think about making generative graphics (which possibly I could retrain my mind for), I tend to think of creating and manipulating Point Data, and
- the kinds of things I want to do subsequently with the co-ordinates — like rotate points about an arbitrary axis will become impossible for me to wrap my head around if I'm forced to use 3x3Point transform vectors to describe each triangle and then apply 4 steps of transform matrices rather than processing a list of points in 3D space through those transformations required to do the rotate around and axis (folding 3D objects in 3D space essentially).