Torque 3D and The Art Pipeline

#1 1. DIF is still supported but no one is going to force you to use it. You always could use POLYSOUP from TGEA upwards.

2. Collada load native, no 'export' needed. Collada loads into T3D, and T3D convert it into a DTS automatically, no intervention on your part. DTS is still the internal T3D mesh shape format.

3. Very little will need to be changed. Just like very little script changes were needed for TGE scripts to work in TGEA.

4. This is a good question, one what i do not have an answer for.

#2 Yeah I know I can use polysoup, but right now in TGEA its the most horrible feature there is. Will T3D have proper polysoup collision? Polysoup that doesn't crash the game or gets players stuck in the soup?

#3 "Will T3D have proper polysoup collision?"

Um, TGEA1.8.1(the version i use) seems to have great polysoup collision, I never have any trouble with even the most complex mesh i have used. So far the same is true for T3D.
You do understand that polysoup collision is not a magical thing that gives license to atrocious mesh construction yet works still as intended? Your mesh still need to be free of all the normal errors that most any game engine stumble over.

#4 T3D doesn't have anything new for interior environments. You can create them in DIF or you can create them in Maya and export as Collada, and they can be imported in as DTS. But there is no portalization or other types of zoning.

The Polysoup collision in TGEA is in fact not all that good, and by default T3D is using pretty much the same. However, T3D does come with some basic PhysX support, and with a little bit of extra work you can bake your static geometry as PhysX tri meshes which will give you much better results. For dynamic geometry you'll need to use convex meshes, but PhysX supports up to 256 faces per convex, and NVidia has a plugin for Maya which will help you auto-generate convex meshes, so it's not quite as painful as the standard TGE/A convex collision mesh gig.

One important caveat; the PhysX support is, I believe, not setup for networking, so it will only be good for single-player games.

#5 So am I to take it, im the only one that have never had a single problem with Polysoup? In what way is Polysoup not good for so many folk that say such things?

#6 The root of the problem is that the Opcode stuff was just shoehorned into the old collision response system of the player class (for Player collision/response), so it's not setup to use Opcode optimally or correctly. For one thing it can be incredibly inefficient because of the way it collects the collision working sets.

As a little anecdote to indicate just how inefficient it is... I have my TGEA setup to use PhysX for most collisions... and it works very fast... but recently I had a really bad lag issue in some parts of a scene with some dense geometry when the player was moving through there. It would go down to like 5 FPS in some cases.

So I initially figured it was just that I was overloading PhysX, but I tested the same scene in a little Ogre3D sandbox with PhysX, and I was getting something like 350 frames per second.

After some profiling and debugging, I discovered that the bottleneck was in the collection of the working sets that are used to do the player collisions. We weren't even using them for the primary collision/responses, it was only used to determine if we were standing on a runnable/jumpable surface to activate the correct animations. This in itself is very light work. The lag was just in the way Torque collects the working sets of polys.

Once I cut that out and set it up to use PhysX to determine that too, it ran smooth as silk. So we can do 100% collision/response on this complex geometry with PhysX, but just collecting the polygons to determine if we're standing on a runnable surface, using the built-in Torque/Opcode constructs, brought it to a crawl. That's pretty inefficient :P

(Unfortunately it uses a very similar method to collect the polys for dynamic shadow receivers... so I still have to figure out a way to speed that stuff up.)

The other problem is that it's not very forgiving. I've seen the player get stuck just running along a wall that has a door; apparently it can't handle the crack between the door and the wall especially well. It doesn't always happen, but it happened enough to make it an unusable system for me.

#7 Thanks Gerald. That puts a light on it. Its more a matter of how one is using Torques version of opcode, if they will be having troubles with it. I knew Polysoup had some limitation. The only one that effects me is the poly count per mesh, but even up to 12,000 poly i have never noticed any performance hit.

#8

Quote:
Thanks Gerald. That puts a light on it. Its more a matter of how one is using Torques version of opcode, if they will be having troubles with it.

Indeed this is true.

It can handle large objects with a reasonable amount of polys fairly well, and small areas with dense polys, but larger areas with dense polys are a big problem. Once it caches the polys in a certain vicinity it runs okay, but when it has to constantly update the working set with lots of polys every few frames, then it's not so good.

#9 Thanks for the in depth info. I will need to keep this in consideration whenever i have odd performance issues, it may help track the problem down at least give me an idea where to look.

#10 Okay a little light on our situation:
We are making a game where you fly small aircraft (toys) in a room. Its for a college project, and its coming along quite nice. However, our airplanes are quite detailed and have things sticking out - I figure thats where the problem is lying. Most airplanes range from 4k to 8k polys, if I'm not mistaken.

The moment we hit a static object we insta-freeze. So we had to create the convex collision mesh manually. This sucks hard and the artists spent two days making boxes around props instead of doing any actual production work.

So we're not very happy with that.

@Gerald: Is it hard to implement PhysX to do the polysoup for us? Do you happen to have example code?

#11 @Eric,

If you're using Maya 8.5 or 2008, then you may seriously want to look into the PhysX DCC plugins. I haven't actually used the one for Maya yet, but if it's like the one for Max, then there should be a Geometry Tool that will create a tight convex mesh around an object with one click. Even if you don't use PhysX you can use it for plain old DTS collision meshes, and it may save your artists a lot of time.

For your planes you'll almost certainly need to use convex volumes no matter which way you go. 4k-8k polys for a dynamic object is a bit much. Even in PhysX that wouldn't really be realistic without using convex volumes. Your static geometry can be polysoup and as complex as you want, but PhysX doesn't support polysoup vs polysoup collisions, only convex vs polysoup and convex vs convex.

As far as example code for PhysX, I'm not really at liberty to share my code at the moment, but there is a PhysX resource for TGEA floating around. I have to run in a sec so I don't have the time to search for it, but search the TGEA forums for some posts by a guy named 'deepscratch', he was working on that resource I believe. I'll look around later if you can't find it. It's not real hard to implement PhysX in TGEA, but it will take a competent programmer to do it well. With T3D, it would be a lot easier, since the core of it is already implemented.

Cheers

#12 Alright, thanks for the answers. Then I'm not sure if we're going to switch to T3D, at least I personally am not sure.

#13 Just bought T3D and checked out the polysoup. Seems to be working just fine.