Game Development Community

Large numbers of staticShapes

by Eric Hartman · in Torque Game Engine · 02/16/2005 (1:59 pm) · 2 replies

For Blockland, I'm currently using static shapes (tons of them) for all the blocks. My plan is to make my own gamebase based class for the blocks so I can strip out all the unecessary network traffic and proccessing incurred by the shapeBase and staticShape levels.

My question is, what else can I do to get these things to render faster? I dont really know anything about openGL, so I need some direction on where to start looking. I have already done the following:

-Switched from mesh collision to box collision = no visible gain
-Removed terrain occlusion check (since you never really leave the play area) = no visible gain
-Removed process tick and interpolate tick code from staticShape = ~5% gain

I've noticed that taking out registerLights() results in a large performance gain (but then theres no lighting, duh). I've heard things about using vertex color to simulate lighting, would that be worth looking into?
NextNext Thread
PrevPrevious Thread
More from Torque Game Engine


Associate Ben Garney
#1
02/19/2005 (5:03 pm)
I would suggest writing your own batched cube/block renderer object. Make one big texture so you don't have texture state changes. Make a batcher so that you submit big chunks of geometry to the card in a go. Cache those buffers, only update when you have to, try to get some spatial coherency so that you can cull based on the view frustrum. I would imagine that if you spent a month or two on it you could have VERY good block rendering behavior. Esp. if you culled geometry that was invisible (top and bottom of connected blocks, for instance).

Torque Owner Eric Hartman
#2
02/24/2005 (11:36 am)
So should I keep all the blocks as seperate objects and then have them communicate with a blockmanager whenever a change happens, or should I have one blockReplicator object that handles everything?