Sure… as you write, I think that the way VUO uses OpenGL based transform and scale, it essentially does the same thing as the QC coordinate system.
I think that when I have attempted to get the dimensions of an image, it is usually provided in only pixels, not in VUO coordinates.
So, if you have an output texture that you wish to interface with an object like a Make 3D Transform, and have it adjust to the same size as the incoming texture and not just be a 1x1, you have to do the math. Whereas in QC, the Image Dimensions patch, and also Rendering Destination Dimensions, always provided the pixel resolution as well as the QC (OpenGL) unit.
Not a really big deal or anything, just something I find myself setting up often.
If that doesn’t make sense I can post a composition soon.
@jersmi i think many of the things you listed in QC as bad or confusing were a necessary part of the system. Of course having both QC units and pixels can be confusing, but theres no other way. limiting QC to pixels only would be a serious limitation, and no use of pixels, disastrous!
I had my share of issue with needing to use the Crop in conjunction with Translate Image patch it could be mind bendingly obtuse at times. I think Auto-Width on billboards saved wiring up image dimensions patch, good and if you didn’t want to use them they were not requires, you could use real size and do the auto-width auto-height or whatever in your own patches.
@MartinusMagneson in your Make Ludicrous Layer node, what was image Anchor? is that an offset from centre of image co-ordinate for the centre (x,y) to be offset by or something else?
The thing about QC is that it made complete sense (with these sort of things). It might have been a nuance to wire up the image dimensions stuff, but to be honest, I didn’t even have to think to set it up. Vuo has a few of these kinks that are intended to be easy, but they end up being a bit too easy so you have to patch up something custom for some tiny bit more tweakable solution, and then that part isn’t always as straightforward.
@jstrecker the combine layers trick works (mostly as intended) after some tweaking , check the attached node for something akin to what I described. I wonder a bit about the efficiency of doing it like this compared to a compiled C node though? What is the impact of doing it like this when using it in a lot of iterations?
@useful_design the anchor is the 0-point of the image in pixels. In the attached comp it is using the “Crop Image Pixels” node to achieve this, so it’s set to the top left corner of the image.
Perhaps, I’m just used to anchor as it is called so in Photoshop. There it does default to center though, but it is a minor tweak to achieve it in the comp as well. I also think that it is evident by now that I really shouldn’t name stuff…
I think that when I have attempted to get the dimensions of an image, it is usually provided in only pixels, not in VUO coordinates.
@George_Toledo, yeah, it does take some math to convert. We’re planning to add an option to some nodes to pick the unit: points, pixels, or Vuo coordinates. Per your comment, we’ve added Get Image Dimensions to that list.
In case you haven’t seen it, the Make 3D Object from Image node generates an aspect-correct quad.
@jstrecker the combine layers trick works (mostly as intended) after some tweaking , check the attached node for something akin to what I described. I wonder a bit about the efficiency of doing it like this compared to a compiled C node though? What is the impact of doing it like this when using it in a lot of iterations?
A subcomposition should ideally be as efficient as an equivalent compiled C node, since the subcomposition also gets compiled. Though I think we’re not at the ideal case yet because of some issues with multithreading. I think it was you who reported some bugs with subcompositions getting bogged down.
If you wanted to make the composition super streamlined, you could replace the Resize Image with a transform. Resize Image requires a pass on the GPU, whereas a transform would skip that.
I still miss an “auto width” layer like there is an “auto height” one.
For example if I have a row of images with different heights, and I want all the layers to have the same height, but the image ratios to be fine and the layers to fit a given heigh, how should I do that?
Sure I can use the stretched layer now, but have to manually calculate the image ratio each time (and I’m getting different results in Vuo 2beta4 compared to 128, see Calculate image layer different results Vuo 128 - 2b4).
With the .c nodes available in Vuo 2, the non-coder in me thought “let’s just edit the make layer stretched, replace “width” with “height” and maybe that will do the job ;)”
But a) I can’t drag the node to the canvas (I can still put it in the modules folder and then it’s recognised), and b), the node doesn’t retrieve any errors, but the composition starts but doesn’t display any window.
So I looked in the API / SDK and see that for “VuoLayer VuoLayer_make” one can specify the width, but not the height. So is this not possible because of the API ? Would some changes need to be made for this to work ? Or should I change the code with some more difficult math to manually calculate the image ratio ?
I get the point of not having an empty height port, but I think for the scaled layer, one could have a “layer size” input rather then a “width” input, and another port to select the width OR height (and have auto width or auto height).
In Vuo 2.1.0 we added the ability to specify a fixed height for Make Image Layer (Scaled), Make 3D Object from Image, and Make Unlit 3D Object from Image.