🔒 Locked

High Performance Rendering

Started by gauntalus Mar 24, 2006 at 10:03 AM 16 replies 2.4k views

Original Post

Mar 24, 2006 at 10:03 AM

I have a question about how I should go about rendering models in the chess game that I'm working on. Currently we have insanely high-poly models, once all the pieces are on the screen we are displaying about 150,000 triangles(total, for all the pieces). We're planning on drastically reducing the poly count on each of the models to heighten performance, but I was wondering if in the other direction there was something that I could do to make high poly models a bit more acceptable. Currently we're using GL_TRIANGLES to render the models, but I figured we'd get a huge boost if we just organized the models into GL_TRI_STRIPS. Would we get about a ~300% increase from this? How hard is it to do? Are there any other suggestions that anyone has? I appreciate the help, thanks.

Promit

Mar 24, 2006 at 10:07 AM

You'd be better off using indexed triangle lists than strips. I assume you're already using VBOs. Also, at those poly counts you would have to be using 32 bit indices, which will cost you in performance. Of course you said you're going to drop the poly counts, which you definitely should, because 150K per piece is just plain silly (artists are fond of high resolution NURBS, are they?). If you really don't want to cut the poly counts too much, you should look into doing dynamic LoD on your models.

smitty1276

Mar 24, 2006 at 10:07 AM

Are you using vertex buffers or display lists?

acid2

Mar 24, 2006 at 10:14 AM

A common thought is that tri strips improve performance, but its actually rarely the case. You end up with multiple batches to get efficient strips, and so on. I suggest you look into index buffers, an adaptive lod techniques if you really need this kind of poly count.

gauntalus

Mar 24, 2006 at 10:15 AM

Sorry if I was unclear, when we render the entire board and ALL the pieces there are 150,000 polys, so each piece is roughly 4500 polys. To answer smitty's question, we're using display lists.

I think we'd like to avoid dynamic LoD, since my proposal was unclear I think you probably wouldn't have suggested this otherwise.

So, with that said, suggestions?

Promit

Mar 24, 2006 at 10:18 AM

You have too much geometry, period. In a chess game culling won't help, and LoD will provide limited benefits, compared to the effort required.

What you should probably do is to stop using such high resolution geometry, and leverage normal mapping or parallax mapping instead.

Lopez

Mar 24, 2006 at 10:19 AM

You could normal map your chess pieces. Use multres in studio max 7/8, and render a normal map for it, that will greatly reduce your poly count.

smitty1276

Mar 24, 2006 at 1:09 PM

I agree... It's really hard to imagine why you would need 4500 poly chess pieces (it's your game, though :-))

It seems like 300-500 should be more than enough... what sort of pieces are they, out of curiosity?

RobTheBloke

Mar 24, 2006 at 3:26 PM

Quote:
Original post by gauntalus
Sorry if I was unclear, when we render the entire board and ALL the pieces there are 150,000 polys, so each piece is roughly 4500 polys. To answer smitty's question, we're using display lists.

