Optimisation/Performance of T3D with many objects

Materials, textures, lighting, postfx
  • 1
  • 2
13 posts Page 2 of 2
TorqueFan
Posts: 130
Joined: Thu Apr 30, 2015 5:35 am
by TorqueFan » Tue Feb 09, 2016 3:38 pm
This can be a very long and involved path to travel down, especially if this is planned to be a multiplayer world. Personally I pursued this very goal off and on for a couple years. I spent a month here there discovering exactly why Torque seemed to choke on a world filled with geometry that the rendering code has no problem chewing up and spitting out.

I did finally find a couple solid solutions, neither of which I consider 'easy' to implement. As all things Torque, a solution for any given project is going to require taking it by the horns, wrestling it down, and beating it to submission.

The first thing you're going to find is the biggest cause of performance drop is the network ghosts. Run your mission, push 'N' and then watch your active ghost count go up when you add the statics. As it goes up, your performance goes down. This is because Torque has a client and a server active on your machine and actually ghosts client versions of the data you change in the mission.

You are correct to assume an object to hold many sub-objects can be helpful - but only to a certain degree, depending on the ultimate goal. I ended up creating a class from scratch that rendered out several mesh cubes within one object by building all the vertexBuffer data manually in engine functions. In my case the whole thing was cubes, so I could specify the grid size, had the whole she-bang using multiple indexed materials (for different faces and extended player class footstep sounds), much neighbor detection code, added EngineFunctions, Callbacks... altogether the code for that class is spread out across about 9 or so new engine files =)

On top of all of that, I hadn't mentioned the most important part: back to networking. Even in a singleplayer mission, the way that Torque is going to handle adding and removing objects from the scene is going to impact performance if you aren't careful about how you handle the ghosts. Exactly how to handle the ghosts is a huge can of worms that can be dissected in several ways( again, each solution is going to be project specific of course ). I wrote NetEvent code for my 'object of many objects' that would allow users to send and receive data only about the 'sub-object' within the main object when adding/removing blocks.

After all that's ironed out, you'll want to be considering how all of those objects are going to be ghosted / unghosted from each client depending on distance from that object. Can't stress enough how many different ways this can be approached, but more recently I've found a system similar to the existing TerrainCell or ForestCell engine code( don't quote me on exact names! ) can be extremely effective if you're willing to fight the dragon there. He's a bit scary, but a solid attempt at making custom functions that hook into those indexes could be a good solution.

About mounting, depending on how many objects are being attached to build things it could be required the mount code be extended a bit. There are resources out there on this iirc. A bit of work moreso with models and adding the proper mount0, mount1 nodes etc. I hadn't done much testing with the effect of mounted objects on ghosting and so on but it could be worth a look =) Anyhow, perhaps some information here is helpful, I wish you luck with Torque!
PaulWeston
Posts: 143
Joined: Thu Apr 23, 2015 7:16 pm
by PaulWeston » Tue Feb 09, 2016 11:20 pm
Wow, so much to think about... Thanks all for this info.

Doesn't really get me started on a solution or anything, it all seems a bit over my head, but it's educational nonetheless.

So, what we're basically saying here is that Torque is inherently limited in the amount of objects that can be placed in a world, at least with out of the box T3D code?

That's kind of a bummer, and a huge limitation, funny that this has never been a priority for anyone to tackle and put a fix into the stock T3D engine code.

Do people only make T3D games with less than a couple hundred objects in a scene or something?

I really liked my game where we could build a castle out of blocks and then destroy it into all its pieces. I had it set up so everything was TSStatics, and when you shot them they turned into Physics objects and flew all over the place. I have lots of great working code for that... The problem has always been that any decent castle has at least 500-1000 1X1 cubes, so you build two castles and frame rate drops to below 10 FPS. Always puzzled me, since my blocks are super simple objects with just one simple low-res material on them - you'd think you could load thousands of them without a problem. Sadly this is not the case for me :(
Timmy
Posts: 378
Joined: Thu Feb 05, 2015 3:20 am
by Timmy » Wed Feb 10, 2016 1:57 am
That's kind of a bummer, and a huge limitation, funny that this has never been a priority for anyone to tackle and put a fix into the stock T3D engine code.
It's a difficult thing to do because there isn't really a one glove fits all solution, what may work for scenario A could make scenario B worse.
  • 1
  • 2
13 posts Page 2 of 2

Who is online

Users browsing this forum: No registered users and 8 guests