Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (498)
Games in Android Showcase (114)
games submitted by our members
Games in WIP (563)
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  
  Renderer design  (Read 4837 times)
0 Members and 1 Guest are viewing this topic.
Offline DavidYazel

Junior Member




Java games rock!


« Posted 2003-07-06 01:46:56 »

I wasn't sure where to post this, so forgive me if this is the wrong place.

I have completed my first pass at a renderer traversing a Java3d standard scenegraph.  Not all nodes are implemented, but most are.  This toy renderer traverse the scene and uses LWJGL opengl calls in place.  Simple scenes are very fast and as expected this drops off fast as the complexity increases.

Now that things seem to be working smoothly I am designing a better rendering pipeline and wanted to see if it seems to make sense.

One of the things you gain when traversing a scenegraph is that you can use the opengl matrix stack to handle your transformations.  The problem with that the scenegraph is really there to support the logical view of the data and is not optimized for rendering.  I need to re-order the way that geometry is sent to the card so that I can minimize state transfers.

So my basic idea is to do the following:

1. Traverse the scene and for transform groups I would calculate the local to vworld transform, multiplying them down the tree.  I would only recalculate this if the transform or a parent transform has been marked dirty through a change since the last render.

2. As I got to nodes I would translate their bounding spheres using the nodes local to vworld transform.  This would shift the node bounds in the SphereTree (extremely efficient for making changes).  

3. Traverse the sphere tree and perform frustum culling, skipping any nodes which are outside frustum planes.  Keep track via stacks the current states.  So if I hit a fog node that is good from that location down, I would push the fog node on the fog stack.  When I come back up through the node I would pop it off.

4. When I got to a node that is to be rendered I would package it up with its shaders ( current state of appearance + fog + lights, etc).  This would push a package on the render bin which had everything needed to render.

Some nodes can also be view specific geometry generators, including BSP generators which can produce their own packages for rendering.  These would be triggered and they would produce shader+geometry packages into the render bin.

5. Special nodes called shadow occluders can be added by users into a branch group to represent the occluder for the "model" which exists below it in the scenegraph.  These are pushed into a special queue in the renderer.  The geometry can be supplied for the occluder, or it can be built on the fly (and cached) from all the geometry which exist in descending nodes.

6. Some of the packages which are placed into the render bin can contain other packages.  Examples of this are decal groups and order groups.

8. The render bin is sorted by shader constitutions to minimize the state changes.  Transparent shaders and thier nodes are placed into a second bin for a later pass.

9. Render bins are submitted to the geometry pipeline which: 1) steps through each package, changes only the delta state (including doing a glLoadMatrix for the transform if there is a change)  2) manages vertex arrays + texture bindings 3) renders geomtry.

10. The first pass would be the opaqe render bin, then each package container (ordered groups, decal groups) would be sorted and sent to the geometry pipeline.

11. Shadows would rendered using zbuffer shadow volumes (carmacks reverse zpass/fail)

12. The transparent package bin is then processed.  Specially flagged packages would be combined and broken up by polygons into mini-chunks.  Regular packages will be added in their larger chunks.  This bin is then sorted by distance to the view and submitted to the geometry pipeline.

13. Last step would be to render overlays.

I also plan to add more advanced shaders than just the standard appearance.  Packages flagged for dynamic per-pixel lighting can have their vertex colors encoded on the fly with the light vector so we apply 3d lightmaps + bump + cubemap normalizer, etc.


