Oh, I see now that there is a particular way of dragging the cable that automatically pulls up the convert dialogue, that I must have inadvertently done the first time with Multiply, but not the second with the Add node.
I was then surprised that I couldn't "grab" the 1 and 2 entries and when they were highlighted, delete them by hitting the delete key. I guess in the moment that's what I was thinking to do to possibly turn the port to a generic type, so that then it might interpret the data type and reconfigure. Oh well.
I also now see that it the port type can be manually edited as well by control+click.
Oh, no…if white is at the color port everything is the same. Like objects in QC, or many others in VUO for that matter.
It may be that this layer node group uses some mac framework that doesn’t allow this…maybe it is CG backed, and in that case, I am unsure if Core Graphics exposes that. But why would the layer engine be CG backed? So that may be completely wrong. It just came to mind, thinking of any possible reason.
Distance min isn’t the front clip point of the camera?
I thought it would be the front clip, and I thought the max would be the rear z clip.
Thanks for the head’s up. I do not understand what is actually going on there yet, but hopefully it will become clear after looking. I guess this makes plenty of sense because I wasn’t getting expected results there in general, it seemed like something is wrong with the projection space.
It's not the order of the camera that leads to a black screen, but the fact that in the "mouse snake spheres 2.vuo" the minimum distance for camera is set at > 2, where "mouse snake spheres 3.vuo" is set back to 0,1 minimum ;)
Nice to have your input here GeorgeToledo. How long ago since the QC ribbons examples you shared on Kineme?
I did share a couple of ribbon and cyclinder patches here a while ago: https://vuo.org/node/2680
I also got one going with working UV's using Parabox nodes a couple of years ago, I'd love to see that was possible again: https://vuo.org/node/2416
It is great that the boolean exists, and it is expected that it would have a 0/1 interface. But I am re-noticing that all of these other integer type situations don't have a zero available.
I think that not having the basic "starting point" available in all of these situations, removes the ability to cleanly use many typical programming patterns. When structure counts go from zero to 1, you often "do something". 0/1 events can help deal with alpha and color fade transitions, texture mix. Values are often seeded at time 0, so you can easily kick off evaluation chains by using time to do the switch.
It is the fact that events, time, counts, etc, all start at 0, that in some situations just adding a -1 to offset actually creates problems in other edge cases, and then you're clamping values to fix that. It can create a cascade of issues.
I see a response from years ago from Steve about this, which I stumbled on last night after posting this, which refreshed my memory about some of the thinking.
I am actually very receptive to the motivation behind this implementation choice of so many things starting at 1, but I think it is a solution for a non existent problem, that in turn actually creates many problems. While it may take a very new user a second to wrap their mind around representing 0...the very concept of 0/1, binary, is almost meme-level. Gregorian calendar starts at year 0, timers start at zero, countdowns go to zero. I give people credit to understand this. :-)
But I have to add now...as I am really seeing how integrated this decision is into vuo, I am maybe more flummoxed than when I posted. I am very sympathetic to the fact that changing this across a number of patches is a major change at this point in the road. I think it would not be the biggest deal in the world to just modify these patches to count zero, and if this is truly something that only I have an issue with, then I don't want it to be a time drain. It may be an exercise best left to myself to deal with. It is unfortunate that the solution would be to replace these or to then have a different version of these nodes existing alongside.