renderMeshExample castRay
by Jesse Allen · in Torque 3D Professional · 10/22/2014 (2:59 pm) · 7 replies
We need solid documentation or a working example of this. I've been researching this for nearly a month now and from what I've been able to gather, I don't believe anyone has ever drawn out a cube in Torque and had its castRay() function work. Here's why:
The Problem
Use any of the above examples and fire up Torque. Shoot that cube in the editor. The projectile will go right through it. Not to mention other scripted tests (rayCasts from view or on click) don't work.
Now, I have seen many postings and accomplishments by Bill Vee in the past so I respect his accomplishments. If he didn't have it working, I don't believe that anyone has. Just my 2 cents. Now, recently, I've had both AndrewMac and Daniel Buckmaster (both forerunners in the community and what I'd consider experts using the source) stumble over this problem and have no solution. Who out there has ever created a cube geometry and had its castRay() function work?
More Importantly
The provided renderMeshExample (and probably the other examples) needs to be updated with proper buildConvex() and castRay() functions. As it stands, I don't believe the existing examples are adequately covering all the bases enough to make them useful.
- If you follow any tutorials on the subject, they are extremely vague and I've yet to see a working example.
- In the more current wiki that Lukas started up, the collision example there links back to this old collision tutorial example, which is out of date.
- I did more research, and found another (more current) thread by Bill Vee: Collision Tutorial Object for T3D 1.2 help
- When I found the above thread, the links were dead so I contacted Bill Vee and he fixed the links. I used his exact code example and the castRay() problem still persists.
The Problem
Use any of the above examples and fire up Torque. Shoot that cube in the editor. The projectile will go right through it. Not to mention other scripted tests (rayCasts from view or on click) don't work.
Now, I have seen many postings and accomplishments by Bill Vee in the past so I respect his accomplishments. If he didn't have it working, I don't believe that anyone has. Just my 2 cents. Now, recently, I've had both AndrewMac and Daniel Buckmaster (both forerunners in the community and what I'd consider experts using the source) stumble over this problem and have no solution. Who out there has ever created a cube geometry and had its castRay() function work?
More Importantly
The provided renderMeshExample (and probably the other examples) needs to be updated with proper buildConvex() and castRay() functions. As it stands, I don't believe the existing examples are adequately covering all the bases enough to make them useful.
About the author
Skilled Artist and Musician. Intermediate Torque Developer.
#2
10/22/2014 (3:25 pm)
Respect. Thanks brother.
#3
EDIT: Aha, and the glitch is back. It seems like collideLine sometimes returns a 0 normal. Which it probably shouldn't.
10/26/2014 (5:44 pm)
Okay, this code actually works totally fine for me.bool RenderMeshExample::castRay(const Point3F &start, const Point3F &end, RayInfo* info)
{
F32 t;
Point3F n;
if (mObjBox.collideLine(start, end, &t, &n))
{
if (t < info->t)
{
info->t = t;
info->normal = n;
info->object = this;
info->material = mMaterialInst;
return true;
}
}
return false;
}Haven't tested with bouncing projectiles yet but I'm about to.EDIT: Aha, and the glitch is back. It seems like collideLine sometimes returns a 0 normal. Which it probably shouldn't.
#4
EDIT: Yep, works with Lurker Grenades :) - Well, it does in my project, but here we're using the bounding box. If it doesn't work when testing the RenderMeshExample, it definitely would need more investigation around the bounding box problem that Lukas pointed out. Could just draw out your own box and call it a day, but if there indeed is a bounding box issue it's probably best it gets tracked and beaten down like the dirty bug that it is :)
10/26/2014 (7:12 pm)
Try this, it's basically what I've got now for the cubes I've been working with - minus the indexing stuff. Hasn't been tested with bouncing projectiles yet.bool RenderMeshExample::castRay(const Point3F &start, const Point3F &end, RayInfo *info)
{
F32 test; // Holds the results of the plane intersects
F32 out = 1.0f; // The output fraction/percentage along the line defined by s and e
VectorF norm; // The normal of the face intersected
VectorF n;
if (mObjBox.collideLine(start, end, &test, &n))
{
if (test >= 0.0f && test < 1.0f && test < out)
{
out = test;
norm = n;
}
}
if (out >= 0.0f && out < 1.0f)
{
// Copy out the shortest time...
info->object = this;
info->t = out;
info->normal = norm;
info->point.interpolate(start, end, out);
return true;
}
return false;
}EDIT: Yep, works with Lurker Grenades :) - Well, it does in my project, but here we're using the bounding box. If it doesn't work when testing the RenderMeshExample, it definitely would need more investigation around the bounding box problem that Lukas pointed out. Could just draw out your own box and call it a day, but if there indeed is a bounding box issue it's probably best it gets tracked and beaten down like the dirty bug that it is :)
#5
In other news, I've managed to completely break collision somehow. If you fire projectiles quickly, they bounce fine. If you fire them slowly, they get trapped in 0-normal-land. Huge WTF right there.
10/26/2014 (8:36 pm)
Oooh, ok, so maybe I need to test for the value of t.In other news, I've managed to completely break collision somehow. If you fire projectiles quickly, they bounce fine. If you fire them slowly, they get trapped in 0-normal-land. Huge WTF right there.
#6
This is not the case - the t value is uninitialised, so comparing against it is meaningless. Just write to it with the value it gains from collision with your object.
Of course, if your object has multiple sub-objects, then you need to keep track of t to see which sub-object has the first collision. But the engine's own castRay logic keeps track of t values along the entire raycast, so you don't need to.
10/26/2014 (9:13 pm)
So I have no idea why that video is a thing, but I do believe I've solved the issue. I always believed that when you implemented castRay, you had to make sure that the t value of the collisions you find is less than the t value the RayInfo object already has.This is not the case - the t value is uninitialised, so comparing against it is meaningless. Just write to it with the value it gains from collision with your object.
Of course, if your object has multiple sub-objects, then you need to keep track of t to see which sub-object has the first collision. But the engine's own castRay logic keeps track of t values along the entire raycast, so you don't need to.
#7
10/26/2014 (10:20 pm)
At the very least I got a good chuckle out of the vid :) It's good to finally see some solid resolution to these issues though!
Torque Owner Daniel Buckmaster
T3D Steering Committee