Hi,
I’ve started a thread on merging Java3D and Xith3D at:
http://www.javadesktop.org/forums/thread.jspa?threadID=5776&tstart=0
Please contribute your thoughts there.
Thanks,
-Paul
It requires yet another sign up - yet another dumb-ass login and password and email address theft.
Are you sure that’s the best place, seeing as Xith’s main discussion areas are here and xith.org, and “java-gaming.org” would seem a sensible place for such a discussion even from J3D’s perspective?
OK, but that’s an example of the two sides not communicating/following eachother’s work.
You can probably guess what I’m suggesting from the subject but here is a copy of my post:
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?
Anyway, just a thought for a Friday…
-Paul
(having read the other thread)
This seems a stupid idea, IMHO. Your suggestion appears to be based on little knowledge of the differences between the API’s, and zero knowledge of what it would take to “merge” them.
Your question “should we not be uniting the two implementations of what is essentially the Java3D API?” is bizarre. If they are alternative implementations of the same API then aren’t they already as “merged” as they need to be: that is the purpose of having an API: it lets you have multiple unique implementations?
What do you feel is wrong with Xith that would be solved or improved? And how do you think that would be achieved by “merging” with j3d? And what form would the merging take? (since they are the “same API” already I find it hard to understand how they could BE any more merged than they already are!)
By the “same API”, I’m referring to the fact that Xith3D has intentionally followed the same object model of Java3D.
I acknowledge my naivety when it comes to understanding the detail of the two implementations, however, it still seems to me that there is so much in common that there is room for a single larger project that encompasses the features of each as a set of options or extensions.
I actually like the performance goals of Xith3D but prefer the stability, robustness and (now renewed) support of Java3D.
If it cannot be done or if people don’t want it to be done, that’s fine, but surely it’s legitimate to pose the question without receiving such a torrent of abuse.
Cheers,
-Paul
Here is my answer from the Java3D forum:
[quote] Of cource you get my vote for that.
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!
[/quote]
I agree my response was not welcoming and happy and wonderful, but it was hardly a torrent of abuse.
To be honest, your suggestion is one I find mildly insulting to Xith, in that it ignores most of the purpose and value of Xith, whilst failing to acknowledge that Xith is doing an excellent job DESPITE the lack of help from Sun (not that I’m attacking Sun here: I’m merely pointing out how well it’s doing without being propped up by Sun…).
(much as the jME guys were mildly insulted when I first said they “lacked documentation” ;D)
I’m sorry that I initially mistook your suggestion for something that you’d thought about a lot and knew what you were saying - and judged it on that basis. You still haven’t described what “merging” you intend nor given any reasons for it, and now I realise belatedly that this is because you don’t know much about the two techs. I suggest you read up on the very early info about Xith which tries to explain it’s purpose, aims, etc - this may help you understand the differences better. You may also want to read the thread on this board that was started when j3d was resurrected; lots was said about various options that xith could take at that point.
I’ve read the threads and articles that you mention.
It seems to me that the main difference is the threading issue that I mentioned in my original message. Surely issues about licencing can be overcome with willing on Sun’s side - which would be needed for my proposal to happen anyway. The other key difference, that I see, is that Xith3D is implemented on top of JOGL allowing direct access to OpenGL which I see as another good thing.
I am not actually criticising Xith3D (so there is no need for you to be so defensive). In fact, quite the opposite - I am all in favour of the development of a 3D scenegraph API in Java that has performance as one of its primary objectives.
OK, let me rephrase my original question:
“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?”
(By the way Blah, Blah, the “I” in API stands for “interface” - the similarity in the object models is why I said the “same API”)
Thanks,
-Paul
-1 on this idea. If Java3D needs to be improved then the caretakers of that code should improve it. Xith solves a specific set of problems and should stay focused.
- The above is my opinion and is not intended to offend anyone.
[quote]I’ve read the threads and articles that you mention.
[/quote]
OK.
But what about the most important of all: the use-cases? There is little crossover between the use-cases for the two techs, less if you look only at what their “main” audiences are (Sun has made it abundantly clear that they don’t consider games-development a high-priority, both in the design of j3d and in recent statements about where j3d is going; c.f. j3d developers’ statements about their belief that j3d and xith should continue - in parallel - unchanged, because they had such different targets)
Yet many of us (sometimes it seems most?) want xith-on-lwjgl too - and many have stated they’d use the latter in preference once it was available.
Here’s a great example of the fact that both techs have completely different audiences: it’s no problem for xith to run on lwjgl, both are aimed at gaming, and to end up with the extra stuff that lwjgl drags with it apart from the ogl-binding is fine for xith, because you probably want it anyway.
Whereas j3d doesn’t have a justification for running on lwjgl, and sun probably wouldn’t be too happy (they would prefer people to be using JOGL - fair enough).
No, but you did appear to be damning with faint praise…
ISTR xith has performance as its ONLY primary objective (aside from method-signature compatability with j3d)?
Putting it that way…what does this have to do with xith at all, except as source code that Sun could copy, licensing permitting?
I’m still struggling to see the reasons why this would be desirable, beyond the implicit “fewer API’s with same number of total developers == better tested more featureful API” and the explicit “j3d could be much faster”.
Thanks zparticle,
That is really my point. I do think Java3D needs to be improved. I cross posted here to try and garner some support.
If the performance of Java3D was good enough to support the development of games, would Xith3D have been born?
Now that development on Java3D is starting up again, the reason for my post was to suggest that it draws from the great work being done by you guys with Xith3D and thereby address the primary issue in my mind - performance.
Having said all of that, I do appreciate the point that performance isn’t necessary for everyone’s application. But surely, optimizations etc. for different purposes can be done under the hood and selected by flags or implemented as extensions.
Let the application developers have one API and switch implementations at runtime.
-Paul
ps no offence taken :-X
What kind of performance difference are we talking between Xith and J3D? Can someone drop in some numbers or maybe there was a thread elsewhere on this.
If memory serves me correctly, Xith got started simply because Java3d was effectively dead and several peeps had been developing games/etc on Java3D. They needed a live API and wanted more FEATURE advancement, and since J3D was “in a holding pattern”, one possible solution was to make a new independant Java3D.
Correct me if I am wrong?
On topic…
Isn’t the biggest gain from unifying Xith dev and J3D dev simply is that there would be a bigger, better pool of developer resources?
[mod spelling]
[quote]What kind of performance difference are we talking between Xith and J3D? Can someone drop in some numbers or maybe there was a thread elsewhere on this.
[/quote]
I believe Java Cool Dude did some comparisons with some Java3D demos he ported to Xith3D and the result was that Xith3D was indeed much faster. There is a thread on it somewhere with a frame rate comparison. I believe David found that magicosm ran faster too.
In theory, Xith3D should be faster due to the fact it is single threaded. If in fact it isn’t then it probably just needs to be optimised. My understanding of Java3D is that there is a lot of internal message passing to enable the scenegraph to be modified while it is being drawn.
Xith3D/LWJGL is available. It isn’t as fully supported as the JOGL version currently, but it does work. The more people that use it the better it will be supported.
Will.
(this thread is everywhere! Going to reply here as the bulk of the responses are here too).
Shawn, the numbers I remember seeing were indicating at least double the framerate. This feels about right because our AV3D scene graph is getting those sorts of numbers as well.
As for the basic premise of the thread: No, there would be nothing gained at all. Xith3D and Java3D are at the opposite ends of the spectrum. They share the same API, roughly, but the semantics are completely different. Xith3D could not pass the J3D TCK test, and probably never would. If you were to combine efforts, there would have to be one winner. Either everyone develops Xith3D or everyone develops Java3D, and there’s no crossover. The architectures are like chalk and cheese. It’s not even possible to take the code from one and munge it to fit the other.
Hi,
I guess that’s really what I was trying to say in my original post but didn’t phrase it very well…
(“merged” was totally the wrong word to use - or at least I should have said “merged the new development effort”)
Both Mithrandir and Shawn expressed it better than I did.
Given the limited number of people available to work on developing both Xith3D and Java3D, wouldn’t it be better to put all of the development effort into one project or the other?
Now the problem becomes “which one?”
Java3D was neglected by Sun for a couple of years. I would argue that that neglect and its relatively poor FPS performance for games led to the birth of Xith3D. Of course, Xith3D has other advantages - it sits on top of JOGL/OpenGL or LWGJL allowing access to those.
Now Java3D has been resurrected. And all those people doing scientific visualization or work in CAVEs etc where multithreading is important will say that they don’t need the games level performance of Xith3D. But it also strikes me that many people who do that kind of stuff develop their own APIs anyway (eg Aviatrix3D from the J3D people), or had left Java3D during its demise.
But although Java3D has been resurrected - and even though there is Sun staff working on it - and doing a great job - there aren’t many of them and Sun’s hope is clearly that it will mostly be developed through the “community”.
My point - had I expressed it better - is can the community develop two different though similar 3D scenegraph APIs? (add in a third with JME, a fourth with Aviatrix, any more?)
My own personal preference is that all the effort goes into Xith3D but I’m biased because I develop desktop applications. Even now and even as a big fan of Sun (cf IBM/Microsoft) I also wonder about Sun’s long term support of Java3D - I wonder how much of the current support is wrapped up with Project looking Glass.
So, I would say that the community should maintain Java3D for those that need it as it is, but that all new development effort should go into Xith3D.
Xith3D has taken the object model from Java3D because it was extremely well designed. But it’s moved things on. It’s now added faster performance. Its provided the flexibility of OpenGL calls. The Java 3D development should all be going into Xith3D and that should be backed by Sun.
I hope this clarifies,
-Paul
Not really
Are you suggesting some sort of mandate to the community at large as to where they spend their efforts?
At the end of the day community effort is driven by need, people that need Java 3D to be fixed and/or improved will do so. Likewise Xith3D.
I for one am not really sure what changes you’re hoping to achieve?
Kev
Hi,
I wouldn’t dream of mandating anyone.
I agree with you to a large extent. However, I also feel that many in the 3D java community will stay with Java3D simply because that is the Sun backed project. Whereas, I think Xith3D could still satisfy their requirements.
I think more could be achieved - for everyone - with a single united effort - backed by Sun. Or at the very least a lot of cross-pollination of common aspects.
Anyway, it’s just an opinion, a thought, not a mandate.
-Paul
One of the advantages that Java3D has, and why people would stay with it is that it is not open source. There’s a big specification process around it, and for them, stability is more important than features. There isn’t different versions of the API every 2 weeks and changes come once every couple of years - which is good enough to fit within their development cycle.
Hi,
If nothing changed since Java3D has been “open-sourced”, then the licensing is a biggest issue for me. In fact, the Java3D license prevents me from distributing modified version of it with my app, even if it is not interfering with the other apps on the system.
For me licensing is a biggest point even to start any effort in the Subj direction.
Yuri
OK, I’ve got you now.
A question which many asked when Sun resurrected j3d, and the cynical often felt Sun had decided to conveniently ignore for reasons not much more complex than NIH syndrome. I can’t speak for j3D users, but I agree with your guess that many of the primary j3d audience appear to have migrated to other things during the years of drought. I would love to know how the landscape looks there (and I’m glad we hav people like Mith around here so we at least get a window onto that perspective - the other scivis people I know (mostly chemists) don’t use java at all, so they’re no use :))
Which, if you ask me, is too little too late (from sun). 5 years ago that might have been a smart idea. Nowadays many people have given up on the train-wreck that j3d became (unsupported, underfunded, unmarketed) - and many have found other alternatives.
If I were deciding which oss API to contribute to now, I’d pick Xith over j3d instantly - I trust that an API which was founded out of frustration and a demand for higher performance has more of a future than one that got cancelled for a long time and then resurrected without much clarity of vision. Shrug. IMHO.
But I’m not in the target audience for j3d so - fair enough - I’m probably missing the point ;).
My guess is that Sun will have a hard time getting people to work on their API. Trust and respect are important aspects of oss development, and even if Sun had veritable saints working on j3d now it’s still hard to trust them - because it’s not hte people that get to pull the plug in 12 months time if it doesn’t work out, it’s those higher up the food chain.
Now, if j3d were being championed by a senior exec, and had a huge marketing drive, things would be different. But as it is it would still be relatively easy for sun to sweep under the carpet in a few years.
I did wonder if j3d is part of a new “experimental” strategy from sun: Take all those things we had that were popular (but we didn’t really listen) and which we massively under-supported and under-sold (too little marketing effort etc), bring them back to life, and give them a couple of years to bear fruit. If not, kill 'em again.
The biggest example would be Solaris (on intel) - my free CDs of which Sun still hasn’t sent me from several years ago (lookup the news stories about cancelling solaris on intel and what happened next)
You sound like you’re evangelising xith, which imho makes more sense than your original thrust. Basically, for “normal” (non scivis) users I find it hard to understand how j3d is anything but a vastly inferior option to xith (performance, support, stability, trust, etc - e.g. the current build of j3d keeps crashing my OS!).
I couldn’t see in the first place what possible benefit xith would have with any closer alliance with j3d, beyond marketing. If sun would market xith side-by-side with j3d, that would be a massive boost - but then I believe people would flock to xith, and sun seem to have difficulty accepting that kind of scenario.