I am getting second thought on Java3D. It doesnt seem that many people still use it. So I have a few questions.
Is it dead? I mean do people still use it?
Or can the fact, that Java3d is now open source rescue it?
Does the fact, that it is now open source mean that Sun doesnt support it anymore and that only the community is supposed to improve it?
I read about the alternatives (jogl, lwjgl, jme, xith3d).
questions to the alternatives:
Is it possible to distribute applications using the alternatives via webstart, so that the user only needs to follow webstart-link in order to start it? (because for me, none of the jogl demos worked)
Is it possible, to distribute applications using the alternatives without webstart, while the user still should only need to double-click the *.jar file so that it runs?
jogl and lwjgl seem to be pretty low level. Does one have to write more code compared to java3d in order to achive the same? For example when loading models.
is xith3d a good alternative, because of the scene-graph approach?
If you dont want to answer all the questions, then thats fine too. Any input is appreciated.
Java3D is not dead, the Java3D Interest is very lively, it just doesn’t seem to be used for many games recently. Java3D being open source is good for the community since its takes the future of the API out of the hands of businessmen and puts it back on community need basis.
However, Sun do still seem to be supporting it and providing people’s time to update it. This is very impressive and should be applauded.
Yes
Yes
Yes, scenegraphs are simpler to use but lead to more generic solutions, which generally are slower. However, unless you know what you’re doing pretty well at the low level you’re unlikely to beat the performance (poly for poly) of a highlevel scenegraph written by people who do know the details.
It’s not dead, but as you say, not many people are using it for games.
Yes, you can use webstart with the alternatives. Not always easy to get webstart to work for everyone though.
The alternatives will work with a double-clickable jar if you put the native libs in the same directory as the jar. You can not put the libs in the jar. Never, ever, put a native lib (dll) in any of the jre directories.
Yes, you have to write more code. It’s also not easy to write fast opengl code.
7)Xith3d is a good alternative for Java3d if you wan’t to make games. It’s twice as fast and designed for games.
So I’ll continue my current project using Java3d. Since its a small game anyway and I’m not able to create fency modells or special fx, I guess it makes no difference.
No, it’s not dead, but it isn’t progressing particularly fast either. All the Java-based competition has many more features than it and seem to be accelerating away from it in those feature collections. That’s probably the biggest issues around it’s current development.
Probably the major achilles heel for Java3D right now is it’s speed. It’s dreadfully slow when compared to all of the competition - gaming oriented or otherwise. I don’t know of any scene graph API that doesn’t provide at least twice the frame rate and significantly less memory footprint when running the same content. While it may be fine for small games that don’t need fast framerates, that’s not acceptable for other larger and more complex systems. For commercial application developers like ourselves, that is not acceptable to our customers and they’ve all migrated away from J3D to other APIs.
The advantage that it has is the huge collection of utilities already around it - particularly the file format loaders. No other API can come close to that right now and probably won’t for some time yet.
I would REALLY like to see the benchmarks on this. I have yet to see a convincing one.
Java3D has some overhead that makes it slower on trivial microbenchmarks.
That same overhead is there for calculations that give it massive performance improvements on significantly compelx scenes.
Im getting great performance eo far on JWNW. Well exceeding what the native NWN client delivers on my hardware…
Java3D is used by folks like NASA for imaging applications. Shawn Kendall at FullSail abandoned his custom scenegraph and went back to J3D.
You’ld probably want to ask him why.
EDIT: JNWN btw is a slow-progressing ebcause Im very busy, but active game project. RIght now Im workign with Shawn on pure-java collision and simpel physics for J3D.
EDIT 2: BTW, Java3D just added shaders, a major feature upgrade. The next big one that is out there is multi-=pass rendering. The team tells me they are looking at that for the major release after this one.
[quote=“Jeff,post:6,topic:24281”]
I asked about performance at the Xith3D forum. There seems to be no “official” benchmark available to back up any claims but there’s some indication Xith3D may be about twice as fast as Java 3D.
Try running Xj3D. It has renderers for both Java3D and our own scene graph. Our own scene graph does everything Java3D does, including multithreaded pipeline rendering and is at a minimum twice as fast, typically more. The bigger the scene the more Java3D falls behind. Look at the games like the old MagicCosm that went from J3D to Xith3D. Again, at least twice the framerate speed increase, though with a more gaming oriented implementation of the same API. Shaders are nice, but all the competition has had them for more than 12 months now. Other features missing that the competition already have are compositing, multipass rendering, access to other buffers than just the framebuffer etc. What the competition miss is a big community around it and as a result a lot of utility code like file loaders, input device handlers etc. When implementing an application, that can be a big factor.
I think it’s a myth that Java3D give such massive performance boost on complex scenes. A complex scene will run slow no mather how smart J3D is. Besided, games are all about custom culling that cuts down the scene size.
I’ll bet there is quite a difference between NASA imaging applications and the games we wan’t to make. Besides, I don’t think NASA puts performance very high on the list of priorites. After all, they can just buy a more powerful workstation / super computer.
A stamenet of beleif with no supporting data cannot be dsicussed or argued with except to point out that it IS pure belief.
The same reason I do not debate with rabid Evangelicals. (No offense to the Nice, reasonable, intelligent Evangelicals out there.)
Java3D has very sophisticated and high performance view-frustrum culling. The oevrhead of that is aprt of what makes “pump triangles to the visible screen” microbenchmarks meaningless.
What more are you looking for?
I dunno. The Mars rover simualtor I downloaded seemed pretty game-like to me *shrug
Sorry but I have to chuckle 'cause I KNOW people at ames reserrach. You have any idea how badly the republicans have cut their budgets over the past 6 years?? You probably have a bigger budget for your workstation then my friends have.
Besides, these days they are producing Apps to be run be anonymous downloaders from the net
EDIT: Let me make this clear. I don;t care WHAT scenegraph you or anyoen choses to use for their project. What I DO care about is the promulgation of what are potentially myths and misinformation. As long as the data youa re makign your decisions on is clear and well established, use whatever fits your tastes and project best. If someone will give me a pointer to Xj3D or some other sufficiently complex test case Id be happy to look at it, and maybe even hand it off to the J3D team for analysis and comments.
What I do know is that there is a fair bit of real rocket science inside of J3D to deal with performance issues, some of which is actually sufficiently novel that it is patented by Sun.
Important note. Java3D is NOT a scene graph renderer.
It is a scene graph translator. Trying to render directly from a scene graph is a very inefficient way to render. J3D converts the scene graph to internal sortyed and organized lists of operations that are much more efficient to render from.
Part of that patented magic I was mentioning.
And yes, you would have to write a LOT of code in JOGL or LWJGL to start even matching J3D performance for anything at all complex. Having said that if you are a John Carmack, working on the OGL level you can take cheats that are not correct in the general case but you can design your game around. If you do that it is possible, with a lot of work, to get better performance from a lower level like OGL.
Your splitting hairs. Of course it organizes the geometry behind the scenes. That is the point of having a scene graph, and everyone does it. The code may be complex, but the theory is simple:
do state sorting to minimize state switches
batch geometry to maximize threwbut
When the scene gets bigger there is potenially more state switches and the scenegraph can sort this out for you. Even so, scenes in games are usually quite small. Microbenchmarks, like the one made by java cool dude will give a pretty good indication of how the performance will be in a real game. From what I’ve seen and heard, J3D is slow.
Not the traditional scene graphs such as Inventor.
Nor do the scenegraphs msot people are taught to write in basic college classes.
Its an important distinction. “Scene Graph” in this case describes the API but not the render.
Sicne you are talking ABOUT render speed, thats a critical diffrerence. A pure scene graph based renderer WILL be slow because it does a lot of extra matrix manipulation, does a lot of work on thinsg that never get drawn at all, and doesnt render in the ideal order.
You left out a few things. Such as matrix concatenation and view/frustrum culling…
Compared to what? They are among the most complelx I’ve ever dealt with…
Not knowing the microbenchmark in question I cant comment. In genreal microbenchmarks fail to predict real-app performance because they do not act like real apps. Its really that simple.
The most common “look how slow J3D is” benchmark I see… and I see this over and over, is a pure pixel throughput benchmark where all triangles drawn are visible in the rendered view. These are by definition totally worthless.
Again, point me at a real benchmark and we can discuss it. Oterhwise this is just assertion and mythology. (And by ‘point’ I mean give me source code so I can do a proper analysis. Its quite easy to make J3D performance bad by using it badly… This is true of ANY API.)
EDIT: Oh and I suggest if what you say is true, then you havent seen very much in J3D. Certainly you havent seen Shawn Kendall’s demos we showed every year for years at GDC…
So here’s a real game benchmark for you with real game data…
JNWN on my laptop, (Sony VAIO PCG-GRT290ZP) with physics currently turned off and no particles, but oterhwise running the real starting map from the “DEMO-The Cat Lady” module and one movign animated character (a lioness) is running at a reliable 250fps.
Frankly, that easily falls into my “fast enough” range.
Edit: As a side note, this is without any serious profiling. At one point I did have a sudden, mysterious, serious slow down. I ran the profiler and discovered a leak in the J3D pick code. Paul fixed it and the problem went away.
This does however point to the real need to keep a profiler handy when coding any game code. Sometimes you will do something or run into a bug that causes a slow-down. At that point you want to be able to understand why the slow down is ocurring bewcause its usually a simple matter to fix.
I don’t have any direct benchmarks for you to play with. However, you can go and download Xj3D yourself from here http://www.xj3d.org/downloads.html Then, using the commandline switches of -ogl and -j3d you can run the Xj3D browser with exactly the same X3D or VRML file and watch the framerate counters yourself. Apart from the low-level scene interaction, all of the runtime infrastructure (file loading, X3D event model evaluation, input device processing etc) are common.
One thing I can directly comment on - have a look at the video of the JavaOne main keynote. Xj3D was shown off there for about a 5 minute stretch. WHen given the option of the renderer to chose -either Sun’s official Java3D or the OpenGL renderer, they chose the later, not the former because of that huge performance difference. We’re not talking trivial rendering either, we’re talking large-scale terrain visualisation with a lot of realtime input from systems such as autonomous underwater vehicles, DIS (distributed interactive simulation protocol) and more. Xj3D is the benchmark you are looking for because we cannot take any game-specific hacks to make one renderer faster than another. We have to deal with random content from any user from anything as simple as a rotating cube up to full geospatial applications running realtime input from hundreds of sources simultaneously, or medical visualisation, or skeletal animation systems, rigid body physics and more. Basically everything including the proverbial kitchen sink is run over both renderers. In our case, the OpenGL scene graph that we coded, called Aviatrix3D, does do everything Java3D does, including parallel scene processing, multipipe and multi-stage rendering etc. In fact, the API looks a fair bit like Java3D’s. Our stock development boxes are dual Xeons running HT to make it look like many of our deployed users’ systems - multi-cpu visualisation machines. Java3D certainly is not unique in these capabilities, and that’s what I’m trying to point out. Even on equivalent systems, with equivalent scene graph capabilities, it is very far behind the ballpark right now in performance and capabilities terms.
Is there source? Without the ability to profile and see what is actually going on I cant really asses this.
As I mentioned above, a single screw up or hitting a bad bug corner case of an API can significantly imapct your performance results.
A question-- have YOU tuned your API for this test case? If so then its a pretty bogus comaprsion until J3D is equally tuned, isn’t it? (Remember the bad old days of seive-generators in C compilers? Same fundemental idea here.
Id ask if you have that actual statement from them as to motives. or if thats supposition on your part, but its irrelevent really because of the above issue,
Again, the performance thing is at this point is assertion . You have one test case. If you can point me at full source Ill actually take the time to do a bit of analysis. You could also download JNWN, its open source, and port it to your scenegraph if you wish for comparison purposes.
Features that are useful for game development we havent begun to talk about really, except that J3D currently needs multi-pass rendering. Its well known. Its on the plans.
I’m glad your proud of your accomplishment, but you’ve also got a bit of a bias and something to prove here… nes’ cest pas?
EDIT: And once someone is running a recent game’s real content at 250fps, one has to ask if performance is even worth makign an issue of, doesn’t one?
EDIT: The URL you gave above generates a 404 error. Ill poke around that site a bit I guess.
EDIT: Found it. Downloaded it. Now the question arises of content. I want a variety of things to try and explore. Can you give me general directions on how I download and run an X3D file and soekm repositories thereof?
EDIT: P.S. Just an observation. If you really do everything J3D does then you are almost certainly in patent violation. Luckily Sun doesnt sue folks generally over such things. Thats not a promise, just an observation.
