Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Prozak

3D Engine Acceleration Techniques

This topic is 5587 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, I''m trying to compile a list of ways in which a programmer can speed up the FPS of its engine. Currently I have: - Triangle Strips - Display Lists (OpenGL) - Binary Space Partioning - Frustrum Culling (?) - Octrees (?) - Quadtrees (?) there must be a few more ways, both in opengl and directx. Could you guys help me make this list a bit more comprehensive?

[Hugo Ferreira][Positronic Dreams]
Need [3D Artist] & [Sound Designer]
for small project. Contact me plz...

Share this post


Link to post
Share on other sites
Advertisement
Rather than "acceleration techniques" i consider most of those things you mentioned, quite standard.
For any rendering engine, you really need to break down the scene into tree distinct functions.
1. Spacial subdivion: (Octree, quadtree, BSP, ABT, etc) Divides the scene space up into sections that can be easily managed and tested against.
2. Culling: (frustum, Occlusion: HOM, PVS, PLP, cPLP etc) Handles checking if geometry is visible to the viewer. If it''s not visible, don''t render it. In this case, the check of visibility is far less than the actuall rendering of an object.
3. LOD: (CLOD, ROAM, GeoMipMap etc) Distance based tesselation of elements. The farther you move from something, the less detailed it needs to look.

Those three I consider standard for an engine. They are called "acceleration algorithms" but that''s only in contrast to, what i would suppose, poly soup rendering.

As far as the other things you listed, vArrays, Display lists, TriStrips, VAR, VAO, CVA etc.. Those I consider acceleration algorithms, mainly because they directly change the way you render your geometry, rather than the above 3 systems, which reduce the amount of geometry rendered. There''s practicly thousands of ways to speed up an engine, you have to sit down and pick an area specificly to speed up in order to get a detailed list.

~Main

==
Colt "MainRoach" McAnlis
Programmer
www.badheat.com/sinewave

Share this post


Link to post
Share on other sites
From what I noticed, the slower things, in OpenGL are alpha testing and [alpha] blending. So, try to avoid them, as much as possible
I implemented once frustrum culling, in my engine, and got a drastical 0% increase in the frame rate.. (even tho the polygon count decreasted by 60%) :D
Also, I tried some display lists once, but they actually slowed down(!!) the engine...


Height Map Editor | Eternal Lands | Fast User Directory

Share this post


Link to post
Share on other sites
funny. I added display list to my engine the other day
and got a 114% increase in frame rate...

I''m thinking about taking the Game
Institute
''s course on BSP Trees...

I think I could learn a lot from it...

[Hugo Ferreira][Positronic Dreams]
Need [3D Artist] & [Sound Designer]
for small project. Contact me plz...

Share this post


Link to post
Share on other sites
i''ve found that with HW T&L that LOD doesn''t really help much except the most simple types of LOD like geomipmapping/LOD involved with a LOT of geometry (terrains). using LOD meshes on little things seems to be slower than just drawing it.

of course, it might have been my crappy mesh programming as well.

Share this post


Link to post
Share on other sites
-View Frustrum Culling via Spatial Subdivision (any kind of tree, portals...)

-Occlusion Culling (remove invisible objects which are in the frustrum)

-Indexed primitive, they are very cache friendly. (Triangles, or strips)

-Front To Back Sorting up to 600% increase in performance compared to Back To Front, while Random is just 180% perf increase.

-Alpha Testing way faster than Alpha Blending but not always usefull.

-Some form of geometry reduction, depending on your poly count.
(with a mid-low poly count that won''t be that needed)


Prefer to remove what''s invisible than reducing poly count to compensate for failing to remove invisible objects.

-* So many things to do, so little time to spend. *-

Share this post


Link to post
Share on other sites
could u give a brief description of each of these methods,
for those of us now trying to further developed their engine
with more advanced methods?

thanx,

