Merge Java3D and Xith3D?

You are here:

Hi,
now that Java3D is reborn and has become open source, it occurs to me that the development effort on these two projects could and should be merged.

I understand that there are some significant differences in the implementation. My understanding is that Xith3D is not thread safe because of the goal of achieving faster performance. However, please forgive my naivety, but are these differences insurmountable?

If you apply the same argument that Sun are using for not open sourcing Java itself, that it will lead to splintering, should we not be uniting the two implementations of what is essentially the Java3D API?

There are some big advantages of Xith3D, the performance issue just mentioned, the fact that you can get to the underlying JOGL/OpenGL.

With so few of you guys contributing to the 3D code development, doesn't it make sense to pool your resources and work together on one implementation - that has everything?

Reply viewing options

I attended a Project Looking Glass presentation at our local Java User Group. The speaker from Sun mentioned that JOGL api has been pulled out of the JSR process because it is Gaming oriented! The pace of JSR will never catch up the pace of the Gaming community where "performance" and "features" are everything for the gaming community.

When you look at the release cycle of nVidia and ATI, drivers are released just to get better benchmark results from Doom III and ignore the quality of the drivers they released!

That's why Java3D shouldn't based on JOGL because of JSR and spec stability issues. Although I am personal looking for a way to add JOGL to the Java3D rendering pipeline becuase of the fundamental differences between a SceneGraph based Java3D and procedure oriented JOGL. It would be really nice if this could be an official Java3D plugin.

On the other hand, for users of CAD/CAM/Animation/Manufacturing industry, they prefer to use the Processional level video card because of the strict quality assurance before releasing drivers and they prefer stability ,quality long product support cycle of the video card and drivers rather than performance and features!

Are there conflicts for Java3D to based on stable JOGL and maybe consolidate Java3D and Xith3D? I would like to see this happen! However, since JOGL is not on the JSR route, it seems not possible from this point of view!

If Java3D is used mostly in visualization applications then I think portability is more important than gaming speed. This is only an assumption but maybe a poll could reveal how Java3D is actually used.

One of the main reasons to use Java in the first place is the promise of portability. But as it stands now Java3D limits an application to be used only on a few platforms.

I think an easy to port pure-Java/JOGL version would position Java3D better for the future than special adapting for gaming.

But maybe the differences between the two projects are far bigger than is seems at a first glance when looking the API.

First, Xith3D is not bound to any specification process nor has it guarantee some API stability. So it can (and does) move quickly, always catching up with state-of-the-art 3D technology.

Second, performance and predictability are a direct consequence of being singlethreaded and targeted to a certain way to deliver the pictures (no caves, single CPU, medium scenegraph size, ... or so).

So there are conflicts in the basic goals and requirements that will make such a process hard, if not impossible.

I feel the xith3d guys don't feel any need to do so. They are happy with their stuff. So it would be Sun/Java3D that has to move and try to integrate. Its the Java3D community that wants to have a well-performing 3D API provided as a Sun-supported standard. So it is about ... us?

Same holds for jME me thinks, which also is a highly remarkable effort!

Yes, having been flamed on the Xith3D forums, perhaps I should rephrase my question as:

"Isn't there a strong case for Java3D to adopt the Xith3D goal of making performance a higher priority?
Would it be possible to have a single API with differences in implementation to accommodate different uses (e.g. Herkules mentioned support for CAVES), hidden from the user, with options specified by flags or included as extensions?"

No flames here, but I would say no, there isn't a strong case. j3d is an API as well as an implementation, and you're more than welcome to take the implementation source and optimize it to perform better for hardware N in the event it doesn't do so well there. But the key requirement from the developer's standpoint is that it is conformnt to its API. Imagine them having to prioritize and rewrite (and test and maintain) significant parts of the internal scenegraph for every OS and piece of hardware on the market, with everyone screaming "me first!"
Its easier to accept that it already is a "good performer" for most common hardware and if you need a "great performer" it makes more sense to suck up some of the tradeoffs from some other API or library like xith3d, or simply modify what our friends at Sun here have done for your own case. If you're *really* serious about milking performance for a given set of hardware (you want to compete with Epic), its really something you've got to do by implementing and optimizing a custom scenegraph yourself in jogl or other low-level bindings becasue a vanilla scenegraph just can't keep up with everything (for example, see what JC and AH have done with aviatrix).
The strength of j3d is it is excellent for "rapid prototyping" and developing small to medium 3d visualization applications. Which is to say, one doesn't need to spend alot of time worrying about implementing a scengraph framework to see something 3D in Java. While its great to think that I could be getting 300fps while I rotate a teapot, the short of it is most j3d apps would benefit way more from new scenegraph features or bugfixes, becasue the performance is good enough.

Hi,
I can see that performance isn't necessary for all applications - for example the visualizations programs that you talk about.

My point - poorly expressed - though is that can the 3D Java community sustain two different though similar scenegraph APIs in Xith3D and Java3D?

Sure, Java3D has been resurrected by Sun (mostly I imagine because of Project looking Glass) and has assigned some staff to it - who are doing sterling work - but it is clear that, by making it open source, Sun are hoping most of the development for Java3D will come from the community.

