Xith direction, something to talk about.

Engines, Libraries and Tools Xith3D Forums
#1

First and formost I am very happy see the level of effort that BlueSky , Qudus, croft , and others have put into the system recently. I honestly think it has revitalized Xith to a large degree.

For variety of reasons I have stayed at an earlier release of Xith mainly becuase that version has a working collision system. In the near future when my demo is complete I face tha the fact that I will need to get my stuff working with the current releases.

This has all made me ponder the rate of change that is going on.

  • New development and features are great/fantastic and a good sign of a living project. Mutiple new features with intertwined existing code changes can easily lead to hidden/surprise breaks in working code.

  • The rate of change including breaking API’s is a concern of some to degree to me since I need to retrofit code. This also affects people like Croft who actually make their living off of Xith3D (man are you lucky or what)

  • The non compliance with Java3D is a mixed emotiion for me. While there are compelling reasons to continue with a high degree of API correlation it is easily argued that either you have 100% compliance or you are non compliant and never will be, why worry. Certainly a high degree of compliance simplifies porting existing Java3D code to Xith.

What all this leads to is how does the community feel about these things?? Should we/can we decide on some guidelines or should the people willing to put the effort into extending the system have a larger say.

Should any break in API require a new sub release .81, .82, etc… Say on a package basis , if you break a.b.c.e then a new release needs to go out. This may simply be to much effort though, especiially since I am not the one doing it.

I certainly thingk any new feature (I am thinking shader support) should require a new release. Some of this comes from questiosan like when did shadow support die?? When did the collision system die? I have read various reports of the UI dieing over time. We have not tracked regressions well enough in the past. Note many of these things happened prior to the recent work…no blame intended. With various sub releases , targetted for specific changes (new feature/API break) the death of exisitng capabilities may be mitagated.

I welcome opinions, I think this is important right now, I am not complaining because other are contributing more than I am. I have seen this surprise regression march in the past and would hate to see Xith grow shakier even as it is being improved.

#2

  1. We should stick to the Java 3D API as closely as possible. If we deviate from this, we could lose all but the programmers who made the changes and are familiar with them. As I write this, I have a Java 3D programming book open on my desk. Today, this book and books and tutorials like it are applicable to Xith.

  2. Changes should be slow and incremental. The first reason is so that we don’t lose our developers who might not have the time to update their applications to many changes all at once. The second reason is that changes need to be vetted for bugs and peer review.

Xith should be defined as: An Open Source implementation of the Java 3D API with additional libraries.

We should focus on documenting the additional libraries and defer to the Java 3D API documentation, tutorials, and books for the rest.

#3

I mostly agree with hawkwind and croft here.
Could you please list the major shifts between Xith3D and Java3D so we can get used to fix that.

#4

There is the idea to release a version 1.0 in near future. This version should define a stable API (maybe closer to Java3D than it is at the moment). And then we could open a 2.0 branch where we can change to API in some points so that it is better but not fully compatible to the old one or Java3d anymore.

Another idea, that came to my mind dureing the last days is the following. Actually I wanted to start a separater thread for this idea, but I think it fits into this one…

[b]Xith3D was started by David Yazel, because of his dispairing experinces with Java3D. Well, this is some days ago and Java3D has marched of and is now supported by sun and really usable as I heard of. So If we sticked to the Java3D API in all concerns, we should question, if we can be better than sun can be. Won't people decide to use Java3D in favor of Xith3D when die API equals and Java3D is more complete / stable / etc? Maybe we should concentrate on a project consisting of something like our toolkit. We could use Java3D as a base (what the core is now) and tie up the toolkit with additional functionality. Wouldn't this make more sense? If some functionality is missing in Java3D or lacks you can still put some code to the (new, 2.0) toolkit which adds or fixes this functionality.[/b]

What do you think of this idea?

#5

Xith is the only existing Open Source implementation of the Java 3D API. If you want to create something different, you should create a fork, not a branch.

#6

Well, croft told you some good reasons why relying on Java3D is dangerous.
Now a sentence that catched me in your saying is “can we be better than sun can be ?”. Well, as far as I know Sun has never been specialized in 3d gaming (although the SGS project is a laudable attempt to be more aware of the game developers) so why not ? But we should ask ourself “in what can we be better than sun can be ?” What is open-source good at ?

#7

Now that Java3D is revitalised (and remembering that it was basically on it’s death bed when Xith3D was started), I see less of a reason for promoting the similarities. People who want Java3D can use it. Keeping the API similaritiy I agree is a good thing, but I think Xith3D should seek to differentiate itself from the alternatives and promote these differences, not just the fact that it has a more open license (although that would be a factor for some people no doubt).

I would describe Xith3D more as inspired by Java3D, but with a different focus (i.e. highly optimised) rather than as a Java3D implementation.

Just my $0.02

Cheers,
Will.

#8

Yes, yes, I totally agree.

And welcome back, Will.

Marvin

#9

I put forth the question “Are not both possible?”

I see know inherent reason why both are not possible, but then again I don’t know much. Are there inherently unoptimized aspect to the Java3D implementation? Just some thoughts.

Now to take the other side. I personally chose Xith3D over Java3D basically after reading about how its optimized for for game development. To me that’s what it is. I think anyone starting to make a 3D Java game should be taking a look at whats out there. So from that point of view jME and LWJGL are who we need to differentiate ourselves from, and then be good at what we claim to be. To quickly summarize my perceived views of LWJGL and jME compared to xith. LWJGL is a more procedural oriented system (rather than object oriented), and jME is more a 3D game factory, giving the developer lots of start up examples and a fairly well integrated system.

#10

i guess i should throw in my suggestion about seperating the core in several parts … have a look at the later parts of this thread: http://www.java-gaming.org/forums/index.php?topic=14297.0

OTOH i believe that xith is missing some form of overall managment … having a complete community based project like xith may work for some time but you can’t deny that now that xith got that complex and large it doesn’t work well anymore … just have a look at all that stuff that is created twice … got inserted in the project … and every user is creating it again just because he doesn’t know it exists

i believe that having a ‘control instance’ … maybe even a jsr entry … will lead to clearer design, more 'overview and generally better results as it forces the community to concentrate on specific milestones to reach …
the downside will be slower code development and longer times that will be needed to check if new contributions will brake other parts

so far … Flo

#11

Well I agree to a great extent with you.

Now I have the tendency to think JSR is bad (see Matzon’s posts about bad things between JOGL and LWJGL, in the JOGL section, thread about panel support IIRC) cause it grants Sun much much power and I may be right if I say they don’t have that much experience in gaming (which is not the case in networking, and I’m not saying that Darkstar is bad although I don’t plan to use it).

I’m more for open-source efforts and I’m considering improving Xith3D support of LWJGL cause hey between open-source projects IMHO we should be connected (/interdependent).

Now we could (sorry dev guys, some more noise about “what should be done”) have a core of 4-5 knowledgeable people which don’t necessarily work actively on the project but who could share their experience and say why this or this is bad or good for Xith3D. I think YVG, Will, DavidYazel ? (dave is back… ^^ not sure), Abdul Bezrati, Scott Shaver, some others which I forget here could do the job. Why I don’t include Arne, Qudus, Croft, and myself ? Well I think we/I have a good comprehension of Xith3D as a whole and arne and me have some trace of its history since Dave left but I don’t know really how is it all going under the hood.