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

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.

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.

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.

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.

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.

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 ?

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.

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 ?

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 ?

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 ?

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.

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