looks like we have some competition

Engines, Libraries and Tools Xith3D Forums
#21

(speaking as someone who is considering adopting Xith)

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 :frowning: ).

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.
[/quote]
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.

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.

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.

#22

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

#23

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 :frowning: ).
[*] 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.

#24

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

#25

I think that this is a compelling reason to make Xith3D dedicated to it’s niche market - game developers.

I completelly agree with the sentiment expressed here that the open source J3D is just an annoucement and it’s still unknown what it can become.

I think the open source, community driven model has done Xith3D many favours and will continue to do so. We also have no legacy applications which we need to support (untill we hit 1.0 that is).

J3D was stagnated for over a year - it’s going to take a while to get that moving again.

Cas, I appreciate your advice based on your experiance in this :slight_smile:

Will.

#26

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 :wink:

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.

PS: Did I say I really like the overlays? :smiley:

#27

But it is! Where is the problem there?

Just the auto-install feature never worked. So you either have to have it installed upfront or distribute it with the app via webstart.

The latter is the only way for xith.

#28

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 :slight_smile:

Endolf

#29

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 :wink: but then why would I push anyone elses?

Cas :slight_smile:

#30

[quote]I just want one solid platform from which to work and do everything.
[/quote]
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.

#31

While it does seem certain, 1.5 is only just about to get a release, 1.6 is ages away. Its not really relevant to those who want something working now.

[quote]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.
[/quote]
But it is a problem because it doesn’t work, or is fatally buggy on many platforms. I for one am getting fed up of people not being able to run S-Type (or indeed the basic Jogl gears demo) which run LWJGL apps fine. Until Jogl is robust and actually works its not a solution, its just a toy.

If its not too much of a problem to use either Jogl or LWJGL then its all good. But nailing it down to just Jogl seems like an incredibly bad move.

#32

This is what I said.

[quote]But nailing it down to just Jogl seems like an incredibly bad move.
[/quote]
This I never said or suggested.
I said: But nailing it down to just Lwjgl seems like an incredibly bad move.

So I conclude: basically we mean the same.

#33

There is no actual requirement to use LWJGL as a shared library you know. Just fork it, lift it out and plonk it into Xith3d. Occasionally you might want to merge it but the idea is that you have a separate, independent living platform with a life of its own that depends on no-one else to make it work.

O’course it’s totally moot until we get Mac support and seeing as we’re all too skint / inexperienced / busy to sort that out Xith is definitely better off with JOGL :wink:

Cas :slight_smile:

#34

Funny you say this in the Xith3d thread, with Xith3d being in a kind of alpha phase, so much about “far away”… :slight_smile:

#35

Here’s the ideal situation in my eyes:

Xith3D/JOGL for people wanting to incorporate 3D stuff with AWT/Swing apps and great with JWS.

Xith3D/LWJGL for people who want to distribute Jet EXE’s with the smallest possible size (infact as I have discovered - Xith3D wouldn’t add much to the clout of a LWJGL project). Maybe - just maybe, sometime in the future, deploying on an OpenGL console!

I feel that both are useful. Now what we really want is that abstract OpenGL layer Cas was proposing on the forums so even if people start accessing OpenGL directly - it’ll still work on LWJGL and JOGL.

And I’m sure Xith3D/SWT fits in somewhere too, perhaps as an alternative to AWT when you want a rich UI that LWJGL doesn’t provide.

Cheers,

Will.

#36

William, you summed it up perfectly!

Let me add one more combination: swt is for those needing a Gui and wanting to use JET for providing a JRE free installation. If using Swing and compiling with JET this one does not complain but it requires an installed JRE for runtime purposes also.

#37

There’s quite a lot of obsession with AWT and SWT for “rich guis” but to my mind these things can, for games at least, be coded excellently in purest OpenGL and simply rendered every frame.

Now, we’re in a games forum talking about gaming technology… so is Xith going to be a games API or is it going to compete head on with J3D in the medical visualisation space, CAD/CAM, etc.?

If Xith is going to differentiate itself properly I think it might want to relax its requirement that it interoperates fully with Swing and allow developers to create native GL GUIs. Such as the ones you might use in games…

Cas :slight_smile:

#38

I disagree that there is no use for Swing, Awt or Swt. You could do any ui in opengl yes that is right but why to invent the wheel for another time again? The Uis have proven to be useful, are stable and I won’t miss translucient guis that do not force me to split textures into pieces (256x256 and up).

Integraton of Swing requires some rework for the input handling (key, mouse, focus) but after that there should not be any more problem. And having used Swing since 1998 (with all its errors, flaws and so on) I have to mention that it is not easy to do everything it offers by hand again - I even do not have the time for writing that from scratch. And as I demonstrated with http://team.micram.de/dingfelder/projects/xith3d/jnlp/levelbox/LevelBox.jnlp it is possible to get nice effects (even watermarks) with a minimum of code …

#39

[quote]There’s quite a lot of obsession with AWT and SWT for “rich guis” but to my mind these things can, for games at least, be coded excellently in purest OpenGL and simply rendered every frame.
[/quote]
(I’m ignoring AWT which is not really a high-level GUI API, and is not really maintained any more either)

You say this often, and I often respond by asking about the high-level parts of the Swing API, and still neither you nor anyone else has come forth and provided high-level GUI API features on top of OGL.

It’s well known that I detest JTree and friends, but I don’t throw the baby out with the bathwater; much of swing has great value.

Heh. It strikes me as ironic that in a forum about a high-level rendering API you advocate dumping a high-level GUI API in favour of having everyone roll their own from a very low-level API ::)…

#40

[quote]There’s quite a lot of obsession with AWT and SWT for “rich guis” but to my mind these things can, for games at least, be coded excellently in purest OpenGL and simply rendered every frame.
(…)
If Xith is going to differentiate itself properly I think it might want to relax its requirement that it interoperates fully with Swing and allow developers to create native GL GUIs. Such as the ones you might use in games…
[/quote]
There’s many occassions you can use Swing with your game. Remember, there are many different types of game. Imagine there’s even games which need high level GUI stuff like Swing - not neccessary rendered to the main screen, but tied next to it, or beside the main windows, etc etc. Yes, there are games other then Quake3 engined ego shooters and similar ones. :slight_smile:

Einstein said: make it as simple as possible, but not simpler. Listen to him, Cas. :slight_smile: