Although we have the window title of composition run/view windows set to the files name automatically, they all appear as "VuoCompositionLoader" and I can't remember which one is which because Dock always juggles things around.
Be good to have the app process name changed to file name, or even just VuoCompLoader1, VuoCompLoader2,… if that is less work. It's a minor request but would help. I tend to have several compositions running to help me understand how a particular node or combination of nodes works when I'm working on a bigger composition.
I use ⌘⇧R to achieve this ATM, but involves a time wait and reset state penalty.
As I'm learning Vuo still, popovers are one of my favourite debugging and WTFing tools in Vuo. I'd just like them to behave a bit more orderly.
I'd like detached popovers to
Maintain minimum size unless size has been adjust (currently we cannot adjust their window size)
Be size adjustable to see more data at times (less important)
When opened, moved, closed, opened again: return to the previous (user preferred) moved position at least until I quit Vuo.
I arrange a series of popovers on the screen and they are watching lists, and i've deliberately made the lists short so I can see what is going on through the composition as I adjust an input value. Then I make the lists quite long (maybe by accident maybe intentionally) and either way when I return to short lists, the windows don't shrink to small windows again and they're all on top of each other. If I close popover tear offs, when I reopen them I need to reposition them.
I realise they stay at the bigger size possibly to stop them constantly adjusting size and slowing the editor down, so perhaps a one second delay could occur before returning to a minimally appropriate size?
I suppose if any of us know C well, we could read Smokris' Reinterpret 3D Object source code. (Mine is extremely rudimentary so I'm not game) And we would have the base code for a 3D Polygon from Points node! It must be most of the way there, surely? It does the filling for us. Polygon Node FR is listed as 2 out of 3 for complexity "a few weeks of work". Maybe a rework of the smokris code could be a stopgap for the next release? It's just about juggling those points the way @Bodysoulspirit did and combining that with a sub-set of the `Reinterpret 3D Object' code, am I right Jaymie (@jstrecker)?
The bells and whistles of proper 2D polygon corner mitres/radiusing and treatment of compound paths (like the letter "O" or "A" or a circle inside a circle for negative space) could come with an upgrade to the Polygon patch if people started using it and wanting more finesse.
It really depends on your hardware and what all processing of the image is being done in Vuo and VDMX. In some situations, it's true that images with power-of-two dimensions are processed faster. I would recommend making a comparison on your own system — load different versions of a Vuo composition in VDMX, one using 16:9 images and the other using power-of-two images — and see if you notice a difference.
Maybe using Smokris Reinterpret node there could be an even easier way to achieve this.
It was just a quick test and since I don't know anything about the whole openGL vertices triangles thing I have to play around ;)
Yes I see what you mean with giving points that would close and create a shape. Thinking almost vector design here. Maybe also linked to Feature Request SVG & PDF import