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!
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.
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.
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. :^)
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?
Hey Doug
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
- geometry -> texture -> transform -> (shaders like material, rendering attributes, etc)
vrs
- 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!
[quote]I am assuming scenegraph IO would probably not be compatible with Java3D’s , even if it was implemented?
[/quote]
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.
[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.
[/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)
[quote]Hey Doug
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
- geometry -> texture -> transform -> (shaders like material, rendering attributes, etc)
vrs
- 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!
[/quote]
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.
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.
Unfortunately, some models simple have to be made of seperate geometries under a matrix hierarchy, for example, a robot.
One issue we ran into in the loader was that some transforms we know will not change at run-time, i.e. they were used to position a geometry, but will not animate at run-time.
For public explaination…
In SGIs Performer these would be called Static Coordinate Systems (SCSs) as opposed to Dynamic Coordintate Systems (DCSs), which was there equalavent to J3Ds TransformGroups. Sometimes the loader knows this and could properly make ths SCSs in Performer. Then in a second pass, the SCS could be forced down into the geometry (we called it flattening) effectively removing the extraneous transforms.
We could not do this in our flt loader because we wanted to allow detaching at the “joint” points. But if you don’t plan to do that or know to add a transform back when you detach we could have cleaned out quite a few in most models.
This sort of issue is exactly why we are still moving forward on our sample rendering for a J3D scene graph. There are many many more times, higher level fuctionality is known to be limited in a way that can really simplify/optimize drawlist and state-sorted generation.
General graph renderers are great generally. But since you can’t hack/alter/modify the J3D renderer directly… now if it was plugable or open source… 
In any case, more examples of how to render a J3D scene graph is still valuable I believe.
I forgot to mention that the transform to geometry flattening can happen behind the scenes when the renderer queues/caches up it’s geomerty, if the “capability bits” were set as not writable, as you can set in J3D.
Doug, your are talking about writable transforms I am assuming…
[quote]I forgot to mention that the transform to geometry flattening can happen behind the scenes when the renderer queues/caches up it’s geomerty, if the “capability bits” were set as not writable, as you can set in J3D.
Doug, your are talking about writable transforms I am assuming…
[/quote]
Yes. In fact, if you set all the capability bits correctly and compile the graph, Java 3D will flatten for you.