looks like we have some competition

Engines, Libraries and Tools Xith3D Forums
#1

Now with Java3D looking to be maintained again and open sourced, together with the new (well not very new) Mac OS X port - it looks like we may have some competition again.

All the more reason to focus Xith3D more on real-time/game applications I guess.

An interesting thought: I guess it would be quite possible to have a Xith3D<–>Java3D compatability layer with the scenegraph package, so even with the differences between Xith3D and Java3D in relation to the scenegraph API - people could still use the increasing number of open source Xith3D tools (eg. loaders) with Java3D.

Will.

#2

Programmable shaders…
Sigh, thinking about how Yuri and myself had some shitty time trying to get them up and working to only hear that sun will come up with em…
Oh well, still, Xith is faster than Java3D :slight_smile:

#3

Well, I think SUN’s announcement on Java3d is great. Like William, I think it’s a shame however it took so long until SUN said a single word. :frowning: Still, that’s been the past, let’s be positive for now and the future.

There’s some competition now, but both APIs target somewhat different “markets” I think. Isn’t it?

#4

I don’t think so. If Java3D is under the hood of Doug now who is member of the GTG, a strong focus on gaming will result. This is reasonable bc. gaming is the biggest consumer of 3D stuff at all these days.
And thats a direct competative situation!

#5

there would be qn interest in competition if you could not change the way others go.
Depending on the licensing and scheme J3D might get, you might be able to do in J3D what you could not before. Xith was started to have an evolving j3d, adapted to gaming. if the new scheme permits to have impact on j3d, you can make xith’s existence point moot.
why scattering energy? proudness?

#6

(I’m moving this article from the other J3D thread in the Xith forum to this thread here so that focus doesn’t get lost…)

Well, good questions, good points. Let’s wait and see what the Xith3d experts say.

From a (Xith3d) user’s point of view I think a main difference would be the gaming concentration of Xith3d, and the difference between a real OpenSource project (like Xith3d) and a Non-OpenSource-but-with-source project.
Because Xith3d concentrates on games, it can be explained why Javacooldude’s demos are typically over twice as fast with Xith3d compared to the same demo with Java3d.

Also much will depend on the concrete licence for Java3d. This still seems a little bit unclear. According to SUN’s announcement on Java3d the code will be released under SUN’s “public source license”, but some articles later Dough writes. [quote] “It has not been completely worked out yet. It will most likely be something in between SCSL and BSD. We are trying to make it easy for developers to do what they need to do, but still maintain compatibility.”
[/quote]
William’s point about the 3d model loader front is a good one. Let’s join forces, where possible. (Loaders, Geometry utilities, etc.)

#7

[quote]Programmable shaders…
Sigh, thinking about how Yuri and myself had some shitty time trying to get them up and working to only hear that sun will come up with em…
Oh well, still, Xith is faster than Java3D :slight_smile:
[/quote]
the time you spent might not be wasted for java3d. your experience in adding and handling the shaders will be very valuable.
merge merge merge…

#8

[quote]I think it’s a shame however it took so long until SUN said a single word. :frowning: Still, that’s been the past, let’s be positive for now and the future.
[/quote]
As Harri Seldon said, the past is often a good indication for the future…

#9

My sentiments exactly.

I think Xith3D will still definitely be relevant as it is less tightly controlled (no JSP’s for one…) this means that development can be much more rapid. With the BSD license if you don’t like something, you’re free to fix it!

For me and probably many using Xith - sun’s gesture is too little too late, we’ve already moved on.

One thing that would be nice would be if we could license their Javadocs off them 8) That all depends on what license they use I guess.

Rather than speculate on what J3D can become, I’ll still continue to use and develop Xith3D. Sharing of knowledge and Ideas between the projects (which is currently the case, albiet one way) would be good however.

Will.

#10

I expect the sharing of knowledge will be largely like having a conversation with a brick wall.

Now’s the time for Xith to concentrate on it’s USPs. We understood that we had to do this with LWJGL to make it a proper alternative to JOGL/JOAL/JInput, and we settled on the following in order of most important first:

[]Compatibility - we wanted LWJGL to be compatible with more systems than anything else
[]Reliability - we are committed to making sure our API works as expected and doesn’t hide any strangeness on both supported and unsupported systems
[]Performance - we want to be the fastest API there is
[]Size - we wanted to have an ultra-small API
[]Simplicity - we focused on gaming, which allowed us to cut out a lot of rare special cases or pointless interfacing
[]Completeness - we wanted everything required to write games; but for the sake of simplicity, we’ve thrown out a lot of stuff

etc. and now it’s time for Xith to set its own criteria that makes it better for the job than Java3D. So let’s hear it here:

