well, this is official, see j3d section.
Now i’m wondering something…
J3D is going to be a java.net project. will you contribute it with all the marvelous things you did for xith or continue that way?
I’m asking because with that change in java3d direction, xith might be seen as a duplicate effort… If J3D can be adapted to actual needs, is there still a point to Xith?
cool- we can teef loads of there code 
why has bombadil’s post been removed?
Sorry for causing confusion - I moved the article to the other thread about J3d in the Xith forum named “looks like we have some competition”, in order to keep the focus.
yes, saw that a bit after when checking other thread… sorry
[quote]why has bombadil’s post been removed?
[/quote]
Maybe he did it himself.
The danger now is that the (small) 3D development resources and community now may gets split up. It would have been advantagious to reach the upcoming state of Java3D before David started his effort. Now some excellent guys work on Xith and I can very well understand they don’t want to give it up now.
Unfortunately SUN APIs do have this habbit of soaking up new developers.
JOGL (at least to me) seems to get far more newbies jumping (while LWJGL is a better and more mature solution).
Java3D with the “Made by Sun” tag will most likely hit the groth of Xith. Well that doesn’t matter to the guys who are already here it might slow the growth.
Kev
[quote]JOGL (at least to me) seems to get far more newbies jumping (while LWJGL is a better and more mature solution).
[/quote]
Hm, I know … ask for JINPUT vs. JXInput 
As soon as JINPUT suddenly showed up, I knew I can stop working on JXInput.
But for Xith3D the situation is slightly different…
Yes, I myself like the “Made by Sun” tag very much! Its like using a standard technology in favor of some freaky opensource stuff (I hope the mood of that sentence comes thru). Reliability, continuity (caugh), quality, availibility, support.
This is now that a decision has to be taken.
rationale: there is not a huge dev community with time available to do it. splitting will slow both, and none will get any thing from the split. J3D will attract more users because of its wide use amongst many domains. J3D is and will be adverted at the source, all sun sites, while xith will not. Thus xith will become less used. by the time whatever its qualities are. Moreover more and more people will not understand the interest in doing two apis that are so similar, whenever they will learn about xith. i believe they will be right. Points of yesterday might not survive today and to me, xith’s point is moot. J3d, while less up to date is way more mature than xith. now that j3d will evolve again, and be open source, i see no reason to continue.
non rationale: Xith is a project one’s invested lots of time, feels like home and one does not want to change habits. one will continue develloping it, whatever the time spent for it and whatever the community becomes.
Okay, the vision is a bit oriented, but i believe that the exageration is small.
[quote] Yes, I myself like the “Made by Sun” tag very much! Its like using a standard technology in favor of some freaky opensource stuff (I hope the mood of that sentence comes thru). Reliability, continuity (caugh), quality, availibility, support.
[/quote]
And that’s the same for lots of people, including me.
(We’re now discussing the same topic in two different threads on the same forum…)
OK, I also agree that “made by SUN” is a good thing for Java fans, usually…
However, since typically Xith3d is over twice as fast according to Javacooldude’s demos (he did them in Java3d and Xith3d), I don’t really know how attractive Java3d is to game developers…?
over 100% faster sounds important in gaming measurement, isn’t it?
Count to this the statement of Yuri (and other Xith developers) that the optimizing “curve” of Xith3d is only at its beginning…
Of course, a lot of packages and even more Javadocu is still missing in Xith3d. Would it be legal to im/port them to Xith3d, one day Java3d is BSD licenced?
[quote]Of course, a lot of packages and even more Javadocu is still missing in Xith3d. Would it be legal to im/port them to Xith3d, one day Java3d is BSD licenced?
[/quote]
If Java3D’s license will be BSD, then this is legal.
Well, if it was done in Xith, it should also be doable in java3d. i mean, the structure of source data is very similar. The learnings of Xith must be used on the sources of J3D to bring to what was an api for industrial 3D into an API that can also push polygons faster for gaming. The vision of the original coding was not gaming. if no one pushes it to get there, it will stay the same.
An API evolves as fast as the people that make it can go, and executes as fast as the team made it to. If you can put a spec on a desk and code an implementation in a week, your API will evolve rapidly. if you let slow/unmotivated people do that, it will evolve at their speed.
We, as a community, have the chance to be implied in the process and success of the API . it’s time to make things move, now that we can.
[quote]Well, if it was done in Xith, it should also be doable in java3d. i mean, the structure of source data is very similar. The learnings of Xith must be used on the sources of J3D to bring to what was an api for industrial 3D into an API that can also push polygons faster for gaming.
[/quote]
Xith3D has some different concepts, which are probably a reason for the performance difference (David wrote a short document about it). I don’t think Java3D’s concepts will change a lot.
[quote]We, as a community, have the chance to be implied in the process and success of the API . it’s time to make things move, now that we can.
[/quote]
We are able to make things move in Xith3D for quite some time now.
I don’t want to upset anyone and I’m no expert but:
Forget J3D. Sure it’s possible to do a game with it but that isn’t what it was designed for. Xith had this specific purpose in mind from the beginning.
You have control over Xith, if poeple start trying to make radical changes to J3D it will just end up being a p*ssing contest and nothing will ever get done. And frankly anything involving an “expert group” is bound to be incredibly slow moving.
There is nothing wrong with having more than one scenegraph API. I’ve never understood why people complain about monopolies (MS) an the problems they cause and then turn around and complain when there are choices (Xith and J3D).
What forbids J3D to evolve to a gaming capability?
You are talking about j3d as it is actually. While at least one great game was done with actual J3D, it does not mean that further one will not be better tuned for you. Amusingly, that also depends on you.
[quote]You have control over Xith, if poeple start trying to make radical changes to J3D it will just end up being a p*ssing contest and nothing will ever get done.
[/quote]
That’s exactly what i’m afraid of. Undoublty more people will more rally j3d than xith, even in gaming, and i fear that stupid contest will happen.
well. original 1.4 timing was of one year. i agree that it is quite a period, but it’s not a lot longer than for any project. Nevertheless, i believe it can be shorter. I also believe that it will now take way less than that to setup and implement what is planned for 1.4.
[quote]There is nothing wrong with having more than one scenegraph API. I’ve never understood why people complain about monopolies (MS) an the problems they cause and then turn around and complain when there are choices (Xith and J3D).
[/quote]
maybe because you did not understood something i will repeat. having choice in closed source software of commercial companies is a good thing. they compete to get more money using different arguments (that are nowdays most of the time pure hype or marketing for long lived ones…) Having the choice in APIs is different in our case. basically one community is having the choice to make evolve one or an other of two or more APIs. Each API will evolve based on demand and all needed features will be implemented as soon as they can be. Whatever the API, the demand will mostly (98%) be the same… they will follow the possibilities of graphic cards and implement new rendering methods, tricks.
All of them will implement new things at their rate. I believe that APIs like xith will do things faster, but will make design changes that will harm users sooner or later, and that due to the time taken to think in slower processes it is less due to come. Taking time to think is extremly important.
Moreover, having a topnotch 3d api that integrates new features in weeks or months will benefit only a very (very very) small subset of people. I don’t know what is the current state of cosm, but i bet it does not integrate most of the advanced features of xith, those that are said to be asked by everyone and are actively developed. show me a xith project (except tech demos) that actually uses with’s latest features…
I won’t get two pets because ‘having the choice is better’. having two pets have no point. i want to have one, take best care of it and have all necessary resources to take care of it correctly most of my time, not half or third.
Well I think we’ll have to disagree on this one. Although the entire issue is undoubtably of far more concern to you than me since I really don’t do anything serious with this stuff.
[quote]I believe that APIs like xith will do things faster, but will make design changes that will harm users sooner or later, and that due to the time taken to think in slower processes it is less due to come.
[/quote]
Isn’t the entire point here that you can take a version of the Xith code at any time and you don’t have to worry about changes hurting you?
[quote]Moreover, having a topnotch 3d api that integrates new features in weeks or months will benefit only a very (very very) small subset of people.
[/quote]
Again this is just my opinion but simply don’t understand what is wrong with that. People that don’t want a fast moving gaming specific API can use J3D, people that do can use Xith3D.
What are your thoughts about the size differences between J3D and Xith3D? I haven’t checked in a long time but isn’t J3D enourmous?
I too agree with the “I prefer Sun’s version by default, whatever the lib is”. When I think about it, though, that’s mainly because the majority of opensource libs are VERY poorly documented and poorly supported - when I find an os-lib with a reasonable level of support and quality my reservations generally evaporate.
But with j3d, as a naive person sitting on the fence, I am at the moment waiting to see EXACTLY what j3d’s roadmap is. Basically, after the initial excitement I’ve not been at all impressed with what Sun’s done so far with the gaming API’s. So much so that I now automatically expect that j3d will be useless to me for at least 12 months - and that’s leaving aside my prior bad experiences with j3d immaturity!
I suspect that there’s quite a lot of other games devs who’ve become “disenchanted” with sun on the gaming API’s. I also suspect there’s not a small number who will think “If Sun is already not able to assign quite enough resources for JOGL etc, is it only going to get worse (even less sun involvement with the dev) with an extra API under the auspices of the GTG?”. I’m not saying this is accurate or fair - but I think it’s easy to think it if you don’t know much about the details.
For the record, the j3d announcement has itself also reduced my interest in j3d (really!). The repeated pattern of letting outsiders do lots of work and then basically tripping them up and undermining the work has been re-inforced here. It’s not a philosophical issue - it’s simply one of trust: as my trust for Sun goes down, I become less confident that they won’t e.g. change their mind and stop all j3d development in 6 months time. Yes, this is different from the JInput case. But it’s not that different, and now what was an “isolated incident” that already stuck in my throat looks like it’s juist the first in a pattern.
But…if j3d announcements come out saying basically that they’re going to alter the architecture in similar ways as Xith (e.g. w.r.t. threading) and that it’ll be focussed at games developers, etc etc etc…I’m going to be faced with a hard decision.
Really, I’m hoping they don’t do that, because then my decision is quite easy.
There are also other major changes that could conceivably be made to j3d that would make it so much better than x3d (technically) that it would swing me.
I would say: don’t even start to give up on x3d until at least 6 months after the next release of j3d. That should be long enough that you’ll see whether:
[] lots more scenegraph games appear, and it’s mostly j3d
[] few more scenegraph games appear, and j3d is clearly having no real effect
[] people are trying both at once, and going one way or the other; and you’ll have a good idea of why they choose each
[] lots of people find j3d, find it sucks, and someone tells them about x3d so they switch.
Note: from what I can see, that last option is starting to happen for a lot of people with JOGL/LWJGL. There’s a long lead time because a lot of people won’t seriously use an API until it’s been “in the wild” for a couple of months, then it takes them a couple of months to get used to it, then they spend another month getting deep into it. It’s at this point that they start to discover the fundamentl problems or realise certain things will never get fixed. This is when they are ripe to change to a new API.
To a certain extent, so long as j3d games developers are attracted to jgo.org, they will find x3d if it’s significantly superior - just like with jogl/lwjgl. The GTG guys have done good work with promoting the 3rd party game libs via their own forum cats etc, and I’m assuming this would continue.
[quote] What are your thoughts about the size differences between J3D and Xith3D? I haven’t checked in a long time but isn’t J3D enourmous?
[/quote]
xith is a 765Kb compressed jar (1580Kb uncompressed jar)
and needs jogl which is a 552kb compressed jar (1437kb decompressed jar) and 472kb dll on windows. add joal to have sound and it make 90more kb.
that makes 765 + 552 + 472 +90 = 1879 kb compressed or 3579 Kb uncompressed.
Note: did not count vecmath.jar, as i did not knew if it was used.
java3d is 4 jars that are installed uncompressed (for performance reasons) of 5005 Kb (2616kb compressed) and two dlls that are 224kb.
note: j3daudio.jar includes a 1.1mb gm soundbank…
that makes 2816kb compressed and 5229 kb uncompressed.
It is not that big for both, and a difference of 1073kb…
if you remove the soundbank, j3d and xith have almost the same size… Xiith is only 5kb smaller if soundbank is compressed and bigger of 80Kb if we remove the sounbank uncompressed…
While xith has more up to date features, it is way less complete globally than j3d. thus, we can say that feature wise, j3d is way smaller than xith.
Tell me if i forgot a file, somewhere…
well it is true for anything. if you don’t update, you won’t be bothered by changes… ;D
[quote]Again this is just my opinion but simply don’t understand what is wrong with that. People that don’t want a fast moving gaming specific API can use J3D, people that do can use Xith3D.
[/quote]
well… I’ll answer with questions, if you don’t mind.
Do you base your games on graphic card features?
Is there any interest of having the benefit of latest features in weeks or few month for a game project ? (a serious one… one that takes months to complete)
and finally, the most important one to my eyes…
Can we simply afford it?