[Hugo Ferreira][Positronic Dreams]
Need [3D Artist] & [Sound Designer]
for small project. Contact me plz...

Share this post


Link to post
Share on other sites
quote:
Original post by Raduprv
I implemented once frustrum culling, in my engine, and got a drastical 0% increase in the frame rate.. (even tho the polygon count decreasted by 60%) :D
Also, I tried some display lists once, but they actually slowed down(!!) the engine...


It's likely that your app was framerate-limited (i.e. framerate was the bottelneck, rather than geometry processing). If an app is framerate-limited, than two rules apply (among others):
1. Reducing the amount of rendered geometry won't speed thigns up (and increasing it won't slow things down - that is, until the app becomes geometry-limited).
2. Since display lists tend to require quite a bit of fillrate (or smt like that), they're likely to decrease performance (depends on the actual situation, e.g. it may depend on the amount of memory needed to store the display list).

As a general rule, you should always identify your bottleneck(s) first, and then deal with them accordingly. There are whole papers on this at NVIDIA's and ATI's developers pages.

A few techniques of the top of my head:
1. If possible, make sure all your geometry is made of indexed, vertex-cache-friendly triangle strips (triangle lists will also be fine, if AGP bus bandwidth is not much of a concern). See this paper.
2. Silhouette clipping is a great way to reduce geometry without sacrificing visual quality (almost).
3. Whenever possible, make sure the relevant geometry and textures are in video memory.
4. Don't use any textures that are bigger than the minimum that is necessary to acheive the desired visual quality.
5. Don't use more texture units than you need. In particular, you may want to turn off detail maps where they're too far to contribute much (although you shouldn't bother doing this if you're not fillrate-limited).
6. Make sure all irrelevant fragments get discarded as early as possible in the pipeline. Use depth-testing (with rough front-to-back sorting), stencil-testing, and whatever else is relevant to acheive this.
7. Minimize expensive state changes.
8. Strive for maximum GPU/CPU concurency.
9. Put as much work as possible on the GPU, and as little as possible on the CPU (you'll need the CPU for physics etc.). However, if after all non graphical work is done, your CPU is "underemployed", consider moving some of the load onto the CPU, to free the GPU for more geometry/fragment processing.
10. Don't simulate cloth, particle systems, and similar if they're not visible.
11. If you can pipeline some expensive CPU-bound process, do so, and use a separate thread for each stage.

Yann, I think you can contribute a lot to this thread...


Michael K.,
Designer and Graphics Programmer of "The Keepers"



We come in peace... surrender or die!

[edited by - technobot on March 6, 2003 4:01:43 PM]

Share this post


Link to post
Share on other sites
My problem is that my engine is isometric, so I don''t need most of the culling techniques, since I kind of know what is visible and what not, what is supposed to be in front of something else, etc...
But, still, after trying all the optimizations I can think of, I am unhappy with the frame rate. I mean, seen some other 1st/3rd person engines (which are supposed to be slower), but they are actually faster, and more detailed... That, or people lie about their FPS :D

Height Map Editor | Eternal Lands | Fast User Directory

Share this post


Link to post
Share on other sites
Well, most acceleration techniques are based upon the assumption that there''s stuff you don''t want to render beacuse it costs to much on the card. For Iso engines etc, the checks to determine visibillity cost MORE than actually rendering the geometry. In those cases, the best place to speed up your algorithms is in design of the engine. Go through and re-consider your structures, how many checks are you doing, rewrite your hit collision, divide different operations between frames, rather than every frame, etc etcc etc.

FPS push a lot of polies, therefore those checks to determine visibility save TONS in relation to rendering all those extra textured, lit, shaded polygons.

Now, if a given FPS scene is rendering the same amount of polies as one of your ISO scenes, and you''re still slower, well, rework the engine my friend, rework the engine.

~Main

==
Colt "MainRoach" McAnlis
Programmer
www.badheat.com/sinewave

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!