I am designing this to be generic as possible with plugins into the rendering pipeline and graphics pipeline to allow different techniques to be used.  It should be also possible to add in a occlusion culling plugin so that different techniques (e.g. Zhang's hierarchical z pyramid) for late pipeline checking or even an early pipline PVS check.

Are there any glaring holes in the basic outline I have described?  

Once this engine is done (good enough to run Magicosm on) I will release it for any use and eventually open it up for other developers to contribute.  At worst it should be an example others can learn good and bad things from.

David Yazel
Xith3D Project Founder
http://xith3d.dev.java.net

It may look complicated, but in the end it is just a bunch of triangles
Offline kevglass

JGO Kernel


Medals: 164
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #1 - Posted 2003-07-06 04:44:19 »

From the little I know, I read through, and nothing jumped out.

Just like to say thanks for going to this trouble, and better still keeping the "community" involved. Really looking forward to seeing the new screenshots of COSM based on your new renderer.

Kev

Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #2 - Posted 2003-07-06 08:18:05 »

All waaaay over my head...

Cas Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline abies

Senior Member





« Reply #3 - Posted 2003-07-06 09:32:19 »

I have just pressed reset during typing this and I had to retype..... grrrrr.

Here is my render-order list:

1  
2  
3  
4  
5  
6  
7  
8  
1.Init frame time/number
2.Clear buffers
3.Priority behaviors running (input/camera), update camera and frustrum
4.Secondary behaviors running (fill dirty transform/bound nodes), perform auto-bounds geometry updates, schedule manual-bounds geometry updates
5.Recompute dirty transforms and bounds (hierarchy-traversal)
6.Cull nodes and fill to-draw list (hierarchy-traversal)
7.Sort to-draw list, opaque, transparent-order-indep, transparent-order-dep (list-traversal)
8.Perform manual-bounds geometry updates and draw sorted to-draw list in parallel (list-traversal)


I have not looked at shadows yet, so it is not included. Generally, order is similar - there are only few ways to do a scenegraph renderer. From what I see, main thing missing from your list is behavior/geometry update handling. On one hand, you need to process geomety updates early to be able to use new bounds for culling, on other hand, you want to parallelize it with rendering to not starve the GPU.

I'm thinking about two tricks here:

1) Split priority and secondary behaviour. Only priority behaviours can modify the view/camera - but they are run always, regardless of distance/frustrum. On the other hand, secondary behaviours can be distance/frustrum dependent (and this culled) - but camera is already set in stone.

2) Splitting manual-bounds-compute and auto-bounds-compute geometry updates. With mbc I will require code to set possibly updated bounds in behavior, well before geometry update itself is executed. In most cases, bounds will be set big enough at start and not modified later I suppose. This will allow to perform geometry updates parallel with rendering, using some kind of fences (if they will be needed at all). On the other hand, abc needs to be updated before occlusion culling, because new bounds need to be calculated and used there (to avoid culling of objects that had grown during update and should be visible). Anyway, I do not expect anybody (this means me) to use dynamic geometry with auto-bounds-compute Smiley


The biggest problem is state sorting. Identical appearances can be put together - but what with ones which are a bit different ? Texture changes are probably most expensive - but what with geometry changes ? Reusing already loaded vertex buffer can be also a big gain. If we have same geometry/appearance, in what order rest of changes should be put ? Is it really worth to sort it in complicated way for anything except textures/geometry ? Texture sorting is also non-trivial - it would be great to detect that only 1 texture unit has changed, while rest stay the same and cluster such objects, as opposed to looking at all textures at once.


I'm considering following trick - maybe you will find it useful. Each appearance component will implement following interface
1  
2  
3  
4  
public interface StateAttributes
{
    public void makeCurrent(RenderingContext ctx, StateAttributes previous);
}

On state change, renderer will call makeCurrent on any of appearance components which has changed compared to last state. Every component will also have 'default' object. So, for example, turning on custom PointAttributes will look like this

customPA.makeCurrent(ctx,defaultPA);

changing them to different ones

otherPA.makeCurrent(ctx,ctx.getState().getPointAttributes());

and going back to default

defaultPA.makeCurrent(ctx,ctx.getState().getPointAttributes());


Inside PointAttributes, code can look like this (I type it from head, so there can be some errors)

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
public void makeCurrent(RenderingContext ctx, StateAttributes previous)
{
  GL gl = ctx.getGl();
  PointAttributes old = (PointAttributes)previous;
  if ( old.getSize() != getSize() ) {
    gl.glPointSize(getSize());
  }
  if ( old.isAntialised() != isAntialiased() ) {
    isAntialised() ? gl.glEnable(GL.GL_POINT_SMOOTH) : gl.glDisable(GL.GL_POINT_SMOOTH);
  }
  ... same for attenutation/fade/minsize/maxsize
}


