DisplayLists: 20% performance boost in MultiCubeBenchmark ;D

[Marvin Fröhlich]

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

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 ... and so easy. Enjoy

Marvin

[bohdan]

That's great! 

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?

[Marvin Fröhlich]

That's great! 

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?

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

Games published by our own members! Check 'em out!

[bohdan]

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.

Alright, now understand, thanks 

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.

Yep, sounds good to me 

[Amos Wenger]

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.

[Marvin Fröhlich]

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.

That's a pity . What about the MultiCubeBenchmark on your machine?

[Marvin Fröhlich]

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.

[Riven]

Simply nest your displaylists.

1   2   3   4   5   6   7   8   9

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:

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18

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);

[Marvin Fröhlich]

Simply nest your displaylists...

Cool Thanks for the hint. I'll implement this soon.

Marvin

[Amos Wenger]

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.

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.

Games published by our own members! Check 'em out!

[Marvin Fröhlich]

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

Marvin

[Amos Wenger]

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

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.

[Marvin Fröhlich]

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

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.

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.

[Amos Wenger]

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

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.

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.

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

[Amos Wenger]

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

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

[Marvin Fröhlich]

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

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 .

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

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

Marvin

[Amos Wenger]

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

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

I wasn't talking to you 
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.

[Riven]

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

[Amos Wenger]

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

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 ?

[Marvin Fröhlich]

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 ?

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

[c_lilian]

There is already an optimization used to auto-detect when geometries don't change (say, if after 10 frames nothing has changed, that part of the branch graph is optimized)

It would be nice to have the same feature with display lists : sometimes models just don't move for a while, and they could be promoted to DL (until they start moving again).

This adaptative feature could also be used to nest static DL when the whole group doesn't change for a while...

My 2cents comments

Lilian

[Marvin Fröhlich]

There is already an optimization used to auto-detect when geometries don't change (say, if after 10 frames nothing has changed, that part of the branch graph is optimized)

It would be nice to have the same feature with display lists : sometimes models just don't move for a while, and they could be promoted to DL (until they start moving again).

I already talked about this above. I'll do that. Thanks for the comment .

This adaptative feature could also be used to nest static DL when the whole group doesn't change for a while...

Yes. cool, too.

[c_lilian]

Ok, so this was my 1 cent... 

[Amos Wenger]

By the way I have a problem with your current display list implementation : I have about 200 shape3D which are actually animation frames. They are all sharedCopied for each unit instance and stored in a Vector<Group> and I add them to the scenegraph when it's their turn to be displayed.
The problem with display lists is that (I suppose) one display lists per shape is created... and I would instead one per geometry.. With the current implementation, memory usage go crazy and performance is worse than without display lists. See ?

[Amos Wenger]

c_lilian, great to see you again !    What are you currently up to ? 

There is already an optimization used to auto-detect when geometries don't change (say, if after 10 frames nothing has changed, that part of the branch graph is optimized)

Really ? How is it implemented.

[c_lilian]

Hi Amos, I'm working on Jack Flowers... currently on the "donkey kong" bonus level and boss fights...

Lilian

[Marvin Fröhlich]

By the way I have a problem with your current display list implementation : I have about 200 shape3D which are actually animation frames. They are all sharedCopied for each unit instance and stored in a Vector<Group> and I add them to the scenegraph when it's their turn to be displayed.
The problem with display lists is that (I suppose) one display lists per shape is created... and I would instead one per geometry.. With the current implementation, memory usage go crazy and performance is worse than without display lists. See ?

Yes, I see. I'll change that on the weekend. OK?

[Amos Wenger]

Hi Amos, I'm working on Jack Flowers... currently on the "donkey kong" bonus level and boss fights...

Lilian

OK. Have anything recently annoyed you in Xith3D and you would like to get it changed ? (Question is also for others users).

By the way I have a problem with your current display list implementation : I have about 200 shape3D which are actually animation frames. They are all sharedCopied for each unit instance and stored in a Vector<Group> and I add them to the scenegraph when it's their turn to be displayed.
The problem with display lists is that (I suppose) one display lists per shape is created... and I would instead one per geometry.. With the current implementation, memory usage go crazy and performance is worse than without display lists. See ?

Yes, I see. I'll change that on the weekend. OK?

OK. How do you think you're gonna implement it ?

[Marvin Fröhlich]

OK. How do you think you're gonna implement it ?

Well, since each Shape3D has exactly one Geometry, the DisplayList doesn't need to be switched to the Geometry. But the RenderPeer must check, if it is a shared copy and create or use the DL depending on this check.

[c_lilian]

OK. Have anything recently annoyed you in Xith3D and you would like to get it changed ? (Question is also for others users).

Well, I have stopped updating from CVS since Xith lost its 1.4 compatiblity (that stops at least 50% mac users from using it) so the changes don't bother me...

I'll try to get back to the main branch later, once my game is released.

Lilian