Problems with Object Selection
by Paul Scott · in Torque Game Engine · 05/09/2003 (9:35 am) · 8 replies
I've had a slight problem with the Object Selection resource.
I created a couple of shapebase subclasses for my game, and I cannot select some of these objects in game. The raycast doesnt seem to see them.
But it's a little wierd, in that this doesnt happen with all dts models, in all situations.
I can select the default Torque Guy player model, as a Player class, but not as one of my shapebase subclasses.
I can select a dts model I made with milkshape, a simple cube, but only if I tell the milkshape exporter to export a collision box. Without explicitly exporting a collision box, I cannot select it.
I have the mask set to all objects, everything, still I cannot select some of these objects.
Any ideas?
I created a couple of shapebase subclasses for my game, and I cannot select some of these objects in game. The raycast doesnt seem to see them.
But it's a little wierd, in that this doesnt happen with all dts models, in all situations.
I can select the default Torque Guy player model, as a Player class, but not as one of my shapebase subclasses.
I can select a dts model I made with milkshape, a simple cube, but only if I tell the milkshape exporter to export a collision box. Without explicitly exporting a collision box, I cannot select it.
I have the mask set to all objects, everything, still I cannot select some of these objects.
Any ideas?
#2
I CAN select the player.dts when it is in game as a Player
I CANNOT select it when in game as one of my shapebase subclasses
I know I've missed something here when making those subclasses... just not sure what.
05/09/2003 (8:02 pm)
yea, but the important thing to note::I CAN select the player.dts when it is in game as a Player
I CANNOT select it when in game as one of my shapebase subclasses
I know I've missed something here when making those subclasses... just not sure what.
#3
are you sure the base constructor is called?
this is what sets the type on your object.
maybe that is the problem.
05/09/2003 (8:24 pm)
are these subclasses c++?are you sure the base constructor is called?
this is what sets the type on your object.
maybe that is the problem.
#4
If you put the player model in as one of your shapebase classes can you collide with it like other shapes?
05/10/2003 (6:35 am)
Paul,If you put the player model in as one of your shapebase classes can you collide with it like other shapes?
#5
What bothers me about this is that every damn subclass of ShapeBase that wants bounding box collisions reimplements this func, re-writing exactly the same code in each subclass. Furthermore that code checking for a bounding box collision is cut & pasted from Box3F's collideLine() function.
Is it just me or is that a damn fool sloppy way of doing things? I dont have a lot of experience, so I could be wrong here... but damn that seems silly.
So I added a varialbe to ShapeBase:
exposed it to the console:
Set it to false in ShapeBase's contructor, and to true in my subclasses constructors, Then changed ShapeBase's castRay() to:
And that fixed the bug.
Note that I am asking my object box for a collision. I think this is the right and proper way to do things, but I could be wrong.
If any of the above is wrong, let me know
/paul
05/14/2003 (1:16 pm)
yes, I can collide with it as another subclass of ShapeBase, and over the weekend figured out why. The other classes implement castRay(), overriding the castRay() in ShapeBase. They check only for collision against the shape's bounding box. ShapeBase checks for collisions with the .dts's artist-made collision hull.What bothers me about this is that every damn subclass of ShapeBase that wants bounding box collisions reimplements this func, re-writing exactly the same code in each subclass. Furthermore that code checking for a bounding box collision is cut & pasted from Box3F's collideLine() function.
Is it just me or is that a damn fool sloppy way of doing things? I dont have a lot of experience, so I could be wrong here... but damn that seems silly.
So I added a varialbe to ShapeBase:
... bool mCollideUseBoundingBox; } // class ShapeBase
exposed it to the console:
void ShapeBase::initPersistFields()
{
Parent::initPersistFields();
addField("collideUseBoundingBox", TypeBool, Offset(mCollideUseBoundingBox, ShapeBase));
}Set it to false in ShapeBase's contructor, and to true in my subclasses constructors, Then changed ShapeBase's castRay() to:
bool ShapeBase::castRay(const Point3F &start, const Point3F &end, RayInfo* info)
{
if (mShapeInstance) {
RayInfo shortest;
shortest.t = 1e8;
info->object = NULL;
for (U32 i = 0; i < ShapeBaseData::MaxCollisionShapes; i++) {
if (mDataBlock->LOSDetails[i] != -1) {
mShapeInstance->animate(mDataBlock->LOSDetails[i]);
if (mShapeInstance->castRay(start, end, info, mDataBlock->LOSDetails[i])) {
info->object = this;
if (info->t < shortest.t) {
shortest = *info;
}
}
}
}
if (info->object == this) {
// Copy out the shortest time...
*info = shortest;
return true;
}
}
//----start added code -->
if(mCollideUseBoundingBox) {
// Collide against bounding box. Need at least this for the editor.
F32 t;
Point3F norm;
if(mObjBox.collideLine(start, end, &t, &norm)) {
info->t = t;
info->normal = norm;
info->object = this;
info->point.interpolate(start, end, t);
info->material = 0;
return true;
}
}
//<----- end added code ----
return false;
}And that fixed the bug.
Note that I am asking my object box for a collision. I think this is the right and proper way to do things, but I could be wrong.
If any of the above is wrong, let me know
/paul
#6
I'm missing a lot of context but it would seem that in the case where you're wanting to use the bounding box for the collision test you end up having to wait for the standard test to fail (which it will always do for your object) and thus incuring extra overhead. Or am I just being dense again and missing something?
05/14/2003 (7:11 pm)
Paul,I'm missing a lot of context but it would seem that in the case where you're wanting to use the bounding box for the collision test you end up having to wait for the standard test to fail (which it will always do for your object) and thus incuring extra overhead. Or am I just being dense again and missing something?
#7
I had thought that this would allow the artist-made collision hull to override the bounding box if present, but it'd seem that I did not think this through all the way.
doh. ok, what I should do is check for the flag, and if it's set check for an artist made hull, allowing the artist made hull to override....
but that could be a pain in the arse for anyone who uses this after me. They set mCollideUseBoundingBox, yet it doesnt use the bounding box if it has a hull. So maybe a flag should just be a flag, and leave it to the lvl designers to unflag things that have better collision info than a plain 'ol box.
thx for pointing that out, I so didnt notice at 2am. /paul
05/14/2003 (7:43 pm)
yeah, you've got a point there. If your raycast misses the artist made hull, we check the bounding box, and if it hits the artist hull, it would have hit the bounding box anyway. This could make for some real strange collisions points.I had thought that this would allow the artist-made collision hull to override the bounding box if present, but it'd seem that I did not think this through all the way.
doh. ok, what I should do is check for the flag, and if it's set check for an artist made hull, allowing the artist made hull to override....
but that could be a pain in the arse for anyone who uses this after me. They set mCollideUseBoundingBox, yet it doesnt use the bounding box if it has a hull. So maybe a flag should just be a flag, and leave it to the lvl designers to unflag things that have better collision info than a plain 'ol box.
thx for pointing that out, I so didnt notice at 2am. /paul
#8
The collision object should then be poked with either collision volumes of some sort (sphere, box whatever) and/or collision geometry.
What you ideally want is to check the simplest of the collision objects first (lets say box) then refine the collision test ONLY if those pass (so say, if we have geometry, we then refine the search to the geometry, which then can refine down to the poly level etc).
Yes, sounds like a pain in the butt how it is now.
Phil.
05/15/2003 (12:36 am)
Ideally each object would have a "collision" object. We shouldnt necassarily care what that is. It should contain all collision functionality (raycasts and collision results etc).The collision object should then be poked with either collision volumes of some sort (sphere, box whatever) and/or collision geometry.
What you ideally want is to check the simplest of the collision objects first (lets say box) then refine the collision test ONLY if those pass (so say, if we have geometry, we then refine the search to the geometry, which then can refine down to the poly level etc).
Yes, sounds like a pain in the butt how it is now.
Phil.
Torque Owner J. Donavan Stanley