sorry, a little guide to use it:
create a plane named Plane01
and a point helper named Point01 above the plane
Hey I wrote this script a while back to perform intersection on a poly object. Supposedly the intersection code should be as optimized as possible according to some coders at my workplace. It checks each triangle for intersection so the lower the face index that is being intersected the faster it will work. Currenly it is setup to work from the mouse position but that can be changed easially by supplying a different .pos and .dir with a ray.
fn Intersectcode =
(
musp = mapScreenToWorldRay mouse.pos
orig = musp.pos
leray = musp.dir
lapos = undefined
testmesh = snapshotAsMesh $
facenum = testmesh.numfaces
vertnum = testmesh.numverts
vallpos = for i = 1 to vertnum collect (testmesh.verts[i].pos)
for d = 1 to facenum do
(
facev = getface testmesh d
vpos = for i = 3 to 1 by -1 collect vallpos[facev[i]]
--two edgevectors
vec1 = vpos[2]-vpos[1]
vec2 = vpos[3]-vpos[1]
crov = cross leray vec1
det = dot vec2 crov
if det < 0.0001 then continue --backfacing
else
(
tvec = orig-vpos[1]
tu = dot tvec crov
if tu < 0.0 or tu > det then continue --outside U
else
(
qvec = cross tvec vec2
tv = dot leray qvec
if tv < 0.0 or tv > det then continue --outside V
else
(
--return true hit if tu and tv is ok
t = (dot vec1 qvec)/det
lapos = orig + (leray*t) --intersection pos
exit
)
)
)
)
return lapos
)
fn IntersectPoly =
(
start = timestamp()
mup = Intersectcode()
if mup != undefined do point pos:mup
end = timestamp()
format "Processing took % seconds
" ((end - start) / 1000.0)
)
IntersectPoly()
cheers,
CML
Hmm I just realized that the code I posted is not failsafe, sometimes it creates a hit outside the object. It always intersects correctly when it interects though. Don’t have time to look at this more right now.
CML
Your routines are very optimized
You make the calculation of the visibility, the collision and the position of this collision by using only one function.
Currently I try to understand your calculations…
Naturally it will be necessary to remove the error if it exists.
Don’t use .mesh.
*Initialize a variable theMesh in higher scope.
*Use SnapshotAsMesh to create a copy of the world-state TriMesh into the variable theMesh.
*Do your work.
*When you are done, you can use delete theMesh to mark the memory as unused for the garbage collector
This will avoid the “memory leak” you would get when using .mesh…
In addition, snapshotAsMesh will give you all transformations and world space modifications, too, while .mesh gives you the mesh on the top of the stack BEFORE world transformations. So if you had SpaceWarp deformations, your code would not take them into account…
Indeed I noticed this problem. I had by-passed it by taking position of my vertices on the Poly object.
Unfortunately if I can not use myPoly.mesh so to calculate manually the intersection isn’t useful… I could use intersectRayEx or RayMeshGridIntersect to find the intersection on the mesh. That is easier and probably faster.
The only advantage of my last script is it don’t use snapshotAsMesh…
Thanks for the help
ps. Where is the documentation about .mesh? I do not find it
I don’t see the problem here. When you intersect with a TriMesh, if you get ABC, you will get two polygons that are using these vertices. The one will use EXACTLY those vertices, the other will use these vertices AMONG OTHERS. Obviously, you would select the polygon that most closely matches the ABC (which IS the polygon using only the vertices ABC), because if your mouse was over the ACBDE, the TriMesh face returned wouldn’t be ABC in any case, it would be one of the actual triangles representing ACBDE (and ABC wouldn’t ever come in question in that case).