Make Parametric Grid Mesh node doesn't conform to documentation

Bug Reports
1

Steps causing the bug to occur

Not quite a bug, more of a documentation inconsistency:

The doc for “Make Parametric Grid Mesh” documents the following parameters:

U Expression, V Expression — The math expressions for the texture coordinate of each vertex. This defines how an image or other texture will be stretched across the mesh when the mesh is combined with a shader to create a 3D scene object. Typically, the values of these expressions should fall between 0 and 1, and should either always increase or always decrease, as U and V range from 0 to 1

But the node itself does not take these expression parameters. There are only expressions for X/Y/Z and they are expressed as functions of U and V. As a result, the UV texture coordinates cannot be manipulated independently, and the mesh created will always have a “flat” UV texture mapping, relative to the two parameters of the parametric surface.

I think the best way for this node to work, would be to accept mathematical expressions for all of X, Y, Z, U, V in terms of two other parameter variables (perhaps p and q?). This would make it possible to create arbitrary UV texture mappings independent of the mesh’s shape in XYZ space.

Other notes

  • Vuo version: 1.2.5
  • macOS version: macOS 10.12
  • How severely does this bug affect you? It prevents me from completing a specific task with Vuo.
2

If this actually belongs in feature requests I apologize :)

3

Oops, yeah, that documentation is wrong. Thanks for catching that, @unicode.

Could you describe how you intend to use the U/V expressions? Like, what is the task you’re trying to accomplish, and how would the ability to manipulate UV texture coordinates independently make it possible / easier than just using X/Y/Z expressions? I ask because a concrete example helps when thinking about possible improvements to nodes.

4

The specific task I had in mind when writing this, is creating a banner-like curved surface, and then scrolling an image around that surface, marquee-style. I can work around this by flat-mapping an image onto the entire surface and then using scaled layers and Tile Image nodes to position the image wherever I want (example project enclosed) but this is wasteful. There are tons of texels on this 3d surface being wasted on a flat background colour, and I have less detail in the image area because i’ve had to scale the image down instead of just positioning it where i want it on the surface.

It would be nice if I could just manipulate the UV mapping of the surface by itself (maybe just by making the V expression a clamped linear function, and making the U expression scroll with time) in order to slide the image around on the surface, without this affecting the position of the surface’s points in XYZ space. This would make it unnecessary to do all these image/layer manipulations to the image, and it would also allow saving all the image’s detail where it’s actually needed.

Flat scaling/scrolling is just a simple example, though. If UV were parameterized just as XYZ is, there’s all sorts of other, wilder image-warping stuff we could do on these parametric surfaces too. :)

scrollingMarquee.vuo (5.89 KB)

5

Oh, hey, I just thought of another use case - it’s not MY use case, I have no current need to do this, but I think it better illustrates the usefulness of separating the UV texture coordinates from the parametric surface parameters.

Suppose I have several different world-map images, in different projection styles. One is a cylindrical Mercator projection, one is an equal-area Peters projection, perhaps another is in raw spherical coordinates. I want to wrap all of these onto spheres in a geographically accurate way.

In order to do this with the current implementation, it seems like my best bet is to come up with a few different ways of parametrically defining a spherical surface, definitions which produce different amounts of vertex density near the poles vs. near the equator. This math gets tricky very fast, and I might not want geometry with those varying levels of vertex density.

It would be much tidier if, instead, I could define the geometry of the sphere in XYZ-space according to a spherical coordinate system, and give mathematical expressions for X, Y, and Z in terms of latitude and longitude (perhaps ranging from -180 to 180, which simplifies life since the trig function operate in degrees by default) and then separately come up with mathematical expressions which express the U and V coordinates of the map images (perhaps ranging from 0 to 1, consistent with how other 3d packages treat UV) as functions of latitude and longitude as well.

This way I can have more or less texture detail near the equator vs. near the poles, without having to also create higher/lower vertex density in those regions.

(Again, this isn’t something I have any pressing need to do right now, but hopefully it illuminates how much more versatile this node could be.)

PS, thanks for all your amazing work!

1 Like
6

Great, thanks for elaborating. I’ve created a feature request: UV texture coordinate math expressions in ‘Make Parametric Grid Mesh’ node. In the meantime, we’ll remove the documentation about U and V expressions.

7

We’ve removed the documentation about U and V expressions in release 1.2.6.