A node that is able to generate a mesh data file (.data) in Paul Bourke’s .data format used by vuo.image.project.dome.
Would be great to have this as currently we can use .data files, but only those written with either custom software- or Pual Bourkes software.
It would be very useful to have a node that takes variables and generates a port type that is unique to the vuo.image.project.dome format.
Currently vuo.image.project.dome only loads a .data URL, it would also be good if this could be separated into a .data file loader - and a warp image node that does the warping. That way we could push custom warp meshes into the node from within Vuo.
Useful for doing advanced projection mapping, and considering this is already working in Vuo could allow an easy and fast path to this feature.
No, actually I’m thinking much more general. Pauls mesh mapper is mainly for mapping of dome environments, however the the mesh file can express any deformation. I was wanting to have a node that allowed us to generate complex deformation, not only for mirror dome.
I think that the node could possibly have a list input of XYZW values associated with a row and column number. The node assumes that if there is no values in the list- then it simple passes a perfect grid of values. If there are values in the list it uses them to deform the grid in the manner that is indicated. Does that make sense? So it could function like an advanced projection mapping tool for irregular surfaces, which we could change on the fly - or even calibrate surfaces with it. Then we could even save out that data.
I believe that the mesh format allows standard, and polar coordinate modes. This could also be a port. And possibly the mesh size, (rows and columns).
Alternatively maybe the list could be of xyzw values that have an effect on the mesh, with everything being relative to 0-1?
OK, so you’re interested in a node that inputs points associated with rows/columns and uses them to transform a grid into some arbitrary shape, which may be a dome but doesn’t have to be, and you want to be able to save the points to a file.
I think we can merge part of this FR with your other FR, Deformable Mesh. For the other FR, the node would also input points associated with rows and columns. The node could have the option to input either all grid points (as proposed in the other FR) or just a subset of the grid points (as proposed in this FR).
As I understand it, the main unique part of this FR would be the ability to convert a list of points to Paul Bourke’s mesh format.
You said the points would be XYZW, but if you want to output to the PBMesh format, that’s (x,y,u,v,i).
Although the PBMesh format has a mesh type option of rectangular or polar, that option doesn’t actually mean cartesian or polar coordinates. The vertex positions are always cartesian. When the mesh type is polar, that just means that the vertex positions for the first column and the last column are equal. The Vuo and Kineme PBMesh nodes ignore the mesh type option, since it doesn’t affect how the mesh is rendered.
If that all sounds OK, I’ll update this and your other FR.
Yes that sounds good, as long as there is a simple way to also get data into the dome warp patch as well. Currently we need to use a file, but it would be good to have a “dome warp Port type” so that we could generate data in real-time. So also disconnecting the loader from the renderer.
If you had a mesh from the node proposed in the Deformable Mesh FR, you could feed the mesh and an Unlit Image shader into the Make 3D Object node. It wouldn’t be necessary to feed it into Warp Image with Projection Mesh.
Updated this feature request’s “Notes from Team Vuo” and opened for voting.
Whatever came of this? This sounds like exactly what I am looking for in my recent post - the ability to add two more points on a square image, so I can warp it into a Z perspective look. While this post is looking for something that i can see becoming much more complicated, the ability to populate a simple 2D mesh in real time, and warp an image in this way, is hugely beneficial :)
While I accept that the warping mesh is general, can’t what is being proposed here be done with a GLSL shader?
For example, my current warping playback for offset fisheye projection is shader based, see attached photos.
And my current warping for spherical mirror installations is now also a shader.
In both these cases the warping is performed based upon a number of parameters describing the geometry/optics. This would also be necessary for any other warping, such as that required to create a mesh representation.
