Plan for Tony Richards

Can I say again that I simply love Torque?

Today I was modeling my female light armor for Renegades and was a bit concerned with polygon count. I started with a beautiful base of about 10k polys... ouch... did a few renders and the guys fell in love. I did too for that matter. I took the best of some of the actresses and models I've seen (like the stomach of Jessica Biel, Selma Blair's hips and took some bits and pieces of Natalie Portman) and made the woman I'd marry... :p Ok, add some armor and maybe she's a little on the tough side, but you get the picture... but my baby was fat on polygons and that wouldn't work for a FPS where you could have 64+ of these things running around on the screen.

Ok, so I've worked my tail-end off trying to keep this thing looking great yet reduce the polygon count to something reasonable. I got it down to around half of the original without doing much more than eliminating redundant polies, and even skimping on the hands a bit (I was wanting to include some emotes that included the use of fingers, but maybe not now :p)

Now, I know that lower poly models look awesome with a good artist creating textures, and I've got a good way of exporting base textures with subsurface scattering to use for blending (makes texture creation of skin and plastic items a snap), but I had gotten to the point where any further reductions were actually modifying some of the general outline... not something I wanted to do.

Ok, so I'm a coder, not a modeler by trade, and I know Torque supports LOD, so maybe this would be my saving grace. High detail up close, stick to about 5k polygons, but futher away the model would quicky be reduced to 1k or even less.

But exactly how does Torque do this? And, being the disbeliever, I looked to the code to make sure... just in case LOD management was just a bit of marketing hype :p. I was thinking that something based on frame rate would be awesome, but that's not exactly the way Torque handles it. But, what I found was interesting enough and looks like it could do the trick without any modifications.

Basically, the way it works is the Detail Manager targets a polygon count, gives priorities to objects that are closer, culls out objects that aren't even in the view frustrum and actually runs through an expert-system like scoring system to bump the detail levels of each rendered object in an attempt to fit somewhere between max and min polygon count.

The end-user can tune this by simply setting $Pref::TS::autoDetail. This value is a multiplier of max polygon count (maybe it should be a multiplier of min too but it's not). A value of 1.0 for autoDetail sets a maximum of 20k polygons.... 2.0 = 40k, etc.

Just an interesting tidbit of information that I thought maybe I'd share... don't mind me I'm just a little bored :p

There's a lot of other interesting things in the code too... maybe if you've got some insight on the way something works, post it... it might make for an interesting read and keep me entertained ;-)

Just another tidbit of humor... in the bowels of sceneTraversal.cpp where SceneGraph is bulding up a list of objects to render, it has to deal with objects that are actually rendered via portals and add them to the list. It gets a bit hectic and it's clear by the coder's comments that it's done correctly but it was a royal pain.

Quote:
Here's the tricky bit. We have to derive a new frustrum and viewport
from the portal, but we have to do it in the NEW coordinate space.
Seems easiest to dump the responsibility on the object that was rude
enough to make us go to all this trouble...

Just thought it was funny... enjoy.