Polygon count

Started by
18 comments, last by Viper173 19 years, 7 months ago
Comparing engines with FPS is also pointless because it doesn't take into account background processing. I can make a 3d demo that renders way more FPS than a video game with about the same scene quality. Why? Cuz I'm not handling AI, Game Mechanics, and Collision Detection etc. Some game have alot of power going on without you knowing, insane scripting engines, physics that even god couldn't touch, etc. Like everyone said, you probably should just pick a target platform, and decide if your engine meets your own expectations.
Advertisement
grrr...!!!

that's why I said 'or whatelse you do with your cpu'...
I know. I was talking about a first person shooter.

Ok, then nobody agrees with me when I say there are efficient engines and not so efficient engines?

What about Quake 3 ? For me it's the best example for an engine that's running unbelievably fast. I mean I write simple demos that run slower that this entire game. (which also takes care of other things in the background by the way)

Are you people soooo fair not to be able to say that some people can program the same thing faster that others?? I dont bel. it
Quote:Original post by Viper173
Using OpenGL, what do you think would be the 'best' solution to pass these information to the graphics card and still support compatibility for older cards such as GeForce 3 or 4???


ah, such are the times.. gf3+4 arent really old enough to worry about compatibility unless you feel like using fragment programs. vbo is supported by both and is usually the method of choice (though even that depends on what youre doing.. using vbo for a simple gui using 5 quads would be a) overkill b) not make any difference and c) be useless extra work to code).

also, you might want to ask yourself what the best order might be (sorted by what and with which priority).

and its good youre not asking, or might feel compelled to mention the 90fps i get with 500k polys with my terrain on a rad9800 (3 textures, no lighting, fillrate eating fog). still wont buy me anything because looking at it will become boring pretty quick. that and the "sane" settings have 50k at 350fps (so quite obviously the polys/second arent even linear within the same program, making it more than pointless to compare different programs by that). as you can see, all that these numbers are good for are bragging ,-)
f@dzhttp://festini.device-zero.de
ok, now, Mr. Show Off!

That got me a little impressed!
How are you drawing 500k at 90 fps?
please tell me you are using opengl.
or are you simply kidding?

Ok, again!
Then you all made me quit comparing 3d engines.

But what about simple demos as discribed above.

like 500k tris terrain 3 text. and fog. and maybe even lighting

what's a good way to get it on my screen ? (w openGL of course)
Use VBOs, keep draw calls to a minimum (i.e. drawing 2000 tris in one batch rather than 2 tris in 1000 batches) and keep state changes to a minimum. That's the gist of it anyway, there's loads of different tricks/techniques etc out there. The 'OpenGL Performance Tuning' presentation on this page may be of interest. If you have a high speed net connection you may want to check out the video version linked to here.
Whoops that was me [smile] APs can't post links so here they are again:

Page with performance tuning presentation

Page with video of performance tuning presentation
hmmm, VBOs sound good.
Downloaded a demo from nehe which is running at 300 fps although its rendering 30000 tris. But what's the min. requirement for this feature?

There's not much of a difference between vertex arrays and the vbo method, is there?
Since I'm new to the idea of vertex arrays...is there a way to render terrain depending on what you see only? Let's say you have a hugh 1024 by 1024 map but you only wanna draw the region you see.
or, can you draw only parts of your entire array?

I know, I should go out there and read some papers on that but I simply wanna know how flexible the idea of arrays is. certainly your desired object has to be static, but do you also have to draw the entire object?
Quote:Original post by Viper173
hmmm, VBOs sound good.
Downloaded a demo from nehe which is running at 300 fps although its rendering 30000 tris. But what's the min. requirement for this feature?

VBOs are supported on TNTs and Radeon7xxx and up iirc.
A detailed list

Quote:
There's not much of a difference between vertex arrays and the vbo method, is there?

Both methods use arrays ;)
VBOs "just" add the VBO specific stuff on top of that.

Quote:
Since I'm new to the idea of vertex arrays...is there a way to render terrain depending on what you see only? Let's say you have a hugh 1024 by 1024 map but you only wanna draw the region you see.
or, can you draw only parts of your entire array?

A common way to achieve this is to split your terrain into several smaller chunks and render only those that are in the current view-frustum (frustum culling).
For rendering only parts of your array you would have to read up on index arrays/buffers, which can specify which vertices of a vertex array are drawn.
Quote:
I know, I should go out there and read some papers on that but I simply wanna know how flexible the idea of arrays is. certainly your desired object has to be static, but do you also have to draw the entire object?

(Almost) everything in a 'serious' renderer will be drawn using VAs or VBOs(/VARs/VAOs), so using them will certainly be a good idea. Your models don't even have to be static ;) Animation can be done in a vertex shader and you can also update your arrays in between two frames, though you should try to minimize this for the sake of good performance.
Thanx Iternal!

I can't wait until trying out those VBOs. The NeHe Tutorial isn't that hard either.

I think I will go for rendering smaller parts of my terrain rather than messing around with vertex indices.

What would be an intelligent resulotion for vbo objects though?
Entire terrain would be 500.000 tris but what about each vbo size?

thank you all for your support

This topic is closed to new replies.

Advertisement