DisplayLists: 20% performance boost in MultiCubeBenchmark ;D

Engines, Libraries and Tools Xith3D Forums
#1

What did you say about the focusing problems, Amos? I had some today :wink:

I read through some webpages and gathered information about DisplayLists, and found it really easy. So I added about five or six lines to ShapeAtomPeer and an additional flag to ShapeAtom holding the DisplayList’s name and a new flag to Shape3D telling if it is a dynamic or static shape. This flag can be set either through the constructors or a getter/setter. That’s it.

I set the cubes in MuliCubeBenchmark to STATIC and the whole thing was running 20% faster (36 FPS before, 44 after on my machine).

This is really awesome ;D ;D ;D 
 and so easy. Enjoy ;D

Marvin

#2

That’s great! ;D

Maybe stupid question, but
 what conditions should be met to safely consider Shape3D to be a STATIC?
Is anything at all can be changed for that Shape?

#3

Well, the game won’t crash, if you change any of the shape’s properties including the Appearance’s ones, but it won’t have any visible effect, if you change a property after the first frame. So in other words: A Shape3D is considered to be static, when you’re not planning to change any of it’s properties. Of course you may translate, rotate or scale it using a TransformGroup
 no problem.

I’m currently thinking about refreshing the static shape’s display list when a property has changed. I’m also planning to add a third type called “AUTO”. With this type the renderer looks for modifications on the shape and if nothing has happened to the shape’s properties for a certain amount of frames, the shape’s type is automagically switched to STATIC (just as Amos suggested). This would be a good default. Maybe a static flag on the Shape3D class would then make sense, telling if this automatic switch should be performed.

Marvin

#4

Alright, now understand, thanks :slight_smile:

Yep, sounds good to me ;D

#5

The performance gain is hardly noticeable on my config. Must be due to another thing : it appears that data transfer from RAM to VRAM isn’t the bottleneck here.

#6

That’s a pity :(. What about the MultiCubeBenchmark on your machine?

#7

In scenes with many small Shape3Ds (like a bsp level) there would be useful a more general display list, shich draws some shapes at once. But this would be very much harder to implement. And I can’t forsee, how big the boot would be with it.

#8

Simply nest your displaylists.

glNewList(..., GL_COMPILE);
for(int i=0; i<4; i++)
{
   glPushMatrix();
   glTranslatef(..., ..., ...);
   glCallList(...);
   glPopMatrix();
}
glEndList();

You can nest up to roughly 64 levels.

The nice thing is the reference to the nested list is like a pointer, the nested lists are not inlined.

So you can do something like this:

glNewList(..., GL_COMPILE);
for(int i=0; i<4; i++)
{
   glPushMatrix();
   glCallList(n*2+0); // reference to DL that translates 
   glCallList(n*2+1); // reference to GL that renders geometry
   glPopMatrix();
}
glEndList();

// later: move your embedded object
glNewList(itemIndex*2+0, GL_COMPILE);
glTranslatef(x, y, z);
glEndList();


// render your scene
glCallList(sceneHolder);
#9

Cool :slight_smile: Thanks for the hint. I’ll implement this soon.

Marvin

#10

IMO, display lists should be bound :

  • To Geometry(s)
  • To Shape3D(s)
  • To Shape3DList(s)
    Shape3DLists(s) display list call Shape3D(s) display lists which calls Geometry(s) display lists.
    Which mean with a Shape3DList containing everything in the Quake3 level you have only one display list, which means huge performance boost.
#11

The Shape3DList could be named StaticGroup and could extend Group. What do you say?

Marvin

#12

No. A group is a list of nodes. The nodes are rendered independently by a renderer.
A Shape3DList should be a node as it has one RenderAtom/Bin/whatever.

#13

Well, this List would be handled like a group, since it has be capable of containing Shape3D Nodes. So why don’t extend a Group? The FrameAtomsCollector (or it’s succesor) must handle it correctly.

#14

Yeah BUT it wouldn’t be efficient because it would create/use one RenderAtom by Shape in the list
 Or am I wrong ?

#15

Note : should YOU, guest, have a better idea, please post it.

EDIT : http://radioblogclub.com/open/114238/better_way/Ben%20Harper%20-%20Better%20way ;D ;D ;D

#16

Ah! Now I see. Yes, you’re right. It would be possible to do that for a group, too. It is just the way the atom collector handles the thing. But it is more logic the way you suggest ;).

???

??? ??? ???

Marvin

#17

I wasn’t talking to you ;D ;D ;D
Sometimes, highly talented individuals not using Xith3D (like Riven/kevglass) fly across Xith3D forum boards. I was just saying that if they’d have a better idea, they are welcome to post it.

#18

The only problem is that displaylists are great in theory! I never used them that way, so you may be surprised with the results, although I highly doubt there are showstoppers here.

Isn’t this almost the best way to implement the currently empty(?) BranchGroup(??).compile() method?

Just iterate over the entire sub-graph and copy the structure in your displaylists

#19

BranchGroup is not meant to be used outside of being a “branchgraph” in Locale.
There was a compile method. We removed it some time ago because it wasn’t used. Maybe we can implement it. Marvin, would you do that ?

#20

Well, I’m not really sure if this actually makes sense. I think, the Shape3DList idea is just enough. When you’re building up the scenegraph, you’ll know which subgraphs are absolutely static (even if a subgraph means one with onle a single shape). And you can set the appropriate shape types.

Anyway, the Shape3DLists will have to wait until after the RenderBin thing, because there’re things, I need to check first to get the Shape3DList working. And these things need to be checked anyway for the RenderBin thing.

I’ll start doing this on saturday.

Marvin