(Or so they claim ;))
Current headline on OpenGL.org
http://www.web3d.org/x3d/applications/xj3d/
So much for Java3D being such a great scenegraph eh? The one thing it might be supposed to do well it’s slow at. How many times did we hear about scaleability and how small scenes were a poor test of its performance?
Oh well, I shouldn’t gloat, but you know…
Cas 
Do you have a pointer to the types of scenes they used to determine that the new renderer is twice as fast? Or any actual numbers for that matter? Pretty much every VRML scene I’ve seen in the past has been tiny, but perhaps that has changed…
The main browser app that is included with Xj3D has a frames per second counter on it as the simple guide to rendering speed.
The big test scenes we use we can’t redistribute as they come from some of our users. The three typical test scenes we use for large-scale rendering is
[*]Planet9 datasets, which are in the order of 15MB for the geometry and about half a gig of textures. Not high on the polygon count (about 20-30K polys), but heavy on textures.
[*] CAD training demo. If you’ve ever seen any of our live demos, this is the one with the encapsulation machine. There’s about 2hrs worth of animation data in the file - it’s about 16MB. There’s about 100K polygons, almost no textures.
[*] Several tests scenes from Elumens - Cityplaza (internal scene, heavy textures) and arboretum (external scene, heavy billboarding and transparent textures).
In each case the OpenGL renderer (Aviatrix3D) easily twice the framerate of Java3D. We have one CAD file test scene that is pure static polygonal geometry where we’re just marginally faster than J3D by about 10% or so. We’ll be optimising that one shortly (right now we’re not making use of VBOs or interleaved geometry).
Edit: Forgot to add that this is moving through the scene. Aviatrix3D has some optimisations where if nothing is changed in the scene graph for that frame that it just skips the culling and sorting steps and just reuses the previous rendering loop. Sometimes this can quadruple or more the framerate (cityplaza for us goes to about 150 FPS from 47FPS using this technique when you aren’t moving) To get a good idea about real differences you either need to have animation running or be moving about in the scene.
But isn’t Aviatrix3D a scenegraph?
Kev
[quote]Aviatrix3D has some optimisations where if nothing is changed in the scene graph for that frame that it just skips the culling and sorting steps and just reuses the previous rendering loop. Sometimes this can quadruple or more the framerate (cityplaza for us goes to about 150 FPS from 47FPS using this technique when you aren’t moving) To get a good idea about real differences you either need to have animation running or be moving about in the scene.
[/quote]
Hm … couldn’t you optimize it the other way round?
I’d prefer high framerate when moving over seeing the same still image 150 times/s
[quote]But isn’t Aviatrix3D a scenegraph?
[/quote]
It is. Meanwhile it gets really difficult to find the right scenegraph to use. In good’ol times there was Java3D… kind of a standard.
Now we have at least 4 (Java3D, Aviatrix3D, Xith3D, OpenMind). Somehow this corresponds to having a variety of OGL bindings…
So Sun is so eager to keep Java itself closed, but on the library side it heavily diverses…
(Does it come thru that I dislike that fact? Makes my life harder!)
Thanks for the numbers, it is always good to know that “real” scenes were tested
Now, if Aviatrix3D is a Java scene graph on top of an OpenGL binding (much like Java3D, just a better implementation) does anyone know the reason for the OpenGL.org headline:
“Xj3D Toolkit vM9 adds native OpenGL API renderer that is twice as fast as the Java3D version”
Makes it sound like “they dropped Java, went native and got a 2x speedup”…
Nah, it’s easy ;)…
OpenMind - who? Seriously, doesn’t seem to be going anywhere, doesn’t seem to be used much. Haven’t seen even one real game (let alone a good one) using it yet. Can’t even find games links on the main website. No webstart demos.
jME - no documentation at all, hence far too risky
Aviatrix - if you fit with it’s specialist aims, it’s a perfect fit
Xith - easier to use than J3D in some respects, steals J3D’s good SG, is utterly rubbish at 2D overlays. Great if you need no HUD, or can tolerate simple manual-rendered HUD and GUI
Java3D - Either you already know it and so it’ll be by far the fastest for you to code with, or you don’t and it’s not worth using for at least another 6 months / until the next major update appears (with bugfixes! And better performance!)
We can add more optimisations to the moving part, but just haven’t done so. Basically what that entails is making use of inter-frame coherence on the view frustum culling step. We could employ some other techniques as well that don’t use this, but right now our aim has been to complete the coverage of OpenGL abilities first. We’re almost done - all I need to do now is rasters/bitmaps and multipass rendering support as part of the scene graph structure and we’re finished on the structural side.
At least with what I know about the codebase, I still have about a 30% increase in performance I can wring out of it without having to head into heavy algorithmic changes like the interframe coherence work. Mostly just stuff with the way we set and stop state at the renderer level.
[quote]does anyone know the reason for the OpenGL.org headline:
“Xj3D Toolkit vM9 adds native OpenGL API renderer that is twice as fast as the Java3D version”
Makes it sound like “they dropped Java, went native and got a 2x speedup”…
[/quote]
No idea as we didn’t write it. The webmaster of OpenGL.org is also the same guy who does Web3d.org and Khronos.org. Seems he picked up our release announcement on the Web3D end of things and reslanted it for the OpenGL crowd. Though we know about his connections and we’ve chatted informally about getting Aviatrix3D announcements posted to opengl.org, he pretty much told us about it after the fact! I saw this on the weekend and it was as much a surprise to me as it is to you guys. He managed to get a few little things wrong too (Immersive profile support is not complete yet, we’re about 6 nodes out of 70 odd short).
We’re not quite as specialist as you might imagine. We still have full coverage of OpenGL as a complete scenegraph. Where we are different compared to, say, Xith3D, is that our optimisation strategies are targetted for handling multi-CPU/multi-display machines, where Xith3D is purely single CPU/thread setup. As such, we’re hitting almost an identical target audience as Java3D, just doing it a lot more efficiently So, on a given PC, Xith3D will be faster than us, and we’re faster than J3D, if that gives you a good idea of the performance comparisons. We’ve already got all the required bits like GLSlang shaders, subtexture updates, various culling and state sorting capabilities etc,
And…
To answer Kev’s question:
Yes, AV3D is a scene graph. Xj3D is a loader and toolkit that works as a scene graph as well but layers X3D/VRML semantics over the top of a lower level renderer. As such, it uses either Java3D or Aviatrix3D for the low-level rendering (it also could use GL4Java as we still have some of that code in the codebase, but it has probably suffered serious bit-rot by now).
Because we needed to build a rendering system over the top of OpenGL bindings to ensure our long-term financial future that was independent of Java3D, we decided to create a scene graph system too. However, we felt that, although our development of AV3D is going to be mainly using Xj3D over the top of it, that others may be interested in the work as a separate project. So, we split it off and it has a life of it’s own that is independent of Xj3D. The majority of the real-life testing of Aviatrix3D is done by the use of Xj3D over the top of it, so we do get to play with a lot of very varied content structures that exercises the entire codebase quite extensively.
are you kidding me? all those demos on how to use it, with comments on each line? all that wiki? and the user guide? my site has some tutorials.
All that, and no documentation?
Not forgetting the javadocs…
DP
“Source code is not documentation”.
Yeah, that FANTASTIC user-guide, which has (almost) no pages!
http://mojomonkeycoding.com/pmwiki/index.php/UsersGuide/UsersGuide
(95 sections, of which barely 10 are filled in, and more than a third of those are introductions!)
Having a UserGuide which emphasizes how much documentation you don’t have, and making it hard to find anything better are classic ways of scaring away any serious developer who doesn’t have time to risk on incomplete untenable technologies that probably won’t be around in 2 years time. Shrug. That’s life.
Put it another way: we wanted to try jME for Survivor-v2 (thought it might be a better for the new stuff than Xith is), until we discovered there was no real documentation and decided it was far too risky. IIRC this was a unanimous decision, that each person came to separately.
Method docs are the last refuge of people who can’t (or can’t be bothered to) write real documentation. Most people who say “but we’ve got javadocs” don’t even bother to write package comments in their javadocs, and that’s inexcusable really if you’re claiming you have real documentation…
Really, we wanted (certainly I did) to use jME, but until someone sufficiently finishes it off to make it properly usable…
NB: Xith of course is saved by the fact that it’s almost identical to Java3D, which is plentifully documented. But even Xith devs are not happy about the doc status…
Jesus Christ, I’m being attacked pretty hard here…
First, DP, while a very strong supporter of jME, doesn’t represent jME, I do.
[quote] Yeah, that FANTASTIC user-guide, which has (almost) no pages!
http://mojomonkeycoding.com/pmwiki/index.php/UsersGuide/UsersGuide
(95 sections, of which barely 10 are filled in, and more than a third of those are introductions!)
Having a UserGuide which emphasizes how much documentation you don’t have, and making it hard to find anything better are classic ways of scaring away any serious developer who doesn’t have time to risk on incomplete untenable technologies that probably won’t be around in 2 years time. Shrug. That’s life.
[/quote]
Documentation has just begun, if you’d taken the time to look at the edit dates, you might notice that they all started these last couple days. It has started, and is the primary focus of myself. It takes time, you should know this, looking at the small amount of useful material on your OWN site, you should keep the rocks in the pocket.
[quote] Put it another way: we wanted to try jME for Survivor-v2 (thought it might be a better for the new stuff than Xith is), until we discovered there was no real documentation and decided it was far too risky. IIRC this was a unanimous decision, that each person came to separately.
[/quote]
Too bad, but not suprising. Kevin had already use Xith3D quite a bit before hand, he’d be a fool not to go with a technology he knew with the time constraints of the contest looming overhead.
[quote]Jesus Christ, I’m being attacked pretty hard here…
[/quote]
Sorry, I probably wasn’t clear, and so you’ve misunderstood me. I wasn’t attacking jME, although I do rail against any claim that javadocs and some source code count as documentation.
If you re-read my post carefully you should be able to see that I’ve no issue with that - only with the claim that was made that it was well-documented already.
If you’re referring to grexengine.com, that’s an entirely different issue. The GE has tonnes of documentation - it’s just that we don’t have any reason to post it on a website for random surfers to come along and gawp at. It’s mostly nicely laid-out PDF’s and hardcopy printed manuals…
I was referring to AFTER the competition - last month, both I and Kev wanted to try jME, and so I got everyone to go and check it out. I can’t speak for KG on this, but we don’t have the luxury of saying “Hey, if we wait XXX weeks then perhaps technology YYY will be sufficiently user-friendly that we can use it without wasting lots of time trying to learn it”. Like any commercial game, we have a few days to a couple of weeks to make final decisions on what tech we’re using - if it’s something as fundamental as the rendering engine for an arcade 3D shooter then it’s purely a case of “What’s available today?”.
I’m still hoping that by the time I next do a 3D game jME will be at the state where I can just pick it up and run with it. Sadly, I probably won’t get much choice when the time comes, but I can hope…
I’m v. tired (it’s been a > 16 hour working day today) and that one long sentence was intended as two separate concepts. The first relating to jME (the userguide at the moment is deeply scary to people evaluating it for a non-hobbyist project) and the second describing the issue at stake for the evaluator (potentially any tech you aren’t paying for could do this to you, and that will dearly screw you over, probably causing the cancellation of your project, so you have to be always wary of it as a possibility).
Ok, I’ve cooled down a bit.
First point, if you have to add a sarcasm tag, best not use the line at all. I tend to take offense to your posts now and then as the tend to absolutely drip with arrogance. Whether that represents you in anyway, I have no idea.
Second, I know you were responding to DP, but you did so at jME’s expense. I would be the first person to admit documentation is what is most needed (that’s why it’s all I am doing at the moment). And again DP does not represent the opinions of jME… yadda yadda.
I’ll leave it at that.
Just to put in my unwanted 2 cents…
jME has had some great results internally and the developers tend to be emotionally tied to it. (Well, at least I am.) I think over the next release or so we’ll get it to a point where you don’t have to know it already to love it. Any constructive comments to help us move towards that goal are always welcome, especially if you have time to drop them on our own board over at http://www.mojomonkeycoding.com/jmeforum/.
Thanks!
blah, i was merely trying to point that that there is some documentation, for my tastes its plenty, but for you, obviously it isn’t.
And why isn’t source code considered documentation? I use the code all the time to find out what the method does. Just look above the method and youd find alot about the method. If your not sure about the class, just look over the class declaration to see a paragraph if not more describing what the class is.
And yes, most people down at jME HQ are emotionally tied to it. I am too, and I take offence directed at me at the slightest offence to jME.
DP
I dont know about this new M9 relesae of xj3d but what i can say from the previous ones is:
xj3d allways made me happy for the idea of mixing x3d with java with a limited x3d editor like x3dedit and get a easy prototyping solution for games.
But after downloading M7 or M8 (dont recall) a couple of months ago and see its critical lack of documentation, and i mean compared to xj3d i have seen the project you guys are complaining here is amazingly documented.
Not only that but i had to run their browser with a dos batch file that didnt worked becausethe command was too long and there wasnt enough memory for dos input line or something like that. :-/
Worst, everything comes with a douzen of mini-jars, you get almost no ocumentation (one or two html pages), and rely only on examples and minimaly comented javadocs.
Besides i used their simple brower with a very simple vrml example and it gave me an error. I know that example worked in almost every other vrml plugin and browser cause i have tried it.
I also tried x3dedit at the time but same dos solution and a program slow like hell drove my computer to his knees without ever loading anything.
I will download xj3d M9 and the new auto-installer for X3DEdit but if i see a dos batch file with a 500 chars command i wont ever bother running it. And if this is not the case im only tempted to decipher their examples and learn how to use it for just that tad amount of time.
I have tried xj3d something like 3 times now. If i get dispointed with this one once more im thinking on forgeting about it completely. The idea is good but they seam to be working on a product for internal usage only.