Getting better FPS in TGE

#1 Philip,

I'm trying to do the same thing your doing and having the same problems your having.


Let me know if you are experiencing the same issues.

Joe

#2 I don't think so, but it'll bear running some tests.

#3 The real trick isn't lower poly models, It's LOD (level of detail) models, With LOD you create the model several times over, each model having fewer poly's than the previous and the engine determines which model to show by how many pixels on the screen of the model are shown.

Very effective method to increase your frame rate and to still be able to have 2-3k poly characters at base. If you look at the screen shots for the showtool pro one of them has pics of the orc model in LOD.

#4 David:

That's a thought, though making multiple copies of every model in the game might be a bit out of scope for the project size. I'm unsure if that'd have really much of an effect with it being a single room. Theoretically, we're not talking about a range in which LOD should be coming into play. I thought TGE auto-generated LOD meshes though. Maybe I misread the demo on it. =) Wouldn't be the first time.

Will definitely keep it in notes though for the future. Thanks.

#5 TGE doesn't autogenerate LOD meshes, for example in Milkshape3d for LOD you create your high poly model, make a copy and use the directx poly reduction tool to a acceptable level, then you place that model in the exact same place in the modeler and name the grouping model_64 or however you choose to name however the _64 refers to how many pixels are shown on the screen or more or less haven't played with it in sometime. Being a single room check your texture maps and make sure you aren't using extra large ones that perhaps are chewing your vid card ram up.

Hope this helps, btw milkshape exporter available here has a LOD detail model for reference to play with.

#6 In my case, most of my models couldn't be reduced. They were so simple that removing vertices would destroy the model. I did tests with boxes and I got the same results.

Philip, don't get held up because my issue appeared to be Mac related. It's only presented that way since that was the only evidence I have to go on without long term access to a PC.

David does bring up a good point about the textures. Make sure you are using textures of reasonable size. If they are too big for the video card then you will be grabbing them from main memory and that would really slow things down.

By the way, what are your system specs? How many objects are you using before you notice the degradation in speed? Some good detailed information would help. Are you using Portals in your interior? I received a huge improvement what I added those to my interior.

#7 Some pointers to work that's been done on some project specific optimizations, but iirc, hasn't been rolled back in TGE.
Might help you to tweak things code side.
A lot of insight in those resources, and the comments after them.
Their author is Clark Fagot, from Bravetree, who when employed at Dynamix wrote the whole DTS system.

www.garagegames.com/blogs/6452/3730

www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=3751

Now, you could also look into sorting the rendering of the various objects (interiors, static dts, animated dts) by texture or opengl states, or both.
Don't forget TGE as a built-in profiler that's quite easy to use, and doesn't need a sizable investment like Intel's VTune does.
Allthough, if you're running on AMD, you can use CodeAnalyst a free profiler optimized for AMD cpus. It also works on Intel ones, but doesn't have as much functionality then.

#8 I don't think your problem is all polygon related ... it's also collision related ... if the level is composed of all .dts shapes then the engine is having to check collisions in a small area on all those separate surfaces. Torque isn't made to be used with a lot of arbitrary geometry. It's great at rendering a huge landscape with a few .dts shapes on it but once you throw a whole mess of them into a tight area it slows down. You might want to try using as much of the .dif interior format as you can as well because that allows for a lot to be culled away. The .dts shapes are the most computationally expensive in the manner which you're using them AFAIK.

#9 David:
Neat to know. Jotting down in my notes. I'll take a look at the texture maps now and do some math on them. Is there a good way to easily check in program if it's doing that though? Would save a fair bit of regular math.

Joe:

Yeah, I read through it all and, as I said, I don't think it's the case. Checking with my modeler, the current count, pre reduction, is 100 models at 108k polygons in the room. I know (now anyway), way too many, which is why those things are getting redone. It got down well enough to run 20-100 on my machine (IBM T30, ATI Mobility 7500, 510 MB of Ram, P 4 1.8 Ghz with DirectX 9.0 c and an unknown current version of openGL), but given my machine tends to magically do things it shouldn't be able to, I'm relying more on the testers that have answered back that the same machine was running under ten frames per second.

And it's a single room. About the size of an average two person college dorm room, or single apartment room. There really isn't a sensible place for portals to be placed aside from the two doors to the terrain outside (which has been deleted and the doors don't actually open.)

Again, if there's an easy way to check if I'm dipping into main memory, that'd be wonderful to know. I've not quite figured out how to go from 'hey, I got a jpg of so and so size' to 'this translates to X bytes in vram' and be at all precise.

Nicolas:

That looks awesome. I'll get working on it right away. And well, while I know Torque has a profiler, I haven't yet figured out how to use it or stumbled across a resource on it. If you could point me in the right direction, I'd be much appreciative.

Jeremy:

I figured that something like that was the case, but given the game design involves having rooms with lots of items to interact with, I don't know how much I can really work around it. Spreading it heavily out really wouldn't work with the game concept and would just leave the players wandering around a level of mostly empty corridors, which isn't very fun.

Thanks everyone for the quick help so far.

#10 Phillip,

To test Jeremy's suggestion remove the colission detection on the objects. I know in blender you just have to remove the link to the collision parent, not sure how hard it is to do on your modeler. But it's a worth while investment in time to determine if you have a collision detection problem.

To test the amount of video ram I believe there is a metrics(video); function you can run from the torque console. It's mentioned in my post I linked you to. I know it works under windows, not sure what all the numbers mean but I do believe one of them is the amount of video ram.

If you really meant 100 objects with 108,000 polys each that is a lot of polys and could be the entire issue as to why you are slowing down.

Not sure what else to suggest as I'm new to all this but I would look up that metrics(); console function. It's really good and the profiler is awesome in torque. Just search teh source for profile and you'll see how it works if your familiar with C++. The Finney book has the function name to enable and disable the profiler. I'm on the way out the door so I can't look it up for you and I won't be back till tomorrow night.

Sorry it's the metrics function
Enter the following on the console.
metrics(video);
glenablemetrics(1);

Joe

#11 Yeah, the info about the profiler is quite scattered all over the place...
Here is a bit of info to get you started, and you can search using the text of the profiling macros in the source files to see examples in the codebase.

www.garagegames.com/mg/forums/result.thread.php?qt=7423

#12 Joe:

100 polys with a combined polycount of 108k for absolutely everything in the room (Can't all be seen at once though). Highest the Total Triangle count goes up to is 41000 (corner of the room, diagnoally facing to get the most of it in visible range).

Was trying metrics(video); before but didn't realize you had to do glEnablemetrics first. Neat. Can't seem to get the metrics(texture); to work right though. It's giving no data whatsoever instead of numbers.

I don't think I can afford to remove collision for most objects in there though (May be misreading what you're suggesting) since by and large they're pickupable by mouse which is using their collision meshes to do it. Unless I misunderstand the suggestion?

Nicolas:

Thanks. Looking over it. =)