There will be also methods for comparing states inside StateAttributes, but I have no idea at the moment how it should exactly work. I'm thinking about returning signed weight of required changes, which would be later mutliplied by constant for given StateAttribute and directly used for sorting - but it is not trivial to describe such function so it will stay bidirectional.

Artur Biesiadowski
Offline William

Junior Member




No Exit


« Reply #4 - Posted 2003-07-07 08:37:11 »

I would just like to add that I think it's great that you're doing this, David, and I'm looking forward to the public release. This provides a much-needed direction in the vaccum that has been created by the freeze of Java3D and the uncertainty of what might come on top of JOGL.
Offline DavidYazel

Junior Member




Java games rock!


« Reply #5 - Posted 2003-07-07 11:45:12 »

Thanks for everyone's feedback!  Over the long weekend I wrote the skeleton based on the new design.  One improvement over what is above is that I seperate the renderer layer into two pieces, with the bottommost being 3 interfaces RenderPeer, ShaderPeer and RenderAtomPeer.  Implementations of these interfaces should be the only places where pure 3d API calls are actually going to be made.  This "should" allow the bottom layer to be LWJGL, JOGL or even Java3D (immediate mode).  You can create a new Shader by implementing the Shader interface and the ShaderPeer interface and then registering the two in the renderer.

Another optimization I have worked in is something called a StateMap.  StateMaps can be used by shaders and other discrete renderable items to create a uniqe map of instances.  For example when a RenderAtom comes in, and before it is sorted in the RenderBin, it is processed with StateMappers.  So when the AppearanceShader is processed, it in turn processes its NodeComponants (material, rendering attributes, etc) by passing them to the corresponding StateMap.  The statemap holds a balanced tree where the key is the actual StateTrackable items (which are comparable).  The first time we encounter a new StateTrackable a StateNode is placed into the tree.  The state node contains a unique id, a reference count and a pointer to a copy of the StateTrackable item.  The StateTrackable item is then flagged with the StateNode so that the netx time it is seen (if it is not dirty) there is no reason to look it up.  This means that from that point forward sorting is done on the state id, not on the state contents.  This is also nice for the final rendering stages since it can keep track of the current context only using the id's and change state only when the id's change.

When an identical material (but different instance) is checked against the tree it will find a match and then it will be flagged with the state node.  The next time it comes in to be processed, if it is not marked as dirty it will retain the prior assigned StateNode and therefore keep the same id.  So for 99 percent of the time the state id's will be the same and for that matter many entire render bins will remain the same, allowing us to exploit frame to frame coherency.

Anyway things are cruising along so far, no major problems so far.

David Yazel
Xith3D Project Founder
http://xith3d.dev.java.net

It may look complicated, but in the end it is just a bunch of triangles
Offline Herkules

Senior Member




Friendly fire isn't friendly!


« Reply #6 - Posted 2003-07-07 13:41:28 »

Do you retain some Java3D compatibility?

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline DavidYazel

Junior Member




Java games rock!


« Reply #7 - Posted 2003-07-07 15:17:35 »

One thing we want to make clear is that we are building a gaming version of the Java3d API, not a pure port.  Java3d is a wonderfully rich and powerful scenegraph which can meet many different needs, from scientific visualization to cad/cam, etc.  With this generality comes a cost however.

So we have quite a lot of compatibility with the Java3d API. (BTW is it legally allowed to use the same method signatures, etc or do they represent protected informaiton?)  We are trying to minimize the work in porting from Java3d to our engine.  So all the familar scene graph nodes are there, etc.

But we are concentrating on rendering in particular.  This first version will have no behavior support for example.  

The biggest change architecturally is at the top of the scene.  We are doing away with view platform and attaching the view transformation right to the view.  

We are also, for the sake of performance, making the scenegraph non-reentrant (non thread safe).

So the way it works is:

1. Read Inputs
2. Update scenegraph
3. Render scene
4. Goto step 1.

Now the "render scene" part does not include waiting for OpenGL to finish, but represents that all the RenderAtoms have been sent to the OpenGL driver through the low level API.

