You mean like adding this available-just-for-last-two-days, cutting edge, unsupported-on-most-GPUs feature like stencil buffer ? Indeed, nobody sane would use such experimental feature in his game, so there was no need to put it into java3d for last 6 years…
{sarcasm off}
I don’t think anybody really means nvidia 5950-only features here. But java3d is lacking certain things which are standard since 5 years. I don’t believe it will start to include them magically with new development model.
As I already said, we did not optimize for size. Throwing out the debugging and the demos would definitely reduce the size of Xith3D and possibly you can throw out more Xith3D packages, if you don’t use them.
What you are basically trying to say in this thread is that we should stop developing Xith3D and move to Sun’s Java3D. There are some problems doing this:
So far there is only an announcement, Java3D 1.4 is not yet out and Open Source. You are assuming that the disadvantages of Java3D will vanish, but currently we don’t know exactly what will happen. Don’t know if it makes sense to try to somehow get involved in the JCP. (I won’t do it.)
Xith3D’s structure is already different to Java3D. The scenegraph is basically the same. Sound, rendering, loaders, physics are different. Xith3D is not thread safe and uses only floats. I don’t know if you are aware of that, because I never saw any posts of you in the Xith3D forum.
You are seeing Xith3D as a duplicate effort. Currently it’s the other way round. Sun has the bad habit of letting others do the work and then coming up with their own implementations without communicating or respecting the work others have done.
Xith3D is truely Open Source. Questions, bug reports, patches, tutorials, new developers are very welcome. It’s not clear if this will be valid for Java3D.
I agree with Adam, that we have to wait at least some months until we can draw conclusions.
The problem I see is that Java scenegraph APIs are already a niche and now that a big player (Java3D) is in the game again, the niche for Xith3D may become even smaller. There are other scenegraph APIs like jME and OpenMind. Another approach than simply giving up Xith3D, would be to talk to them and perhaps creating a single project out of these APIs.
The positive aspect is that we can also learn from Java3D, if it’s further developed and we can reuse their code, if it’s Open Source. If Xith3D remains a vital project I don’t see Java3D getting ahead of us.
I think the decision to open source Java3D is great because it lets the Xith3D folks grab some functionality that they haven’t yet implemented. I don’t think the decision will make Xith3D go away though, since if anyone forks Java3D to be optimized for games the fork will be just as “unofficial” as Xith3D.
Maybe the expert group will remove the multi-threaded execution architecture from the Java3D spec and ignore other needs of the visualization coomunity in favour of the game development community, but until they do, the official Java3D API will still be a lot less appropriate for games than Xith3D.
Well said Jens, you have really summed up the situation well.
Point 1 is very important. As Tom Clancy writes - “assumption is the mother of all fuckups”.
Good point regarding Xith3D size - it’s an order of magnitute larger atm as we are compiling with full debugging info.
Will.
Please continue your good work on Xith. 
It’s already a great API to use, even if it’s still in alpha phase. So we can be on edge when in the future it will go version 1.00 …
There’s a need for a game specialized 3d API for Java and I think we find this in Xith. Javacooldude’s demos are typically over twice as fast as the same ones in J3d. I don’t see how J3d would compete with Xith on the games front. Aside games J3d is a good general purpose 3d API, I read. This explains why it’s slower on one special task: “just” games. So it’s not a “problem”, it’s a design decision.
The reasons for Xith3d being so fast are many. David’s small PDF overview on the Xith3d docu site shows the basics. Like Jens said, Xith targets a specialist market. So it’s got different goals than J3d, and vice versa.
If you target fast 3d games and/or casual gamer’s PCs, your choice is clear. Not to mention that Yuri and David told several times that the optimization potential of Xith3d is only at its beginning.
Since J3d obviously has got different goals, I don’t think we’ll see similar optimization efforts for J3d - why should they spent their time for such when for 3d applications it means no win? Would be silly.
It’s good that SUN continues its nice J3d and makes it better. This helps the Java folks, the industry using Java, etc. There’s a great need for a general purpose 3D API.
Having said all this, of course for both 3d APIs it makes sense to share knowledge and join efforts where possible. Clearly I vote that Xith3d continues to keep Java3d API compatible where possible. This strengthens both APIs’ user groups.
It would also be very nice if we could share utilities, loaders, etc. for both APIs. When J3D goes OpenSource (BSD?), we could even import and export parts of the APIs to the other one. I think this would be great.
PS: Of course I’d love to see a “perfect 3d API being best at all purposes”, but that’s an utopia.
Hi
One other major advantage of Xith3D is that sun almost certainly won’t release j3d under a BSD style license, which will mean they retain control, so next time they put it in a holding pattern it will sit there and nothing will move. Where as if david, yuri, william and co get bored and move on, being open source, someone will come in and take over if there is still the interest in it.
Cheers
Endolf
Let’s hope Sun chooses a real open source license, rather than the non-free Sun Community Source License, or they could cause real trouble for the Xith3D developers. After all, the core Java libraries are released under the SCSL and this has forced the GNU Classpath project to require that all its developers have never agreed to that license by looking at the sources.
OTOH, I wonder what the role of the expert group and the JCP would be if Sun went with a real open source license. Would they control what implementations that get to use the Java3D brand? Maybe just control what implementations get distributed from the java.sun.com site?
Hi
Doug (i think) said that it would be somewhere between BSD and SCSL, so we can assume it won’t be completely open, on the other hand, it won’t be so closed as some of the other source. We will just have to wait and see, odds are, you won’t be able to teef code from java3d for xith though
Cheers
Endolf
I think the biggest problem here is that the community using Java for 3D is very small. And that means the number of 3D experts who are able and want to help develop a 3D API is very very limited.
Right now those experts are making:
As I see it there is no experts left for Java3D. Sun simply was too slow, it had its opportunity and did not grab it.
:’(
Sometimes I am a little bit of an expert myself … and what about you?
Pepe - please read my recent research into Xith3D file sizes. As you will see - Xith3D can be significantly smaller if you want.
Both Xith3D and Java3D use vecmath.jar (although different implementations).
Also - don’t forget to compress your DLL files if you want a true comparison. Also - using BZip2 (eg. in an NSIS installer) gives you better compression again although both would be effected more or less equally.
Will.
throwing debugging info would be a regression, imho. Removing them means that you will pass huge time to correct bugs on your user’s reports, and be back to the old time of C. throwing out demos, however, is a good idea.
[quote]What you are basically trying to say in this thread is that we should stop developing Xith3D and move to Sun’s Java3D.
[/quote]
Somewhat, but that’s not what is important in that thread. I have an opinion, and i am asking for yours. I’m aware that people will not want to drop developing xith, and i think that this is madness in the actual situation. I might be wrong, and i want you to give me your points so i can understand them. Discussing each other’s point to extract only objective ones is important to me as it gives me the possibility to eventually change my mind. A reductiion of all that might be “i don’t understand why, convince me, but don’t expect me to just listen”
[quote]1. So far there is only an announcement, Java3D 1.4 is not yet out and Open Source. You are assuming that the disadvantages of Java3D will vanish, but currently we don’t know exactly what will happen. Don’t know if it makes sense to try to somehow get involved in the JCP. (I won’t do it.)
[/quote]
MMhhhh. aren’t you secretly assuming the opposite? We don’t know for sure, but we both have a position. I am optimistic and prefer assuming good things will happen and try to help in that.
Wow that’s nasty… well, i hope for you that 99% of your users never drop a word on forums as i do. If not you’re actually wasting your time on an api used by… mhh … 20 to 30 persons… better do something else…
Well, actually, Xith came with their own implementation of java 3D. If there is a competition, i see it there. they do, you ‘rip’, then you think they will rip what you did, but you will rip what you did not implement or document… bla bla bla endlessly…
childish imho…
Except for patches, that is also welcome for any closed source API.
For this, i partially agree. I’ll wait for things to really begin in order to draw conclusions.
You don’t have to compress to compare. you can compare anything, once they are of the same type. Actually, the question was how was xith compared to J3D. J3D has to be the basis, as it can’t change. Nevertheless, i did the comparisons of both compressed and uncompressed jars to be fair and clearly understandable.
i post the rest in your thread.
[quote]Somewhat, but that’s not what is important in that thread. I have an opinion, and i am asking for yours. I’m aware that people will not want to drop developing xith, and i think that this is madness in the actual situation.
[/quote]
Is it madness that people want to drop it or that people don’t want to drop it?
[quote]MMhhhh. aren’t you secretly assuming the opposite? We don’t know for sure, but we both have a position. I am optimistic and prefer assuming good things will happen and try to help in that.
[/quote]
No matter what position we have, we can’t look into the future.
[quote]Wow that’s nasty… well, i hope for you that 99% of your users never drop a word on forums as i do. If not you’re actually wasting your time on an api used by… mhh … 20 to 30 persons… better do something else…
[/quote]
I just wasn’t sure if you are aware that there are already major differences between Xith3D and Java3D. It’s indeed some kind of strange, that the first thing the community in this forum hears from you is a request to drop Xith3D, but I didn’t intend to offense you. It’s of course OK to stay in silent-mode and I do this quite often myself in other lists.
[quote]Well, actually, Xith came with their own implementation of java 3D. If there is a competition, i see it there. they do, you ‘rip’, then you think they will rip what you did, but you will rip what you did not implement or document… bla bla bla endlessly…
childish imho…
[/quote]
The first ‘rip’ was for a good reason: Java3D seemed not be supported anymore, but a lot of developers were used to its scenegraph structure. I’m not sure, if they will rip what the Xith3D people did. Probably this won’t be the case, because there isn’t much communication (I know of). Yes, I’m aware this all isn’t perfect, but I can’t imaginge an easy solution, based on the information, which is currently available.
The fact that many people considered Java3D dead, created a new “market” for Java 3D (scenegraph) APIs. Today there is not only Java3D and Xith3D, but also jME, OpenMind, Jist3D and probably others. There will be duplicate effort between these projects.
[quote]For this, i partially agree. I’ll wait for things to really begin in order to draw conclusions.
[/quote]
Let’s keep the topic in mind, so we can come back to it, when we have new information.
pepe, I see that you are convinced that Java3D will evolve into an API that will exactly fit your needs. I hope for your sake that it will, and do so in a timely fashion.
When Xith3D was designed - many of the good featres and ideas of Java3D were encorporated, and the API was made to be similar to ease porting.
Xith3D is not, never was and never will be an attempt to recreate Java3D. There are many fundimental differences between the two API’s which will widen over time.
I have suggested to you before, and I shall do so again - review both API’s based on their technical merits and choose the one which best suites your needs.
Personally I will be saying with Xith3D as I feel that it has more innovative potential, is a current solution rather than a proposal, and after reviewing both API’s I have found that it is better suited to my needs.
Will.
You are correct in that you can compare anything once they are of the same type - however in this case they are not of the same type. No two files of the exact same size (unless they are the same file) will have the same amount of compression.
A good example is word files - you could have a 300K file and a 30K file which both compress to the same size (I have seen this).
As we are talking about distribution size rather than installed size - the most accurate comparison would be to compress both libraries up (including native libraries!) using a good packaging software (eg. NSIS using BZip2).
Regarding debugging information, I think it is up to the distributor to decide if including it would be benificial don’t you think? If you know your customers can’t submit a stack trace or if you don’t care if they do - then there is little need for debugging info. Most production code people use on a day to day basis doesn’t have this information (I can name several commercial games which have crashed without any useful information that I could relay to the developers and even it did and I tried to submit it, I would most likely be ignored anyway). The reason I provided BOTH sizes (with debugging and without) is to illustrate the choice and the trade offs.
Will.
Hey guys - I’ve been meaning to check in, but GDC got in the way. Java 3D and Xith3D can co-exist with no problem. Xith3D has a focus on games, and some non-games applications can take advantage of the things that it has. There is also a very large Java 3D development community that doesn’t make games. Because of Java 3D’s asynchronous multithreaded design, it fits very will into visualization systems. It’s focus is not likely to change because of its large visualization installed base. So, having a games focused scene graph is a good thing. There are lots of non-games Java 3D developers that are very excited about the prospect of helping to develop it. The feedback has been awesome.
Also, it is unlikely that you will be able to directly use Java 3D code. There is the license issue. And, I think you will be suprised to find how different the code is than you might think. It was designed for highly scalable multi-screen visual systems, so not much of the code will meet your needs anyways.
So don’t worry. Our intention is not to take over all scene graphs. We are just trying to help our Java 3D developers who want to see it evolve and thrive.
Doug.
Hello Doug,
nice to hear a statement from you. It describes the situation pretty good. Does “license issue” mean that Java3D won’t be released under a BSD license?
Btw. for visualization systems, there is also the Aviatrix3D project (http://aviatrix3d.j3d.org/). I think there are currently quite a number of scenegraphs out there and it’s hard to predict the future of them.
Jens
Cross-post
“Official Announcement”
Jist3D as a rendering engine is no longer being developed.
http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=jogl;action=display;num=1069188165