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.

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

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. :-( 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?

There's some competition now, but both APIs target somewhat different "markets" I think.

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!

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?

(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."

William's point about the 3d model loader front is a good one. Let's join forces, where possible. (Loaders, Geometry utilities, etc.)

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

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....

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 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.

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?

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.

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

:-)

Quote

What are your goals for deployed size?

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?

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.

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...

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.

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.

Which means that changement is already on the list.It's time to be involved in JCP, don't you think?

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 )

According to Doug's post, Which means that changement is already on the list.It's time to be involved in JCP, don't you think?

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...

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.

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.

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.

> 6 months ago when I last looked at Xith it was too immature for me (I've lost too much time to immature libs that wasted my time with bad docs and worse code ).

I was already starting to re-appraise that when the Sun announcement appeared .

Quote

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.

I agree this is a valuable feature; interesting to compare to how much Sun could achieve similar with J3D given their strategy to be very cautious on what they allow people to redistribute.

Speaking as someone who's had about 20 bugs accepted by Sun on standard java - including more than 5 on the JVM or core tools (javac) themselves - I've gained the strong impression that Sun's unit testing and regression testing systems for java are mediocre.

So, having fine control over what version is being used is important to me, but...not if the cost is having every game app require an extre X Mb of space that is really duplication of what should be a shared library.

Quote

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...

But...for me (and presumably many others?) making maximal use of shared libs is often more important. Bascially, my ideal is a webstarted game that allows any shared version of X3d - but if I discover an incompatibility with a version, being able to exclude that particular version in the JWS.

Quote

Similarly, J3D is going to need to be webstartable before I even consider using it again.

Ditto. Cannot underestimate the value of this! JWS was always an idea that had massive potential but was let down by dreadful implemntation bugs; now the tech is (slowly) catching up to the potential, it's becoming indispensable for many people.

But...for me (and presumably many others?) making maximal use of shared libs is often more important.

Jogl can be shared. As for the xith3d - how big it is/will be without jogl/jaol/jinput ? 1-2MB ? I don't think it is a problem for 3d game, taking size of textures/models/music into account. But I agree that for small demos, it can be a difference. In such case, sticking to 'shared' major xith3d releases which can come once per 4-8 months should do the trick. I'm mainly taking here about ability to make breaking API/behaviour changes after half a year, without breaking all application developed so far in the process.

Think how could jdk 1.5 look like if there would be no need for backward compatibility. In case of jdk, having per-application jre is too much. In case of games, having per-game xith3d... looks perfectly acceptable to me (especially if it is per-game/demo-from-given-half-year-period).

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

I'm offering a response to this ONLY because I'm someone who has NEVER adopted X3d, so I represent a part of the target audience which perhaps is under-represented in this forum .

Issues for me with java3d (note: I'm aware some of these may no longer be the case, but I couldn't afford to keep re-trying every week until they got fixed!)

First time I ran the j3d demos on NT with a G200 I'd just been playing Q3 on...they rebooted my PC. No BSOD - just a reboot.

Checked release notes; found lots of comments about how different graphics cards would BSOD with the J3D release. This is an absolute show-stopper - I can't afford to cut down the audience for my games and I can't afford the perception that my games "are crap; just don't work at all" on what was for a long time a common 3D card.

A few releases later (I think 1.3.x) tried again, and found that the demos now worked, but the app would often crash after anything between 15 seconds and 3 minutes. Often = most times you ran it. Again, completely put me off even trying to use the API.

Architecture: lots of good bits, but lots of unnecessary fuss that just got in the way. If I'm going to use a high-level API for development it damn well better let me get a good-looking (if boring!) app up and running very fast with very little fuss. With j3D this could probably have been solved with two things: better tutorials (+ easier to find tutorials!) and some base classes that made getting something *significant* of your own up and running much quicker.

Sun's clear shunning of the API was a major problem. It was always buried deep in the site, and other parts of sun.com and articles etc wouldn't even mention it. Every announcment about j2d seemed like they were further putting the boot in on j3d. No way I can afford to go with an API that even it's developers / owners hate.

Distribution. If a 3rd party API is not easy to include in webstart then I can't use it; just too much hassle - and advising players on how to install 3rd party native libs is far beyond my resources (note: I couldn't even do this myself if I needed to; all I know is that I'd have to search through old emails on getting LWJGL to work because on linux the obvious behaviour is either broken in the Sun JVM or just not there by design ).

Stability. J3D always gave me a consistent impression - largely confirmed by the release ntoes - that the code was utter ****. No defensive programming, no ability to recover from errors, just simple "oh my! Something went wrong! Quick, lets call System.exit()!". Whilst I was always aware that my most severe problems were driver issues none of the players of my game will know that. And my app should never just bomb; all errors in the library should be handled as gracefully as possible - I don't care if the entire 3D rendering has to be disabled in order not to crash the app; at least leave my player with something rather than a slap in the face . Nowadays I employ the default ThreadGroup when creating threads, which let's me automatically catch even uncaught exceptions in 3rd party code; so this is less of an issue for me, but probably still a big problem for other people (I can print an error message making a guess at what went wrong!).

Glacially slow progress on improving things, making new releases.

I hope that's of some help - the ignorant, naive view, if you like .

As an aside, although it sounds great that x3d concentrates on games development, that often makes it more desirable for non-gaming uses than a generic API. Lots of apps are run on normal or poor workstations and *desire* similar performance to a game. I even know some researchers to whom a rendering API tagged "for games development" is instantly more attractive - they expect they'll get something leaner, less patronising, more widely used, better tested, etc. AND (and this is a biggy) the tutorials tend to cover a wider range of abilities - game dev libs tend to get used by "beginners with lots of enthusiasm" and you don't tend to get the situation where the docs are all designed at experts only.

backward compatibility. In case of jdk, having per-application jre is too much. In case of games, having per-game xith3d... looks perfectly acceptable to me (especially if it is per-game/demo-from-given-half-year-period).

Sure. I'm just trying to point out that I very much want *both* options, not just one. So long as I can, as I said, "blacklist" any versions that turn out to be dodgy .

Please take WHoW into your concerns also-What are your goals-How do you want to reach them and-Will it be easy to achieve

Speaking for myself only any engineer/programmer/Developer should ask him/herself these questions and decide what to use afterwards.

Not the pure amount of features counts, not even the number of developers of the core product nor the bloomy promises given by anyone. I really dislike these me-too effects to implement any feature here and any feature there - a behavior we can see in so many fields.

You may ask why? Let me answer with another question: Anyone using MS Word? Ever wondered why they could not stop implementing new goodies (being required by nearly nobody) but not fixings annoying bugs for versions? And Sun in some cases is doing the same - I always wonder if a bug I reported in JDK 1.1.8 will ever disappear ...

Doing a good job is essential in todays times to shorten development cycles and getting USEFUL code. Therefore evaluation of any third party lib should take its time. Weight the pro and cons!

Oops - forgot something: I have not said anything that is related to Xith vs J3D in special.

Okay, you got me

Let's start back some years. Around 1992 I was using an Amiga (no flames please) and got a 3D construction kit - anyone remembering that one? It was nice for the first steps but somewhat limited in speed and complexity. So I never got far with it. Some years later I got the A4 engine (this time on the pc) from a small but committed german company. Solid power for cheap. And it had its own scripting language making it easier to adopt further complexity. Then Java 3D was around and I had already switched from C++ to Java. So I gave it a try. It ran - no crashes but in my eyes it was too slow for my purposes. And I missed some tools and tutorials for easy understanding. Good tools are essantial for any product - nobody wants to place all objects in code but have the possibility to separate virtual worlds from the coding part (programmers and world designers often can produce astonishing effects in their special fields).What I have been looking for is not a simple click'n'point tool for creating virtual worlds - that is easy for the first steps but IMHO limits you afterwards. I do need the full control in coding anything that is missing and like to add features I do need - even for the costs of additional hacking.

When I found a pacman game in 3D running upon J3D I decided to test Java's capabilites again. To make it short it was awesome in a way that it worked - but at what costs. Running at 2 Ghz on a Gforce 3 I saw a performance that was less than desired for the worlds I wanted to create.

What to do? Giving up? Nope. Searching the internet I found some other approaches using native libs beneath. There I noticed a significant speedup (based upon Jogl, Lwjgl etc.) And around last christmas I tried Xith3D. Though it lacks some additional tutorials, source code documentation and even books dealing with it - btw. a Xith cookbook would be fine - I admire its solid base and commited coders. The forum contains several invaluable advices, hints and examples that helped me to cope with the problems I stumbled in.

As a result I do not see why to leave Xith at this very moment as it features speed and produces this one-more-step-effect that lets you push the limits even further.

Hi Java3D *could* be webstarted, but I was always wary of the license, and what must be shipped and want doesn't have to be. It's been a while but I was also not sure on what to do with the license texts, you have to ship them, but where do you put them in a jws world, bury them in a jar somewhere?, i'm sure sun would have loved that . Xith on the other hand was much nicer on the licensing issues alone

Well, y'all want a good differentiator for Xith: put it on top of LWJGL, and integrate it tightly. Make it Just Work. Don't arse about with all this pluggable renderer bollocks. Get one case working 100% brilliantly. It's what we designed LWJGL for after all. It's the raison d'etre and all that. If there's one thing I, as an actual developer of games, really hate - it's having to wire tons and tons of stuff together in fiddly ways with libraries and connections and version compatibility nightmares. I just want one solid platform from which to work and do everything.

I know I'm strongly pushing my own agenda here but then why would I push anyone elses?

I'm sure that a SUN official OpenGL binding like Jogl will find its way into a future J2SE. On the Non-Win32 Java platforms they're so close to an OpenGL binding internally.I think it would be unwise for Xith not to be able to use Jogl as OpenGL binding. When it's inside J2SE or at least has the button "SUN tech" on it (see other threads) it's good and one problem less for Xith. We're not talking about an high level 3d API like OpenSource Xith <-> SUN Java3d here, with all the game centric discussion, but about a small native binding to OpenGL.

If it's technically no problem to make Xith working also with Lwjgl, way to go. However, I vote not to make Xith depending critically on just one external OpenSource layer.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org