By using this approach we do not need the famous "retained" copy stored along side the scene.  Also it allows for geometry generators (like BSP) to generate in-line rather than building a geometry array and sending it to be processed.

For our purposes we will not be using AWT or Swing at all, giving us the fastest flat out speed we can do (hopefully).

David Yazel
Xith3D Project Founder
http://xith3d.dev.java.net

It may look complicated, but in the end it is just a bunch of triangles
Offline Breakfast

Senior Member




for great justice!


« Reply #8 - Posted 2003-07-08 08:07:35 »

I'm really glad you are doing this- from what I can tell you probably know a good deal more about using Java3D for games than anyone. As soon as it gets down to the level where I have some chance of being useful I'll be more than happy to offer any assistance I can Smiley
Offline Herkules

Senior Member




Friendly fire isn't friendly!


« Reply #9 - Posted 2003-07-08 08:50:23 »

The renderer design looks OK for us, we only use one single behavior now to drive the whole game. This could easily be achieved with a gameloop as well.

LWJGL would be of little interest due to it's restrictions, JOGL would be the choice.

But more important: we should try to motivate the authors of the loaders to port their stuff. Without loaders (in our case John Wrights 3DS loader), the gap between artwork and game still is quite big.

BTW, David, I'm deeply impressed by the speed you make things happen and how people are willing to follow.


HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline abies

Senior Member





« Reply #10 - Posted 2003-07-08 10:14:27 »

I'm trying a bit different route than David, but maybe it is worth considering as far as loaders are concerned. I have defined umpteen interfaces for scenegraph objects, plus few factories for creating them. All the rest of internals are hidden inside implementation classes. In theory, it should allow to write generic loader which would work with any renderer implementing these interfaces. I'm trying to design them in way they are not really dependent on underlying structures.

Do you think it would be possible to agree on some kind of interfaces which would abstract specific renderer details ? I'll try to post my proposal later today, to have some base to comment on.

Artur Biesiadowski
Offline Herkules

Senior Member




Friendly fire isn't friendly!


« Reply #11 - Posted 2003-07-08 10:41:06 »

Hm, renderer and loaders should have no contact anyway. There is the engine (scenegraph) between them.

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline shawnkendall

Senior Member





« Reply #12 - Posted 2003-07-08 11:46:03 »

Great progress, sorry I've been out, was away for a week on vacation! :-)

We are still doing similiar development, and similarly plan to release something working when we have a decent demo.
After that we will probably rework what we have and perhaps can come to a more common approach for the scene graph renderer with the community.

So far, your description sounds quite good, if not overbuilt for how we would like to see a renderer.
We are going for a more modular approach, for example, a simple drawlist system that suports adds/caches/inserts based on an render attribute hash or similar, and then a simple loop to render single transform objects, and allows for shader execution, as well as various other "pieces".
The traverser walks the graph, flatten transform stacks and doing sphere bounds culling as well but does not use OGL push and pops since it's output will be flattened transforms and geometry data (classic graphics object)  into the draw list.
The drawlist renderer will push and pop any object the has a transform but never works on a hierarchy.  This avoids any issues that the 32 max transform stack can have in OGL.  It also allows any other drawlist generation system to be used instead of a graph traversal, etc.

We want to create a render toolkit as opposed to a render "engine" so it can be assembled rather than inherited or rewritten to do app specific render execution.

Still, the discussion is great!

Shawn Kendall
Cosmic Interactive, LLC
http://www.facebook.com/BermudaDash
Offline bmyers

Junior Member





« Reply #13 - Posted 2003-07-08 15:05:12 »

Keep it up, David and Shawn and abies!  Although, personally, I am of two minds on this discussion:

Mind #1:  I am really happy that there's several groups who are all working very hard on filling the void left by the Java3D "stall".

Mind #2:  I am disappointed that there's now going to be at least 4 (at last count) different scene graph APIs that are all somewhat incompatible with each other and with Java3D.

One of the big reasons our team went with Java3D in the first place was because it was a standardized API that people could add content-specific modules to (e.g. Loaders), and I didn't have to worry about how compatible they were, and how much work I would have to throw away.  Plus I knew it was supported by Sun.  Now it looks like a bunch of re-work might be coming in the near future.

