hi there.
i’m thinking about an intersection cursor.
The cursor should always point on the intersected mesh in 90 degrees. so it is possible to “feel” the surface.
i tried polarcoordinates, but this is not the right way?!
i don’t know if it is possible and how to go on.
perhaps there are some ideas.
i am not so sure
but i think you have to use mesh (split) , vertexbuffer (split).
that outputs the normals.
and then??
do i tell rubbish here? tonfilm? gregsn?
optimized version, instead of transforming all vertices into the world space, just transform the intersection point into the object space to do the distance calculation…
nice work, tonfilm! i thought about that kind of solution when attempting to detect collisions between ODE-Geos and regular meshes.
this approach still fails to detect the proper normal when dealing with low-poly meshes like a box, where several vertices with radically different normals share the same distance to the intersection point.
i thought it would be possible to fix that by taking a number of the closest vertices (not just one), use the mesh indices to determine which 3 of these vertices belong to the same face, and take that normal - assuming that it would be the face we are intersecting. that approach fails because it is not certain that the vertices closest to the intersection point are those of the actual face we are intersecting, and i really don’t know how large the sample of vertices should be, as an arbitrary number of vertices might share the same position.
admitting that this is not really my top priority ;), any idea on how to solve that? or should i be looking forward to the Intersect (3d Mesh Subset Ray) node i see lurking in the changelog?
can somebody help me to get intersectioncursor on a spreaded xfile?
my xfile is a mess. 32 parts linearspreaded by 16 give 16 models of two pieces each.
so i need to intersect slice 0/15,1/16,2/17, and so on.
but when i use getslice(node) to feed intersect and mesh nothing happens.
and another question is, why intersection is a little bit in nirvana. can this be caused by a bad x-file with redundant geometry data?