Hi!
This is the problem: i need a “Surface constrain”.
I want to drive a particle on a mesh:
-the particle moves in a virtual 2d space (xy).
-the particle is constrained to the surface using the UV space of the mesh. XY = UV
If there were NURBS surfaces… :)
tnx!
Something that works like this patch…
http://vvvv.org/tiki-download_file.php?fileId=1335
…but less CPU expensive…
Any Idea?
it should be possible to patch a “NURBS (3D Surface)”.
look in the modules folder for
B-Spline (3D Surface).v4p
B-Spline (3D Surface Normals).v4p
GridEditor (EX9).v4p
most of them have help files also.
then in the girlpower there is
so i think it is possible to patch this nurbs surface (but it would also be cpu expensive) and it should also be possible to patch it in a way that you can sample a point (together with tangent and binormal) on that surface.
if you want to go this way then first have a look at the patches in the “+Curves” folder in girlpower to get started.
also worth looking at “DeformByCurve (3D B-Spline).v4p” in the modules folder.
i will assist you if you want to go that way…
Thank you gregsn! you gave me many ideas!
…now I have to study… :)
Meanwhile I optimized the Patch above.
Now you can spread particles on the surface;
you can also change the resolution of the grid…
http://vvvv.org/tiki-download_file.php?fileId=1336
Thanks a lot
wow!.. no text …
wow!!!.. no text …
:D… no text …
That is awesome! Great job!
Here the B-spline version of the surface constrain
thanks to gregsn
http://vvvv.org/tiki-download_file.php?fileId=1337
It seems to be faster…
;)
does the Integrate (Differential) miss some Input?
seems so.
but looks especially this way VERY fast…
;)
Someone knows if there some other way to obtain the XYZ position of a point lying on a polygon surface from It’s UV coordinates?
@gregsn, maybe you know, is there any kind of algorithm that work in this way?
I think…It would be very useful to implement it in nodes like Intersect (3d Mesh Ray)
…or better! a new node!
with 2 inputs:
…Perhaps I am dreaming… :D
Tnx
hmmmnice :)
hey dottore,
that’s really a beautiful patch! :)
with the uv coordinates…
If i understood you right your basic idea about the new node is that any point on any mesh can be accessed by UV coordinates.
But i think this is not always true. Normally you only have uv coordinates when you construct your mesh in this way (like you did in your patch). But when you have an arbitrary mesh you don’t have the uv info. So you would need to generate this first by projecting these coordinates somehow (sphererical, cylindrical…) onto the mesh. However, if the mesh has holes (like a teapot) then you get several points for each (u,v) …
Thanks gregsn! your congratulations make me feel proud! :)
as you already should have seen, i posted the constrain as a module in my userpage, both for polygon and B-Spline surfaces…
Obviously the node would be conceived to work with imported x files, with proper UV coordinates defined with advanced texturing tools as in Maya, XSI, 3d studio max, modo ecc.
It would be possible to handle the movement of particles on complex meshes in realtime;
this could near vvvv to advanced tool for particles handling, like Maya for example.
…and this would be an outstanding feature!
hi dottore!
i’m not sure and hope that you can prove me wrong, but i think there is a problem with the uv-lookup within the imported mesh.
i suppose we have to think about what is stored in the xfile.
when exporting xfiles constructed with advanced texturing tools as in Maya, XSI,… then i think these uv coordinates are somehow baked onto the mesh (and then are just part of the vertices, i.e. uv-texturecoordinates).
so we have an arbitrary mesh made of vertices, which at least have
now i cannot think of a shader/node/algorithm which does the lookup task in a straight forward and therefore fast way.
this algorithm would have to search for the triangle including the uv coordinate. and this search task would be something more complex (it could search in the one-dimensional list of triangles, or a better solution could be more adaptive and include adjacency information of triangles to search into the right direction, which could be faster).
for now i think this sounds to be to complicated to just do it right now…
so i would suggest another module (doing something completely different), which you could be also possible to patch.
what about projecting a point onto the mesh. you can freely position the point in space and you can freely define the direction to project that point onto the mesh.
(intersect mesh)
the only thing you need to do is to get that normal (which i think should be possible with the face index)
then you can constrain an object at an arbitrary mesh (even without uv texture coordinates) at that point.
what do you think?
greg
ah yes, and it is a nice one…
very cool! so you only need to plug it together in a different way. would be cool to modularize the heart of it, and use it together in both approaches (curser and surface constrained animation)
Hey guys, I may have found a solution!
check this patch and tell me what do you think about…
http://vvvv.org/tiki-download_file.php?fileId=1350
;)
i think i’m pretty close… but can’t figure out the last step. it is possible to access the relative vertex-space of a face with ParallelEpiped - but i can’t figure out how to map the intersection point into there (vision… too clouded…)
maybe some of you got better luck:
Universal_surface_constrain_12.v4p (50.5 kB)