Oh, well... :-/

Currently, most of our 3D programming work is on the back burner while we wait for the 3D scenegraph API shuffle to settle out.  We're mostly working on the AI system and the 2D stuff in the meantime, which for our game is just as important as the 3D stuff.

Question for Dave:
Are you using joal and jinput, or are you using a different set of packages for audio and input?  Or is that something that is up to the user to hook in?  thx!

Offline shawnkendall

Senior Member





« Reply #14 - Posted 2003-07-08 15:17:19 »

Quote
Keep it up, David and Shawn and abies!  Although, personally, I am of two minds on this discussion:

Mind #1:  I am really happy that there's several groups who are all working very hard on filling the void left by the Java3D "stall".

Mind #2:  I am disappointed that there's now going to be at least 4 (at last count) different scene graph APIs that are all somewhat incompatible with each other and with Java3D.

One of the big reasons our team went with Java3D in the first place was because it was a standardized API that people could add content-specific modules to (e.g. Loaders), and I didn't have to worry about how compatible they were, and how much work I would have to throw away.  Plus I knew it was supported by Sun.  Now it looks like a bunch of re-work might be coming in the near future.

Oh, well... :-/


I believe that the developers of the J3D-like renderers/systems understand this completely.
We are trying to make sure that the renderers will be abel to operate on a J3D compatible graph so as much existing loaders, etc will still be usable, and that replacement/intergration with existing game apps will be as smooth as possible.
It is true, if you use ALLOT of J3D's other functionality (picking, collision, behaviors, sound) then you will probably not be able to switch anytime soon.
However, as more projects face this, I imagine(hope!) that those pieces may start to appear as well.

Personally, we only used the renderer of J3D in all our projects and less and less of the other features each later project.  Most people wrote their own collision support, and  the behavior model was always a problem, most only used the WakeOnFrameElapsed(0) which will port easy to our renderers.

But keep on voicing those opinions to keep us all on track!

Shawn Kendall
Cosmic Interactive, LLC
http://www.facebook.com/BermudaDash
Offline bmyers

Junior Member





« Reply #15 - Posted 2003-07-08 16:21:56 »

Quote


IIt is true, if you use ALLOT of J3D's other functionality (picking, collision, behaviors, sound) then you will probably not be able to switch anytime soon.
However, as more projects face this, I imagine(hope!) that those pieces may start to appear as well.

Personally, we only used the renderer of J3D in all our projects and less and less of the other features each later project.  Most people wrote their own collision support, and  the behavior model was always a problem, most only used the WakeOnFrameElapsed(0) which will port easy to our renderers.


We are using picking and lots of of behaviors which would all have to be merged into one big uber-behavior if we were try to port now.  We're also using Java3D sound, but have had so many problems with it that it's turned off right now.

Our problem is that our game is in many ways a data visualization game (read: simulation/strategy), which is what Java3D is really well suited for.  So it's made sense for us (so far) to use it as it was originally intended, which means using behaviors extensively, especially DistanceLOD and various Interpolators, as well as our own custom behaviors.

I can't imagine that I'm the only one in this boat -- there must be other people using behaviors  Huh

Quote

But keep on voicing those opinions to keep us all on track!


Oh, I will!   Grin

Offline shawnkendall

Senior Member





« Reply #16 - Posted 2003-07-08 16:39:21 »

I will comment on the use of LOD behaviors in Java3D...

It is a nice convenence that J3D has LOD behaviors hanging in the scene graph.  It makes much of the operations transparent, as a loader and model can be made to set up the LODs and off they go.

However, this localized approach has many cons, and in most games is often overwritten to be controlled at a higher level by some sort of game manager.

For example, what if you decide you would like to modifiy all LODs to switch at a later distance for lower requirement hardware?
Or perhaps you have a terrain system that knows about the view changes at a higher level, so there is no need to recompute each LOD distance every frame, but only when the viewer is moved across a tile barrier(LOD checks can add up).
Or what if you wish to use a Cell and Portal style viewing system.  That type can cut of completely large portions of a scene graph, but the behaviors have to be managed as well, and if oyu are cutting them on an off from large object lists, or travsing the graph to find them, you might as well control them directly IMHO.

