Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (480)
Games in Android Showcase (110)
games submitted by our members
Games in WIP (546)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  DisplayLists: 20% performance boost in MultiCubeBenchmark ;D  (Read 5947 times)
0 Members and 1 Guest are viewing this topic.
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Posted 2006-09-21 22:28:19 »

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

Marvin
Offline bohdan

Junior Member




Java-positive...


« Reply #1 - Posted 2006-09-23 23:55:19 »

That's great!  Grin

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?
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #2 - Posted 2006-09-24 00:37:59 »

That's great!  Grin

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!
Legends of Yore - The Casual Retro Roguelike
Offline bohdan

Junior Member




Java-positive...


« Reply #3 - Posted 2006-09-24 16:31:42 »

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  Smiley

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  Grin
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #4 - Posted 2006-09-25 16:23:05 »

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.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #5 - Posted 2006-09-25 17:38:05 »

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 Sad. What about the MultiCubeBenchmark on your machine?
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #6 - Posted 2006-09-25 17:40:08 »

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.
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 781
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #7 - Posted 2006-09-26 10:27:53 »

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

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #8 - Posted 2006-09-26 18:02:56 »

Simply nest your displaylists...

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

Marvin
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #9 - Posted 2006-09-26 18:07:04 »

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.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #10 - Posted 2006-09-26 18:11:23 »

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

Marvin
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #11 - Posted 2006-09-26 18:12:09 »

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.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #12 - Posted 2006-09-26 18:14:52 »

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.
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #13 - Posted 2006-09-26 18:20:46 »

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 ?

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #14 - Posted 2006-09-26 19:58:00 »

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

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

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #15 - Posted 2006-09-26 21:27:12 »

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 Wink.

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

Huh


Huh Huh Huh

Marvin
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #16 - Posted 2006-09-27 13:45:31 »

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

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 781
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #17 - Posted 2006-09-27 18:10:50 »

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

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #18 - Posted 2006-09-28 15:57:30 »

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 ?

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #19 - Posted 2006-09-28 16:07:56 »

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
Offline c_lilian

Senior Member


Projects: 1


Java games will probably rock someday...


« Reply #20 - Posted 2006-09-28 16:24:16 »

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 Smiley

Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #21 - Posted 2006-09-28 16:31:00 »

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 Wink.

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

Yes. cool, too.
Offline c_lilian

Senior Member


Projects: 1


Java games will probably rock someday...


« Reply #22 - Posted 2006-09-28 16:34:07 »

Ok, so this was my 1 cent...  Grin

Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #23 - Posted 2006-09-28 16:44:29 »

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 ?

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #24 - Posted 2006-09-28 16:46:18 »

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

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.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline c_lilian

Senior Member


Projects: 1


Java games will probably rock someday...


« Reply #25 - Posted 2006-09-28 16:58:37 »

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

Lilian Smiley

Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #26 - Posted 2006-09-28 17:01:45 »

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?
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #27 - Posted 2006-09-28 17:15:04 »

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

Lilian Smiley
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 ?

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #28 - Posted 2006-09-28 17:26:35 »

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.
Offline c_lilian

Senior Member


Projects: 1


Java games will probably rock someday...


« Reply #29 - Posted 2006-09-28 18:54:53 »

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 Smiley


Pages: [1] 2
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

atombrot (23 views)
2014-08-19 09:29:53

Tekkerue (22 views)
2014-08-16 06:45:27

Tekkerue (21 views)
2014-08-16 06:22:17

Tekkerue (12 views)
2014-08-16 06:20:21

Tekkerue (19 views)
2014-08-16 06:12:11

Rayexar (57 views)
2014-08-11 02:49:23

BurntPizza (37 views)
2014-08-09 21:09:32

BurntPizza (29 views)
2014-08-08 02:01:56

Norakomi (36 views)
2014-08-06 19:49:38

BurntPizza (66 views)
2014-08-03 02:57:17
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!