My Humble Project
by BigDaz · in Torque 3D Professional · 02/05/2012 (9:33 am) · 17 replies
I'm making a remote controlled robot, similar to the bomb disposal robots the Army uses. Eventually I'm hoping to have the robotic arm that can move objects about. The general idea being to drive the vehicle from a to b, maybe completing various challenges along the way.
But I'm having a hard time trying to get it drivable. I'd really like a good tutorial on vehicles in T3D, ideally with Physx. I'm finding it hard to do much physics-wise.
Pics:



But I'm having a hard time trying to get it drivable. I'd really like a good tutorial on vehicles in T3D, ideally with Physx. I'm finding it hard to do much physics-wise.
Pics:



#2
02/08/2012 (6:24 am)
I agree with Frank, the model is really good!
#3
02/08/2012 (11:39 am)
Thanks. I'm just starting to texture it now.
#4
Nothing special but it was built from scratch.
Thought I might as well document my progress.
02/19/2012 (1:29 pm)
Making progress with a vehicle :)Nothing special but it was built from scratch.
Thought I might as well document my progress.
#5
02/19/2012 (2:10 pm)
That's awesome - as is Madness.
#6
02/20/2012 (6:49 am)
Sweet!
#7
I can't get torque to add more than 8 to a vehicle no matter how many hubs there are. But I can't see a limit in the code either.
02/22/2012 (2:37 pm)
Is there a limit on the number of vehicle wheels? I can't get torque to add more than 8 to a vehicle no matter how many hubs there are. But I can't see a limit in the code either.
#8
A couple of notes for other people editing vehicles -
The wheel limit is set in engine/source/T3D/vehicles/wheeledvehicle.h
So you need to recompile the project to change it.
When adding animations to a vehicle model in the shape editor, delete all copies of the vehicle from the level first. Make the changes, then put the vehicle back in to the level. Otherwise your changes tend to get ignored. It's taken me ages to figure that out.
02/26/2012 (5:24 am)
After a lot of trial and error I've got my test vehicle tracked up and working nicely :)A couple of notes for other people editing vehicles -
The wheel limit is set in engine/source/T3D/vehicles/wheeledvehicle.h
So you need to recompile the project to change it.
When adding animations to a vehicle model in the shape editor, delete all copies of the vehicle from the level first. Make the changes, then put the vehicle back in to the level. Otherwise your changes tend to get ignored. It's taken me ages to figure that out.
#9
02/26/2012 (7:22 am)
Nice tips BigDaz, and awesome engineering! 8D
#10
02/26/2012 (7:41 am)
Very slick! Keep it up man.
#11
02/26/2012 (3:55 pm)
Those tracks look great! I always wondered how I'd go about doing something like that, but I guess it makes sense to just have a vehicle with tons of wheels!
#12
The gist of it is that you add physics shapes to your model in your 3D modeling program, using the convention "col<type>-#" where <type> is box, sphere, capsule or mesh (I think, at least, since I don't have a model file in front of me to check) and # is just a number for convenient naming. You'll also need a "collison-#" Dummy object (or node or however your 3D program calls it) where # is the same number as one of your corresponding colbox-# or whatever. The dummy nodes do not need to be parented to the col<type>-# meshes. Make these objects correspond to your visible mesh for everything that should have collision.
Then in vehicle.cpp in Vehicle::onAdd() put this code near the bottom (before the return, obviously):
To properly support it, you'll want to add settings to the datablock for turning it off/on and for setting which type of collision it uses (collision meshes from the model, or the visible mesh). You'll also need to add setTransform calls on the mPhysicsRep in the appropriate places (such as Vehicle::applyImpulse) like so:
(A list of places that needs to go (also don't forget to change "transform" to whatever the actual transform is named!): applyImpulse, setPosition, setRenderPosition, setTransform, and updatePos.)
The call in updatePos grabs the transform from the mRigid. I also disabled the updateWorkingCollisionSet() call in processTick(), though it may be necessary if you're making a different type of game than me.
I plan to release a resource for this at some point, but haven't really had time lately. Also, it's a little fiddly and hackish in my build in terms of how it disables regular T3D vehicle collision.
Edit: One major issue with this to note is that it doesn't handle vehicle-to-vehicle collision at all in terms of what happens when the two PhysX kinematic objects collide (they simply won't do anything, and pass through eachother). I haven't actually bothered fixing that in my codebase yet, but one technique is to attach PhysX dynamics to your model (with collision disabled between the kinematics and the dynamics for a given vehicle), matching the kinematic collision meshes and then detecting hits on those dynamic objects in order to apply forces back into the kinematic.
* - Note that this won't work for dynamic vehicles without more work on the code side, but for kinematic vehicles it works quite well.
03/22/2012 (4:36 pm)
This may be a bit too in depth to go into well here, but if you want simple PhysX enabled *kinematic* vehicles I have some info on how to get it all working pretty easily.The gist of it is that you add physics shapes to your model in your 3D modeling program, using the convention "col<type>-#" where <type> is box, sphere, capsule or mesh (I think, at least, since I don't have a model file in front of me to check) and # is just a number for convenient naming. You'll also need a "collison-#" Dummy object (or node or however your 3D program calls it) where # is the same number as one of your corresponding colbox-# or whatever. The dummy nodes do not need to be parented to the col<type>-# meshes. Make these objects correspond to your visible mesh for everything that should have collision.
Then in vehicle.cpp in Vehicle::onAdd() put this code near the bottom (before the return, obviously):
if ( !PHYSICSMGR )
return true;
TSShape *shape = mDataBlock->mShape;
// buildColShape Options
// If the first parameter is "true" it will use
// the objects (col<whatever>), if "false" it will use the visible mesh (slow!)
PhysicsCollision *colShape = shape->buildColShape( false, Point3F::One );
if ( !colShape )
return true;
PhysicsWorld *world = PHYSICSMGR->getWorld( isServerObject() ? "server" : "client" );
mPhysicsRep = PHYSICSMGR->createBody();
mPhysicsRep->init( colShape, 0, PhysicsBody::BF_KINEMATIC, this, world );
mPhysicsRep->setTransform( getTransform() );To properly support it, you'll want to add settings to the datablock for turning it off/on and for setting which type of collision it uses (collision meshes from the model, or the visible mesh). You'll also need to add setTransform calls on the mPhysicsRep in the appropriate places (such as Vehicle::applyImpulse) like so:
if ( mPhysicsRep )
mPhysicsRep->setTransform( transform );(A list of places that needs to go (also don't forget to change "transform" to whatever the actual transform is named!): applyImpulse, setPosition, setRenderPosition, setTransform, and updatePos.)
The call in updatePos grabs the transform from the mRigid. I also disabled the updateWorkingCollisionSet() call in processTick(), though it may be necessary if you're making a different type of game than me.
I plan to release a resource for this at some point, but haven't really had time lately. Also, it's a little fiddly and hackish in my build in terms of how it disables regular T3D vehicle collision.
Edit: One major issue with this to note is that it doesn't handle vehicle-to-vehicle collision at all in terms of what happens when the two PhysX kinematic objects collide (they simply won't do anything, and pass through eachother). I haven't actually bothered fixing that in my codebase yet, but one technique is to attach PhysX dynamics to your model (with collision disabled between the kinematics and the dynamics for a given vehicle), matching the kinematic collision meshes and then detecting hits on those dynamic objects in order to apply forces back into the kinematic.
* - Note that this won't work for dynamic vehicles without more work on the code side, but for kinematic vehicles it works quite well.
#13
That is excellent work!
03/23/2012 (2:40 pm)
So I assume the track is an animated mesh that is animated like the pistons? How exactly did you do the track? That is excellent work!
#14
Frank, yes the track is just a mesh, animated to match the pistons. The collision box of the wheel is bigger than the visible mesh, so it floats off the ground with the track visible underneath.
I might do a tutorial on the process at some point. I want to work out how to scroll a texture to make it look like the track is moving and things first.
My proper robot in action:
03/24/2012 (7:59 am)
Much appreciated Ross, sounds a bit complicated but that's the sort of help I need. :)Frank, yes the track is just a mesh, animated to match the pistons. The collision box of the wheel is bigger than the visible mesh, so it floats off the ground with the track visible underneath.
I might do a tutorial on the process at some point. I want to work out how to scroll a texture to make it look like the track is moving and things first.
My proper robot in action:
#15
03/24/2012 (12:42 pm)
Holy $%^&! That is awesome! Yes, build a tutorial!
#16
The resources section of the GG site is always looking for new victims! feel free! :)
Diamond wipe! Classy ...
03/24/2012 (12:47 pm)
Quote:
I might do a tutorial on the process at some point.
The resources section of the GG site is always looking for new victims! feel free! :)
Diamond wipe! Classy ...
#17
04/02/2012 (4:07 pm)
Awesome vehicle, realy a great work!
Torque Owner Demolishun
DemolishunConsulting Rocks!
As a starting place you might look into the Advanced Vehicles Kit from DeepScratch. He has a good understanding of the physics involved.