These are the kind of things that are difficult at best to do with the localized behavior system in J3D (or any behavior object supporting scene graph).


Shawn Kendall
Cosmic Interactive, LLC
http://www.facebook.com/BermudaDash
Offline shawnkendall

Senior Member





« Reply #17 - Posted 2003-07-08 16:44:35 »

On picking...

I meant to say this earlier, but we do not use the pickign utils except in tools.  In profiling they are shown to be fairly inefficient but most important they generate allot of garbage objects.  They are more of an example of how to do picking althought they are generally complete.'

In any case, they are open source and could be recompiled/ported to work on the new graphs (provided the graphs reach that depth of compatiblity) as is so I imagine you will be ok there.

Our viewer using them, so our graph will have to work with them.  In fact, I think that is a good test of compatibility

Shawn Kendall
Cosmic Interactive, LLC
http://www.facebook.com/BermudaDash
Offline abies

Senior Member





« Reply #18 - Posted 2003-07-08 17:52:33 »

Quote

I can't imagine that I'm the only one in this boat -- there must be other people using behaviors  Huh


Yes, some of them are Smiley
I have used behaviours in NWN model loader for implementing particles/emitters and animation. For me, it is an example that even loader (not core game itself) needs some kind of support for behaviours - after all, there is only a limited set of things you can do with static data.

Artur Biesiadowski
Offline bmyers

Junior Member





« Reply #19 - Posted 2003-07-08 19:34:50 »

Quote

For example, what if you decide you would like to modifiy all LODs to switch at a later distance for lower requirement hardware?
Or perhaps you have a terrain system that knows about the view changes at a higher level, so there is no need to recompute each LOD distance every frame, but only when the viewer is moved across a tile barrier(LOD checks can add up).
Or what if you wish to use a Cell and Portal style viewing system.  That type can cut of completely large portions of a scene graph, but the behaviors have to be managed as well, and if oyu are cutting them on an off from large object lists, or travsing the graph to find them, you might as well control them directly IMHO.

These are the kind of things that are difficult at best to do with the localized behavior system in J3D (or any behavior object supporting scene graph).


Well, we're not doing any of those things...  Wink

Although it's probable that we would change LOD distances based on hardware or user preference, so you have a good point there...

For terrain we have about 1500 static shapes, each of which has an associated DistanceLOD, and Java3D seems to handle it perfectly well.