That should be ok. Use static VBO's instead of display lists, you'll get a bit more performance. The polycount is *high* either consider swapping out some of the models further from the camera to slightly lower poly ones (it'll be fine on a 2ghz+ pc with Geforce6 +). You will need to drop the geometry amount a fair amount if you want to use shaders.

Quote:
I think we'd like to avoid dynamic LoD, since my proposal was unclear I think you probably wouldn't have suggested this otherwise.

Dynamic lod is not going to make the game any quicker (high cost for tesselation or splitting triangles), model swapping is worth considering though (and other things, like only using different high quality shaders for the closest objects, low cost cheap shaders for those things in the distance etc).

owl

Mar 24, 2006 at 3:30 PM

Quote:
Original post by acid2
A common thought is that tri strips improve performance, but its actually rarely the case.

The cases I've experienced myself showed to improve performance quite a bit. Reducing the number of vertices you upload always help. But I agree that stripping meshes can be a hell if you lack the knowledge and the tools.

oggialli

Mar 24, 2006 at 11:49 PM

Quote:
Original post by owl
Quote:
Original post by acid2
A common thought is that tri strips improve performance, but its actually rarely the case.

The cases I've experienced myself showed to improve performance quite a bit. Reducing the number of vertices you upload always help. But I agree that stripping meshes can be a hell if you lack the knowledge and the tools.

You don't really upload any vertices when using fully static VBOs. The thing is, when you use triangle strips, one vertex specifies one triangle, right? So that basically means one vertex to transform per triangle drawn. Now, your average model actually has a vertex-to-triangle ratio of around 0.5. If you use indexed triangle lists, and exploit the post-transform vertex cache on modern GPUs well, you'll be transforming only around 0.6-0.7 vertices per triangle opposed to ~1.0 with triangle strips. This is what the GPU makers recommend.

owl

Mar 25, 2006 at 2:18 PM

Quote:
Original post by oggialli
Quote:
Original post by owl
Quote:
Original post by acid2
A common thought is that tri strips improve performance, but its actually rarely the case.

The cases I've experienced myself showed to improve performance quite a bit. Reducing the number of vertices you upload always help. But I agree that stripping meshes can be a hell if you lack the knowledge and the tools.

You don't really upload any vertices when using fully static VBOs. The thing is, when you use triangle strips, one vertex specifies one triangle, right? So that basically means one vertex to transform per triangle drawn. Now, your average model actually has a vertex-to-triangle ratio of around 0.5. If you use indexed triangle lists, and exploit the post-transform vertex cache on modern GPUs well, you'll be transforming only around 0.6-0.7 vertices per triangle opposed to ~1.0 with triangle strips. This is what the GPU makers recommend.

Actually when you use VBOs you do upload your vertices once, and not only your vertices, but also the normals the UVs and the color information.
All that stuff occupies memory. What if your vertices need to be transformed by a skeleton each frame? What if you have lot's of complex models that need to be animated almost constantly?

Reducing the number of vertices you need to work with will always be a good thing.

zedzeek

Mar 25, 2006 at 3:04 PM

150,000 tris aint much per frame even for oldish cards eg my gf2mx could easily run it realtime.
ild ignore all suggestions of LOD etc.
strips dont buy u much more performance in reality (only 2-10%) so its really not worth the bother.
the limiting factor for static models is what shading method do u use to render the pieces (not the vert count) eg a single directional light is gonna be much faster than a glsl shader that does reflection / shadows etc. its been like this since last century when hardware t+l came out.
youre best off using Display lists.

youll have to discribe what u want better.
eg what target hardware, what lighting/shading model

Promit

Mar 25, 2006 at 3:07 PM

Quote:
Original post by owl
What if your vertices need to be transformed by a skeleton each frame? What if you have lot's of complex models that need to be animated almost constantly?

That has no bearing on whether you should tri strip. It just means that you should be using indexed primitives (which you should be doing no matter what).

owl

Mar 25, 2006 at 3:51 PM

Quote:
Original post by Promit
Quote:
Original post by owl
What if your vertices need to be transformed by a skeleton each frame? What if you have lot's of complex models that need to be animated almost constantly?
That has no bearing on whether you should tri strip. It just means that you should be using indexed primitives (which you should be doing no matter what).

So, by the mean of an index you can automatically transform/update all your shared vertices as one in a VBO?

Promit

Mar 25, 2006 at 5:03 PM

Quote:
Original post by owl
Quote:
Original post by Promit
Quote:
Original post by owl
What if your vertices need to be transformed by a skeleton each frame? What if you have lot's of complex models that need to be animated almost constantly?
That has no bearing on whether you should tri strip. It just means that you should be using indexed primitives (which you should be doing no matter what).
So, by the mean of an index you can automatically transform/update all your shared vertices as one in a VBO?

I'm not sure what exactly you're asking, but with indexed primitives each vertex appears exactly once in the VBO. Whether you tri strip or not just alters the structure of your indices.

owl

Mar 25, 2006 at 11:24 PM

Quote:
Original post by Promit
Quote:
Original post by owl
Quote:
Original post by Promit
Quote:
Original post by owl
What if your vertices need to be transformed by a skeleton each frame? What if you have lot's of complex models that need to be animated almost constantly?
That has no bearing on whether you should tri strip. It just means that you should be using indexed primitives (which you should be doing no matter what).
So, by the mean of an index you can automatically transform/update all your shared vertices as one in a VBO?
I'm not sure what exactly you're asking, but with indexed primitives each vertex appears exactly once in the VBO. Whether you tri strip or not just alters the structure of your indices.

You're right. Sorry.

gold

Mar 26, 2006 at 8:50 AM

Your geometry count is not unreasonable. The advice above, while sound, may not help because we have not determined your bottleneck. Are you using a complex vertex shader? If you replace it with a simple shader do you see a speed-up? If so the bottleneck is not the manner in which you give geometry to the GL but the per-vertex processing in the shader.

You could also be validation bound; are you using the API efficiently or are you making lots of redundant state changes?

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.