How does this work with their dual pipeline strategy Direct3D/OpenGL ?!?!
Seem odd to me.
// Tomas
Once I voted for dropping the D3D support in favor of the OpenGL stuff. Advantage: only one codebase.
This seems to turn out to be a big mistake…
glsl support on d3d is an interestign question. Ill ask Kevin on monday.
I knwo the whoel point of GLSL was that it was suppsoed to be hadrware neutral so I imagine it could be translated, but i dont know what they are actually doing yet 
Go away for a week and look what happens! ;D
Right, where to start… Jeff, thanks for taking the time to have a look at Xj3D. Few pointers there and the text bug we know about and have fixed a couple of months ago in CVS.
Performance differences between NWN and Xj3D. Yes, that’s to be expected. One is a fully optimised game engine player that deals with a very specific content set. The other is a general scene graph and runtime engine that is optimised for nothing in particularly. It has it’s own runtime model that must be evaluated every frame etc. The core point is that the entire runtime structure is identical for both renderers. The only time you get to runtime-specific structures is once you get down to the individual node. We have an X3D/VRML scene graph which then overlays the renderer-specific scenegraph (AV3D or J3D) because the structures don’t map cleanly through (eg a VRML Transform node has separate scale, translate, rotate vector values that need to be combined into a single matrix to send to the renderer). The only time either of them update is at the end of the eventmodel evaluation for the frame. In effect, the interactions between the real code and the renderer is relatively minimal. Rendering speed is thus determined by how quickly the underlying renderer returns back to userland code. We use no Java3D behaviours other than WakeupOnElapsedFrame(0) so that we clock it every frame. Java3D has nothing other to do than process and push polygons, and perform picking at the start of the next frame. This makes is a very good comparative performance between rendering technologies because there is absolutely no optimisation for a specific rendering API beyond polygon pushing. Comparing a general purpose rendering engine versus a content-specific engine won’t be of any use because that is like comparing apples with motorcycles.
Optimised design stuff: Aviatrix3D was designed to be an efficient API for large scale visualisation - scientific, medical etc. We’re not designed for gaming, nor for any Xj3D-specific purpose either. None of the work that has gone into it particularly special. Everything is based on common strategies such as view frustum culling, state sorting, etc. We looked at almost every visualisation API out there that we could get our hands on - Open Scene Graph, OpenSG, Inventor, Performer etc etc and built something that did what these guys could do. Java3D is nothing special in those terms. If it has anything patented, who cares as it would have to be so implementation-specific that it doesn’t effect anyone. The one bit that is patented is the geometry compression and Sun has already granted us the use of those patents for use in the X3D spec about 12 months ago. If you want to try running the patent FUD trick, go for it, but we’ll just completely ignore you.
Rendering differences between the two APIs. Yes, that’s an odd one. The same data is being passed to both, so I don’t know why they sometimes come out diffferently. I do know that at the Xj3D level we haven’t yet mapped some of the rendering qualities through that Java3D has (eg mipmapping and some filtering options). I also know that J3D reorders some of the rendering calls in very odd ways occasionally that can lead to somewhat bizarre rendering artifacts that we weren’t expecting to see. One of the worst problems is the frame lag for transformations versus geometry. If you have a single behaviour and set a transform matrix, a vertex change and some material changes, you’ll see the changes appearing in 3 separate frames, not all together as they should be.
Herkules: One of the tricks to get Java code running fast is to write it like it was C code. This is a point I continually make here and yet you get people that claim that garbage collection is good and fast. The fact is that it isn’t. Every time that GC runs or that you create new object instances, you’re loosing CPU time. The same tricks as before Java still apply now. Don’t waste time creating and destroying objects. Reuse them. Don’t make the system do work it doesn’t need to. GC pauses are very visible in graphics applications regardless of how short they are. It’s something the eye picks up on very easily. I know that once we did a garbage pass through Xj3D that we gained about 30% better framerates and all the stuttering completely ceased.
Hmmm… other points I was going to make but the reply box here is only showing the last page or so of the thread… DOH!
No.
JNWN is my NWN client,. It uses Java3D. In fact, the runtime is almost exclusively Java3D outside of the physics behavior.
AIUI however Xj3D DOES have its own full internal graph structure in addition to J3D and is only using J3D for render. If thats true then I’d grant you are certainly using memory unecessarily in maintaining two structures. You may also be wasting some processing power in not leveraging Java3D’s maintainence of bounding volumes and such. If so, O’d wodner why you are using a scene graph API at all, really, and why you just don’t render from the XJ3D structures directly to JOGL…
See above. Sounds like your wasting a lot of what J3D has to offer.
In any event, they key point was that the two APIs were not comparable for performance because they werent producing the same result. Id be happy to take another look when they do although the SECOND almost as important point was that FPS readings were so wildly all over the place ontop of either scene graph to draw any meaningful conclusions.,
[quote] Java3D has nothing other to do than process and push polygons, and perform picking at the start of the next frame.
[/quote]
Which means you are using it as JOGL and should use JOGL instead, nest ces pas?
No it makes it a very BAD comaprison because Java3D is designed to do a lot more then just push polygons to the screen. If thats all your doing, the right technolgoy is JOGL.
JNWN uses Java3D as its intended to be used. Its also very stable on performance numbers. I suggest you put your scene graph under it and lets get a real benchmark.
'nuff said.
Oh the answer to the shaders question…
If you want to go cross platform, but all OGL, use glsl.
If you want to go single platform (Windows) but cross API (OGL and D3D) use cgl, which is also supported.
Unfortunately, thanks to Micrsoft, there is no way today to hit both goals with the same shader programs 
[quote] Java3D has nothing other to do than process and push polygons, and perform picking at the start of the next frame.
Which means you are using it as JOGL and should use JOGL instead, nest ces pas?
[/quote]
No. It means that we’re using everything that is useful to us. To use JOGL, we still need to implement some sort of rendering pipeline that does all our state management, culling etc. We’re just not wanting to use any of the intrinsic behaviours because they are effectively useless for us. If I have a rendering engine that needs to do terrain following, collision detection (both object-user and object-object), visibility and proximity detection etc, these cannot be done by the stock behaviours provided by Java3D. It’s not that we’re not using what J3D has to offer, it’s the fact that Java3D doesn’t offer what we need to start with or goes out of it’s way to make it very difficult to do. For example, the whole BranchGroup thing makes our scene graph typically 3 times deeper than it should be - every node is removable and shareable in X3D/VRML, so for every X3D node we need to use a Link->SharedGroup->BranchGroup combo!. In fact, the whole J3D model for behaviours is quite bad - it’s very hard to guarantee any specific replicable result, which is what is required to implement the X3D spec.
As for memory usage. Yes, we have to pay a penalty for that. We really have no other option. There’s a requirement by the X3D spec to be able to read all the fields as they were written at the X3D level. For example, trying to pull geometry data out of an indexed triangle array for an ElevationGrids heightfield can be quite a bad thing to do. Considering that many of our users are using extremely large datasets (in the orders of 10s of megs per geometry primitive) the cost over heads of creating passing around and then GCing those large arrays is staggeringly high. And, as I said in the previous post - the X3D scene graph does not map cleanly onto either Java3D or AV3D (Xith, OpenSG or anything else for that matter) so there is a layer needed in between to merge the X3D user’s view of the world versus the renderers.
[quote]No it makes it a very BAD comaprison because Java3D is designed to do a lot more then just push polygons to the screen. If thats all your doing, the right technolgoy is JOGL.
[/quote]
Please justify this. Why is it bad? You keep claiming that there are no good benchmarks for comparing J3D versus some other scene graph. Every time you’ve stated this in past threads you claim that because the implementations are not the same when someone has done that (for example converting a J3D app to Xith3D). Yet, here I offer you one good, complex, non-microbenchmark example of exactly the same code running over the top of two very different scene graph implementations that have the same end goal (large-scale visualisation, not games) and now you claim that it can’t work because it wasn’t optimised for the specific scene graph. You can’t have it both ways! So, which of these two contradictory arguments are you going to use here?
Consequently, if it is so easy to get such good numbers in Java3D, why is it that only you and the Fullsail guys seem to be able to do it and none of the rest of us (particularly those like myself that have been doing professional 3D graphics programming for more than a decade) cannot replicate those same results. If there is such a black art required to get them, don’t you think this says something pretty important?