We also have a lot of LODs for the units, however (potentially several 1000's), so maybe that is pretty inefficient and could (will) be redesigned.  But we don't move by tile boundaries, and we have vertical altitude as well as changing horizons (because we're dealing with spherical planets) to deal with, so the distance calculation from the view would still need to be made for each unit, if the unit is inside the visible distance, although I guess if we wrote our own LOD-manager we could use L-distances instead of actual distances to avoid the square root.  

As far as picking, the garbage that the Java 3D picking utilities generates is not significant for our game, so it's not been crucial for us to roll our own version (yet).  And we have lots of natural pauses built into our gameplay, so garbage collection hasn't been an issue for us.  At least not so far!  Wink    And we're not using picking for collision detection at all.

So, in general, the current Java3D stuff has met our needs fairly well (except for the lack of high-level animation infrastucture, and sound, and some bugs).  Which is why we're going to keep using it until something nearly as good emerges,  and is supported and embraced by enough developers to ensure that content tools like loaders are available.  

Which would have been Java 3D 1.4 if things were different...  Cry

But I'll be keeping an eye on the scenegraph APIs being developed now by you and others -- and I'll contribute to them when the time comes!

Offline shawnkendall

Senior Member





« Reply #20 - Posted 2003-07-08 19:40:54 »

Of course, the ultimate test of our work is whether developers like you can port with exceptible effort and have a equally (or better :-) ) running app.

Sounds like yours will be a great big test!

Shawn Kendall
Cosmic Interactive, LLC
http://www.facebook.com/BermudaDash
Offline TexMurphy

Senior Newbie




Java games rock!


« Reply #21 - Posted 2003-07-08 20:56:08 »

My project is a online space sim. You know your Elite, Wing Commander, Privateer, Jumpgate kind of game. First phase is just to make a simple online shoot em up as this involves all the important parts as rendering, physics, collisions, netcode and servercode.

The goal is to make the alpha phase in Java3D but given the state of Java3D (future unknown) Im pretty much aware that I will have to port at some stage.

If your project will allow me to render better graphics while still having a scengraph data structure Im all for it. Though I do NOT wana move over to pure jogl as the scenegraph structure is good for fast implementation (ot at least according to my evaluation).

A port could either be done right now in my project or when I have the first alpha running. After alpha 1 I will be adding persistancy, building a huge galaxy, player built stations and alot of other content and then I do want the data structure in place.

And ohh yeah I use behaviors for alot of things. All navigation and HUD display rendering is behaviors, radar/targeting will be as well.

Tex.
Offline William

Junior Member




No Exit


« Reply #22 - Posted 2003-07-08 21:05:48 »

My project Nevermore uses picking, scenegraph IO, and Java3D's JMF integration. Just wanted to warn you that I might dive in and work on those, or similar, components once you get the basics up.

I have really moved on to other projects now, but I would still like to play sound in Nevermore without having to freeze the rendering (like I do now with Java3D).

The JMF video-texture renderer shouldn't be too hard to port if the new scenegraph retains Java3D's texture handling, but maybe it would be better to implement it, or a general component for animated textures, as a custom shader to reduce the number of internal copies.
Offline dtwilleager

Senior Newbie




Java games rock!


« Reply #23 - Posted 2003-07-08 21:43:11 »

Hi David,

Welcome to the world of writing scene graph renderers.  :^)  Here are my thoughts on your approach.

   - By making threading a non-issue, you have already solved most of your problems.  :^)

   - Transform updates and the resultant bounding volume structure update will require carefull optimization.  It is a simple concept, but it will quickly become a bottleneck.  All hierachical transforms for rendering should be banned.  

   - State sorting is very tricky, but it is the gold.  It will get you from a simple renderer to a real game engine renderer.

   - Beware of certain scene graph features, they are hidden daggers.  Examples include Link/SharedGroup and hierachical rendering state.

Other than that, have fun.  The initial design and prototype is very rewarding.  The last 20% will kill you.  :^)
Offline bmyers

Junior Member





« Reply #24 - Posted 2003-07-08 21:48:15 »

Right -- I forgot to mention that we're using scenegraph IO, and multitexturing.

I am assuming scenegraph IO would probably not be compatible with Java3D's , even if it was implemented?

EDIT:
Hmmmm.... we're also using SharedGroups/Links quite a bit with our units to help with memory usage -- does Doug's note above mean that SharedGroups/Links are likely to not be implemented?

Offline DavidYazel

Junior Member




Java games rock!


« Reply #25 - Posted 2003-07-09 00:05:20 »

Hey Doug Smiley

I have what I think will be a blazing fast state sort design, but we will see.  Where do you think is the tradeoff between using geometry as the outermost sort versus shader sorting?

so

1. geometry -> texture -> transform -> (shaders like material, rendering attributes, etc)

vrs

2. texture -> shaders -> transform -> geometry

I was thinking that it wil have to be both, where I have the same geometry being rendered multiple times that I should use method 1, but for others use 2.

So, break the chunks into two bins, one which is where lots of duplicate geometry goes, which is then sorted inside by shaders for each geometry.  the second bin would pretty much assume that each geometry is different for each draw.

What has been your expereince?

Brad, I am supporting linked/shared groups from the start.  We use them a lot!

David Yazel
Xith3D Project Founder
http://xith3d.dev.java.net

It may look complicated, but in the end it is just a bunch of triangles
Offline William

Junior Member




No Exit


« Reply #26 - Posted 2003-07-09 05:22:51 »

Quote
I am assuming scenegraph IO would probably not be compatible with Java3D's , even if it was implemented?