What are your goals for deployed size?
What are your goals for performance?
What are your goals for completeness? (i.e what do you plan to be able to do in the core library?)
And most importantly how do you compare to Java3D on these points?

Cas :slight_smile:

#11

It’s quite typical for Sun to say nothing for months/years and then let the bomb explode. It’s probably not a bad thing, that Java3D is Open Source, but why didn’t they try to communicate with us (the JGO/Xith3D people)? I think they wanted to have everything sorted (this process always takes at least months no matter if it’s simple or not) before they say anything. The people working on Java3D probably know Xith3D and other APIs (OpenMind), so it would have been nice to discuss a strategy which helps Java gaming and not only individual APIs.

#12

[quote]I expect the sharing of knowledge will be largely like having a conversation with a brick wall.
[/quote]
:slight_smile:

[quote]What are your goals for deployed size?
[/quote]
AFAIK we do not have explicit goals concerning the size of the codebase, but we’ll probably continue our way to be modular and offer choice. Jogl/LWJGL for rendering, JavaSound/Joal for Sound, Swing/SWT for the userinterface, own collision system/ODE for physics etc.

[quote]What are your goals for performance?
[/quote]
Currently we are ahead of Java3D in this aspect and this probably won’t change very soon.

One of the main problems is that the market is small and every project will only have a small number of core developers, even if our goals are clear.

#13

I think I’ll stay with xith3d. I’m less likely to hear that some idea is not possible to implement because we need to support some 15-year old Sparc machine with ugh-ugh GPU. Or that fixing some not-so-obvious bug will break too many applications, so it has to stay this way. Consider turnaround time for changes/RFE for JDK on bug parade versus time for getting things done in xith3d. I don’t want to care too much about millions of people already using this API - with xith3d, they just bundle given version with their app and don’t care if next update will break their application - if they do, they can as well fix few things if they need extra functionality coming with next release.

For me, xith3d major strength is that it is not standard extension, it can be bundled with application - thus evolve faster. For other areas of programming, it is not as important, but given the speed of changes in GPU/gaming market…

#14

[quote]For me, xith3d major strength is that it is not standard extension, it can be bundled with application - thus evolve faster.
[/quote]
Similarly, J3D is going to need to be webstartable before I even consider using it again.

#15

[quote]I think I’ll stay with xith3d. I’m less likely to hear that some idea is not possible to implement because we need to support some 15-year old Sparc machine with ugh-ugh GPU. Or that fixing some not-so-obvious bug will break too many applications, so it has to stay this way.
[/quote]
According to Doug’s post,

[quote] . We also want the expert group to help define the next major
revision (1.5? 2.0?) to the Java 3D API, which could involve
more widespread changes to the API.
[/quote]
Which means that changement is already on the list.
It’s time to be involved in JCP, don’t you think?

#16

I think at least for now Xith3D is worth sticking with, maybe getting envolved with J3D 2.0 is worth doing, I’d personally like to see people like David and Yuri envolved with the JCP for J3D 2.0, I think then we could save some of the duplicate effort and get a more common approach with the speed we need. 2.0 sounds like it will be the bigest change and it maybe possible to redirect it’s target more towards performance and gaming in particular, especially with the other members of GTG part of the J3D process. If nothing else, it could be an interesting few months (or years as this is sun we are talking about :P)

Endolf

#17

Imagine a Java3D 2.0 compatible with DX 9.0
Sweeeeeeeeeet ;D

#18

[quote]Imagine a Java3D 2.0 compatible with DX 9.0
Sweeeeeeeeeet ;D
[/quote]
Why?

I use under windows and Linux, DX support is irrelivent to me :slight_smile:

Endolf

#19

Fact that they want to change something doesn’t mean that supporting 15-year old Sparc machines will stop to be a priority. Of course this 15-years old Sparc machine argument is just a fake example, they are probably 17-years old by now… :wink:

My point is that Sun will try to appeal to as many customers as possible. This means that j3d even in 2.0 version, cannot be really game-oriented api, because it also has to be a viable choice for CUBE studios and non-gaming, low end integrated GPUs. Unless I’m wrong and Sun WANTS to convert j3d to gaming api, not just something that can support gaming as side effect - but then, we can as well start with xith3d code as with old java3d code.

#20

[quote]Unless I’m wrong and Sun WANTS to convert j3d to gaming api, not just something that can support gaming as side effect - but then, we can as well start with xith3d code as with old java3d code.
[/quote]
Well. Xith proved quite nicely that an api based on J3D’s architecture could be expandable and adapted to gaming. Lessons may be taken (and might already, who knows) to adapt that to J3D. Actually, gaming initiative has bindings to low level gaming elements, but no official higher level glue exists. J3D might fill the hole nicely if correctly adapted.