During the two years that Java3D was neglected, many people went off and either built their own APIs (Aviatrix, Xith3D) or even abandoned Java for C++.

Since Xith3D has roughly the same object model as Java3D, it shouldn't be too difficult for those people wanting to build a quick prototype or a small-medium visualization to do so using Xith3D. (The faster performance won't hurt them).

The people who need the multithreading, the more sophisticated, larger scale visualization toolkit seem to have abandoned Java3D altogether now anyway.

So, my argument would be that by all means let's maintain Java3D for those that need it as it is now, but that we should pool the community's new development work and channel it into Xith3D. Xith3D has roughly the same object model as Java3D, so can be as quick to build apps with, but also has the other advantages for those that need it of faster performance and easy access to OpenGL.

This should also be backed by Sun - who stand to gain by having a 3D scenegraph API that people are actually using to develop all sorts of applications - including games.

I should not have used the word "merge" for Java3D and Xith3D. Maybe what I should have said is "merge the new development effort".

Let's bite the bullet and move development to Xith3D.

(Controversial I know but worth discussing, eh?)
-Paul

PS I began a similar thread on the Xith3D forum.
Apologies if you read both. If you don't but are interested, follow this link:

>My point - poorly expressed - though is that can the 3D Java community
>sustain two different though similar scenegraph APIs in Xith3D and Java3D?

I think so, actually, if you rummage around, I think you'll find it can
sustain substantially more than 2 scenegraph APIs, of varying degrees of
similarity. Also, take a look at XML parsers and APIs supported by the
Java community, and you can get a feel for large and diverse API
economies. I see a split as a good thing for things with open source,
because it allows both sides to leverage changes made by the other(s)
(perhaps not directly, but from a "what's going on over here?" POV. I see
the BSD flavours (and linux, now that I think of it) being fine examples of
this.

>Sure, Java3D has been resurrected by Sun (mostly I imagine because of
>Project looking Glass) and has assigned some staff to it - who are doing
>sterling work - but it is clear that, by making it open source, Sun are
>hoping most of the development for Java3D will come from the community.

Sun does this with a lot of their stuff. You can pay for quality, but if
you don't have to, why bother? This is a new trend, not widely adopted
yet, but IBM and a few other companies do it too. The real problem here is
that the API wasn't implemented by anyone else like they were expecting it
to be (short of Xith as a partial implementation), so in lieu if that to
keep it alive, they had to shift how its "being done."

>During the two years that Java3D was neglected, many people went off and
>either built their own APIs (Aviatrix, Xith3D) or even abandoned Java for C++.

And? I don't mean this facetiously, but so what? Having options is a good
thing. Since then we've seen jogl and all that's come from that too. C++
people will come back for the next project, or move onto .Net because C++
sucks any way you slice it. People will ALWAYS build their own APIs, for
the simple reason that they can do better, or at the very least create a
tradeoff that suits them better.

>Since Xith3D has roughly the same object model as Java3D, it shouldn't be
>too difficult for those people wanting to build a quick prototype or a
>small-medium visualization to do so using Xith3D. (The faster performance
>won't hurt them).
>
>The people who need the multithreading, the more sophisticated, larger
>scale visualization toolkit seem to have abandoned Java3D altogether now
>anyway.

Well, yes and no. I don't think its a set of absolutes like that. The
right tool for the right job and all, and people stay abreast of what
toolkits can and can't do every time a new project comes up.

>So, my argument would be that by all means let's maintain Java3D for those
>that need it as it is now, but that we should pool the community's new
>development work and channel it into Xith3D. Xith3D has roughly the same
>object model as Java3D, so can be as quick to build apps with, but also
>has the other advantages for those that need it of faster performance and
>easy access to OpenGL.

It lacks the backing of a big company. If you've never had to explain your
toolkit choices to the complete non-techie who pays for what you're
building, and requires accountability and hardcore QA for everything,
consider yourself lucky. Companies don't use linux, they use Red-Hat or
SuSe, and 5 years ago, they wouldn't even go that far away from Windows or
Big Name UNIX. If someone finds Xith does something important better than
j3d, they'll move (and vice-versa), but no one needs to be pushed either way.

>This should also be backed by Sun - who stand to gain by having a 3D
>scenegraph API that people are actually using to develop all sorts of
>applications including games (and 3D games on small devices are coming).

They've already got one. Its got patents and everything. Some people
don't like it. Some people do. If people don't move to Xith, because j3d
works for them, you can't blame people. See the beauty of choice?

>Sun do not want to splinter Java - why splinter 3D java?

What are you talking about? Sun is more than happy to have others create
their own Java implementations (though if they want to call their creation
"Java," it is subject to a long list of requirements). There's more than
one GNU "not Java", the IBM JVM is great, the Microsoft JVM is not, (it did
perform well when doing AWT/Swing, but if you can't play by the rules and
stick to a spec, expect to get burned). Again, choice is a good thing,
monocultures are not.

>Let's bite the bullet and move development to Xith3D.

Really, power to those who do, but its not going to happen anytime soon.