True, but a new load/save API could probably convert a structure stored by scenegraph IO by loading it into Java3D, traversing the Java3D graph and saving it in a format compatible with the new scenegraph.
Offline shawnkendall

Senior Member





« Reply #27 - Posted 2003-07-09 09:33:45 »

Quote
Hi David,

Welcome to the world of writing scene graph renderers.  :^)  Here are my thoughts on your approach.

   - By making threading a non-issue, you have already solved most of your problems.  :^)

   - Transform updates and the resultant bounding volume structure update will require carefull optimization.  It is a simple concept, but it will quickly become a bottleneck.  All hierachical transforms for rendering should be banned.


Doesn't this bottleneck go away if the updates are force to sync, i.e. all updates must finish before you fire up the renderer?  
A single pass bubble up of bounds or keeping a dynamic changes list to loop through is quite efficient.  This is how other game scene graph renderers handle it ( begins with "Ren" ends with "ware" ;-).

Forcing sync seems to prevent the bottleneck, no?

Also, if you still need/want async scene updates, then you can build a message system (a la Java3D) on top of this based sync-ed renderer... ("can build" meaning huge ass-kicking effort)

Shawn Kendall
Cosmic Interactive, LLC
http://www.facebook.com/BermudaDash
Offline dtwilleager

Senior Newbie




Java games rock!


« Reply #28 - Posted 2003-07-09 16:38:43 »

Quote
Hey Doug Smiley

I have what I think will be a blazing fast state sort design, but we will see.  Where do you think is the tradeoff between using geometry as the outermost sort versus shader sorting?

so

1. geometry -> texture -> transform -> (shaders like material, rendering attributes, etc)

vrs

2. texture -> shaders -> transform -> geometry

I was thinking that it wil have to be both, where I have the same geometry being rendered multiple times that I should use method 1, but for others use 2.

So, break the chunks into two bins, one which is where lots of duplicate geometry goes, which is then sorted inside by shaders for each geometry.  the second bin would pretty much assume that each geometry is different for each draw.

What has been your expereince?

Brad, I am supporting linked/shared groups from the start.  We use them a lot!


The next RenderBin I was architecting for Java 3D, had just this type of configurability.  If the RenderBin can configure itself to the current data set, then you have the best of both worlds because different scenes and different hardware characteristics (faster buses, longer shaders, less multipass) can be tuned for later.

So, it sounds like you are on your way.

BTW, with the bus being the big bottleneck these days, my guess is that with big scenes, you will have a bunch of 1's at the beginning.
Offline dtwilleager

Senior Newbie




Java games rock!


« Reply #29 - Posted 2003-07-09 16:42:02 »

Quote


Doesn't this bottleneck go away if the updates are force to sync, i.e. all updates must finish before you fire up the renderer?  
A single pass bubble up of bounds or keeping a dynamic changes list to loop through is quite efficient.  This is how other game scene graph renderers handle it ( begins with "Ren" ends with "ware" ;-).

Forcing sync seems to prevent the bottleneck, no?

Also, if you still need/want async scene updates, then you can build a message system (a la Java3D) on top of this based sync-ed renderer... ("can build" meaning huge ass-kicking effort)


The force to sync definitle helps with the memory bloat, but the biggest factor on performance is how deep is your scene graph.  The composite transform computation will kill the renderer.  That's why hierarchical transforms are great for modeling, but horrible for rendering.

Java 3D is async, so it used the message passing system, and yes, it was a huge effort.
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.

BurntPizza (20 views)
2014-09-21 02:42:18

BurntPizza (14 views)
2014-09-21 01:30:30

moogie (14 views)
2014-09-21 00:26:15

UprightPath (25 views)
2014-09-20 20:14:06

BurntPizza (27 views)
2014-09-19 03:14:18

Dwinin (41 views)
2014-09-12 09:08:26

Norakomi (73 views)
2014-09-10 13:57:51

TehJavaDev (96 views)
2014-09-10 06:39:09

Tekkerue (49 views)
2014-09-09 02:24:56

mitcheeb (70 views)
2014-09-08 06:06:29
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!