It would be nice if you can specify your reasons as well…
Thanks.
“I use Xith3D and have no intention to switch to Java3D”
I discovered first Java3D, then I realized there wasn’t any Linux or Mac stable versions, so I drop a line to the Oddlabs dev team which gave me advice to take a look at Xith3D before deciding to use LWJGL.
That’s what I did and, say, it’s fine.
“I use Xith3D and have no intention to switch to Java3D”
I didn’t have a closer look on Java3D. So my vote is maybe a little too strong, because I just don’t know Java3D. But at the moment, I really have no intention to switch. Xith3D is just fine.
“I was using Java3D but switched to Xith3D”
I started with the Java 3D API around 1998. I have used it off and on for different projects. As the years went on, I would hear promises of future development but nothing would materialize. In fact, it seemed as if Sun stopped working on it. When they announced at a JavaOne conference that it was becoming Open Source, I was delighted. I was then disappointed to learn that it was actually “public source”. Sun had no plans to really Open Source the Java 3D API until, to quote a lead Sun employee on the Java 3D API development team, “they lost interest”. I was also upset that they had decided not integrate JOGL.
With Xith I have my Open Source implementation with JOGL. Because it is Open Source, I never have to worry about Sun dropping the ball again.
Yeah, you’re absolutely right. Therefore I have thrown away my idea I pronounced in the other thread.
“I use Xith3D and have no intention to switch to Java3D”
I had many of the same disappointments that croft had. I really distrust Sun these days, they have let so many people go and have failed to come through on prom,ises. At one point Xith was significantly faster.
I find I like the commiunity attached to creating something new.
Hi
I’ve used Java3D, then Xith3D, then Java3D, then LWJGL, and now, I’m on JME. each has it’s merits. Java3D does now use JOGL in 1.5, which sounds interesting. JME is more than just a rendering API as it includes the input and sound layers too. It comes with lots of features for terrain, model loading, particle effects, spatial seperation etc, so for games it seems to contain alot more.
I haven’t fully explored JME yet, i’m still on the learning curve, but it’s looking good so far.
Endolf
HIAL
com.xith3d.sound
org.xith3d.terrain
org.xith3d.loaders
Java Cool Dude’s demo
What ?
more than what ? I always been stunned by people thinking Xith is just a scenegraph and a renderer…
Re read the post, I never said it wasn’t there in xith, just that JME had it too and JME had not been listed on this thread before. Spatial seperation, quad tree’s and the likes, JME does it on your terrain for you I believe (I don’t use it, was just pointing out it had it). All of the features can be implemented in any of the rendering engines mentioned, my point was that there is another alternative.
To be honest, my experience so far is that they are all very much alike. They all do some things slightly differently. It’s easier to convert between Java3D and Xith3D than jME, as Xith3D was designed to be almost compatable with Java3D on API when David Yazel first started it. Where as JME was designed from the ground up.
I’m using JME now because I’ve not used it before and wanted to try it. So far I like it, but in reality, I find it no better or worse as yet than the others, they all have quirks and niceties. They are just different.
I find the JME guys very helpful, but I never had troubles getting help when needed with either Java3D or Xith3D.
I used only java3d. I wanted to try Xith3D , but when I saw it’s single-threaded… How can a good and fast game be developed without multi-threading?
Threads do not insure speed. threads can and are indeterminate.
With the Xith render loop, you have total control of what activities occur within the scene and the ability to adjust game elements based on the current render loop performance. As i rmember with Java3D you need to use a wake up behavior that triggers every cycle to insure that activity A takes place when you want. For example in my game the speed objects translte/animate is based on recent render cycle durations, the number of scene changes that occur is limted by cycle time.
You can use org.xith3d.render.loop.ExtRenderLoop to easily schedule operations to be done by the render thread. This class also has more functionality that ensures thread safety.
I have used Java3D and left when it was left apart by Sun. Then I tried Xith3D. I was happy with it as long as I was doing ‘simple things’. Then I wanted more, so I dived into the code and tried to add the functionnality I was missing. I then discovered that the code is a whole mess (just my opinion) and that it would be fairly easier to start an engine from scratch than to try to improve Xith3D (just my opinion again). So I dropped Xith3D and moved on to my own engine. In the process, I tried jMonkeyEngine which I found wonderfull but since I had allready started my engine and had a working base I did continue on my own path. I have no plan to use Xith3D again at the moment but I still follow closely the progress of the available graphic engines to learn good design ideas from them.
That’s ok. My point was that Xith3D was simply more than an open-source Java3D implementation. And it contains lots and lots of things which aren’t known really.
Really interesting.
Do I have a chance to take a look at your engine ? Is it open-source ? I also follow graphic engines progress.