#13 Ick. Profiler doesn't seem to work in release mode and debug mode crashes (I suspect because we took out terrain) before it'd be useful. :\ Any ideas on how to let it work in release? Didn't see any #ifndef _debug defines blocking it.

#14

Quote:
100 polys with a combined polycount of 108k for absolutely everything in the room (Can't all be seen at once though). Highest the Total Triangle count goes up to is 41000 (corner of the room, diagnoally facing to get the most of it in visible range).

You do realize an average Torque scene normally has only 3000-6000 triangles in view at any given time?

Closing the "doors" of the room won't cause it to stop rendering the terrain. If you don't need the terrain you should delete it from the mission file (can give you a good boost in performance).

How big are your textures? Textures larger than 512x512 can start to cause serious performance issues in realtime rendering. You are going to want to optimize them as small as you can. Also, typically in realtime environments you only want to use 1-2 textures per model. Reuse the textures as much as possible.

The thing to keep in mind is that *suggestion* can go a long way. A low poly model can be as effective or more effective than a perfectly accurate model. Move as much of the small details as you can from the mesh to the texture. The screws on a desk can be represented on a texture just fine and will save you a couple hundred triangles. Pay attention to what parts of the model affect the silhouette and which don't.

Don't underestimate the power of LOD. With a 100 objects in the room it sounds like you are doing a lot of small things (like calculators, books, pencils, etc.). Those small objects can easily be represented with a lot less polys when they are very small on the screen and then a higher number of polys when you zoom in to them.

How complex are your collision meshes? Are they convex? You are going to want to keep most of them under 20 polys or you are going to take a heavier and heavier performance hit.

#15

Quote:You do realize an average Torque scene normally has only 3000-6000 triangles in view at any given time?

I wasn't aware, but I've gotten that idea during the last week of research on it before opening this. Overguessed originally. It's why I admitted the first thing was having the poly count reduced a lot. My modeler was thrashed a bit recently when I realized just how many polys were going into a lot of the objects from lazy lightwave conversion. It's something we're working on reducing significantly right now.

Quote:
Closing the "doors" of the room won't cause it to stop rendering the terrain. If you don't need the terrain you should delete it from the mission file (can give you a good boost in performance).

The terrain and sky have been deleted for a while.

Quote:How big are your textures? Textures larger than 512x512 can start to cause serious performance issues in realtime rendering. You are going to want to optimize them as small as you can. Also, typically in realtime environments you only want to use 1-2 textures per model. Reuse the textures as much as possible.

1 per model, the largest is 512x512, which technically, now that I notice, is a bit too big for most of what it's doing.

Quote:
Don't underestimate the power of LOD. With a 100 objects in the room it sounds like you are doing a lot of small things (like calculators, books, pencils, etc.). Those small objects can easily be represented with a lot less polys when they are very small on the screen and then a higher number of polys when you zoom in to them.

Fair enough, I'll have my modeler give it a test run, see if that helps.

Quote:
How complex are your collision meshes? Are they convex? You are going to want to keep most of them under 20 polys or you are going to take a heavier and heavier performance hit.

Almost all cubes or rectangles. We're going for generous collision on mouse so we didn't need them to be complicated. I'll double check this though.

#16 100k polygons is a fair bit to render and light but without collision it should be doable on something like a Geforce 3 or better ... although I'm not sure at more than 30fps. If you're using a lesser video card though you're going to be hurting. I'd recommend writing some sort of special routine to enable/disable collisions along with LOD. For many of your objects you should probably only display them when you're relatively close and completely hide them otherwise. Are you rendering any shadows or anything? That can cause quite a bit of slowdown as well. Aerial Antics is all arbitrary geometry with invisible low polygon collision and most of the scenes are 30,000 polygons or less. I think the highest one approaches 50,000 and it can run pretty slow on some older hardware. Without a lot of CPU (collisions, shadows, etc...) optimizations I wouldn't try to run anywhere near 100k polygons. Stick to 20,000 or less for the best performance. You should be able to render a very detailed room with 20,000 polys. Then you should portalize the rooms. I'd imagine Torque's interior code would hide all static meshes inside an interior which is culled ... then again I don't know all that much about Torque yet.