This thing = way too slow
I got this thing I'm working on. It's too damn slow(~30fps), but a choppy 30fps at that.
The problem is when it draws the models. Is 114912 too many vertices to draw faster than that? It takes about .01 seconds to draw all the models(9 of them, each is about 12000 vertices a piece, in a display list), and since this little program needs to be more accurate than .01 seconds, I kind of find myself in a bind. Should I just try reducing the polygon count on the models, or is there something else I can do?
The problem is when it draws the models. Is 114912 too many vertices to draw faster than that? It takes about .01 seconds to draw all the models(9 of them, each is about 12000 vertices a piece, in a display list), and since this little program needs to be more accurate than .01 seconds, I kind of find myself in a bind. Should I just try reducing the polygon count on the models, or is there something else I can do?
Are you clearing the color buffer? Do you need to?
Are you clearing the depth buffer? Do you need to?
Do you have blending on? Do you need to?
Do you have depth testing on? Do you need to?
Can you downgrade your texture filtering?
Do you have any other state on that you don't need?
Do you have alpha testing on?
Do you have backface culling on?
Can you implement any frustum culling?
This is a good thread on the subject.
Are you clearing the depth buffer? Do you need to?
Do you have blending on? Do you need to?
Do you have depth testing on? Do you need to?
Can you downgrade your texture filtering?
Do you have any other state on that you don't need?
Do you have alpha testing on?
Do you have backface culling on?
Can you implement any frustum culling?
This is a good thread on the subject.
Are you clearing the color buffer? Do you need to?
Yeah, and yeah.
Are you clearing the depth buffer? Do you need to?
yeah, and yeah.
Do you have blending on? Do you need to?
yeah, and yeah.
Do you have depth testing on? Do you need to?
yeah, and yeah.
Can you downgrade your texture filtering?
I removed textures entirely. Only runs about 3fps faster.
Do you have any other state on that you don't need?
Not that I am aware off.
Do you have alpha testing on?
Nope
Do you have backface culling on?
Yup
Can you implement any frustum culling?
I could if I knew how.
The situation is maybe just too many polygons. I need a realistic looking human that I can section off into parts. So, without any kind of artistic ability, I created one in poser. Thats about 17000 polygons, so I had to reduce it. I got it down to 4752 polygons in Lightwave, its still too many, obviously. I maybe just need a better model, so if anyone knows of a realistic looking human <2000 polygons, let me know. Oh yeah, a free one at that.
Yeah, and yeah.
Are you clearing the depth buffer? Do you need to?
yeah, and yeah.
Do you have blending on? Do you need to?
yeah, and yeah.
Do you have depth testing on? Do you need to?
yeah, and yeah.
Can you downgrade your texture filtering?
I removed textures entirely. Only runs about 3fps faster.
Do you have any other state on that you don't need?
Not that I am aware off.
Do you have alpha testing on?
Nope
Do you have backface culling on?
Yup
Can you implement any frustum culling?
I could if I knew how.
The situation is maybe just too many polygons. I need a realistic looking human that I can section off into parts. So, without any kind of artistic ability, I created one in poser. Thats about 17000 polygons, so I had to reduce it. I got it down to 4752 polygons in Lightwave, its still too many, obviously. I maybe just need a better model, so if anyone knows of a realistic looking human <2000 polygons, let me know. Oh yeah, a free one at that.
Check for loops that u can put together (get's me every time)
BinarySpike
BinarySpike
Global warming is caused by hobos and mooses
4,000 doesn't seem unreasonable for an upclose person, but you should try some realtime LOD geometry on your people. so that when farther away, they use less polys
skyhawk Wrote:4,000 doesn't seem unreasonable for an upclose person, but you should try some realtime LOD geometry on your people. so that when farther away, they use less polys
Ok, how?
LongJumper Wrote:Ok, how?heh, well, I recommend reading some SIGGRAPH paper as the technique is relatively new. Also, they do it in DOOM3, so if you can grab that source code too
but yeah, it's a relatively new technique, the SIMPLEST way (READ: non dynamic) is to generate (with lightwave or what have you), 3 levels.
Normal, how much detail you want if the model is half the size as full screen, and then less than eighth size. (I'd say 4,000, 1,000, 500 for the 3 levels). and then a simple "if object is < X distance from camera, draw 4k level model, if >= X distance and < Y distance, draw 1k level, else draw 500 level model.
this introduces popping (you see this often in games like Farcry), but it is by far the easiest solution.
LOD itself is not a new technique. As Skyhawk described, it's simply a matter of drawing things with fewer polygons when they are further away. Start simple: generate a low-poly model and use it when the character is further away. Add a graphics game option or two to control at what distance this happens, so someone with a fast enough computer running at a very high resolution can adjust it.
Things get trickier if you want to dynamically generate the lower-poly models on-the-fly, or have your program derive them automatically when the models are loaded. This is an active area of research in fact, but the majority of games out there are not using cutting edge techniques to get their improvements. Gamasutra had a detailed series of articles about a method of doing LOD for terrain, it might also serve as a good intro to the kinds of issues that occur with LOD.
One more thing: this isn't LOD but you might also want to think about whether some characters are more important than others. Third-person games use a very high-resolution model for the character that the player controls, because it is up close and they'll be staring at that character for most of the game. The enemies are often an order of magnitude less detailed.
Things get trickier if you want to dynamically generate the lower-poly models on-the-fly, or have your program derive them automatically when the models are loaded. This is an active area of research in fact, but the majority of games out there are not using cutting edge techniques to get their improvements. Gamasutra had a detailed series of articles about a method of doing LOD for terrain, it might also serve as a good intro to the kinds of issues that occur with LOD.
One more thing: this isn't LOD but you might also want to think about whether some characters are more important than others. Third-person games use a very high-resolution model for the character that the player controls, because it is up close and they'll be staring at that character for most of the game. The enemies are often an order of magnitude less detailed.
Measure twice, cut once, curse three or four times.
Another thing to consider is a quick way to handle LOD for a whole scene.
I'm working on introducing boulders and trees to my game, and I *want* to be able to support at least a few hundred ( for a terrain that's about 10km square ).
So I've written a simple scenegraph which -- besides being an efficient way to cull invisible scenery -- also assigns an LOD for each visible node. All the objects in that node draw at that LOD. This means that I don't need to calculate the distance to each object, just the node its in. This saves a few cycles.
You might also consider stuff like not drawing shadows for objects in the distance, or even drawing things billboarded when they're really far away.
I'm working on introducing boulders and trees to my game, and I *want* to be able to support at least a few hundred ( for a terrain that's about 10km square ).
So I've written a simple scenegraph which -- besides being an efficient way to cull invisible scenery -- also assigns an LOD for each visible node. All the objects in that node draw at that LOD. This means that I don't need to calculate the distance to each object, just the node its in. This saves a few cycles.
You might also consider stuff like not drawing shadows for objects in the distance, or even drawing things billboarded when they're really far away.
Possibly Related Threads...
| Thread: | Author | Replies: | Views: | Last Post | |
| Weird OpenGL thing... | jfFlash | 9 | 3,306 |
Sep 13, 2006 08:11 PM Last Post: akb825 |
|
| Occlusion queries... SLOW. | TomorrowPlusX | 8 | 4,018 |
Aug 19, 2005 07:05 AM Last Post: TomorrowPlusX |
|
| Are SDL events slow? | Skorche | 3 | 3,685 |
Jul 25, 2005 11:08 AM Last Post: Skorche |
|
| SDL got pretty slow on Tiger? | Zeeke | 17 | 8,089 |
Jun 5, 2005 12:29 AM Last Post: Kevin Lindeman |
|
| Slow first time draw of textures | rzilibowitz | 4 | 3,203 |
Jan 17, 2005 01:46 AM Last Post: rzilibowitz |
|

