Collaboration between jME and Xith3D

Business and Project Management Discussions Community & Volunteer Projects
#1

First of all, let’s present myself.

I started game development with GLUT/OpenGL in C++. All was pretty good although I had no experience at all. But I found development a bit messy… I used L3DS (http://www.levp.de/3d/) to load 3DS models which I modeled using Anim8or (http://www.anim8or.com/)… Not fancy, but it worked.
Well, after having resolved the 50 welcome bugs for n00bs I had a running game prototype… I even had sound with Fmod (http://www.fmod.org/)… All couldn’t be better… until I tried to compile on Windows… (I was working under linux)… And then the problems began… GLUT versions weren’t synchro between Linux & Windows… Lots of portability issues… One of my freinds tried to compile on mac… And it was even worse, L3DS didn’t work at all and all he got was a black screen and a crashed mac. Then I decided to go SDL, and after having issued 100 SDL parachute errors and figured out that C++ is really not as good as gamedev.net says.

Then I began to look for a Java solution… I had tried Tribal Trouble (http://tribaltrouble.com) and it seemed to me pretty, fast, and portable… So I decided to go the way they had gone… I downloaded LWJGL but unfortunately there was no test to run easily on linux, and as I had very little knowledge I didn’t went very far. I then e-mailed Tribal Trouble development team, which answered I could also try Java3D or Xith3D which were also pretty good. Java3D was dead and didn’t have any linux release so I downloaded Xith3D, followed the Installation Guide, then the Getting Started Guide and started coding again my game… And it was fine.

Some weeks after the news arrived Java3D was resurrected… Although (as you can have seen) I’m a lib-changing guy I didn’t wanted to try the new Java3D… Then I heard about jME… I even ran some demos which were beautiful, but Xith3D was fitting my needs. So I just stick with it.

Actually I’m fighting with my artists to have a working graphic pipeline… To say you all :

  • MD2 isn’t precise, and Blender export don’t work really. And it doesn’t support bones
  • OBJ is precise, and Blender export works, and I can import it in Xith but it doesn’t support bones
  • Cal3D cannot be imported currently in Xith3D

I have regularly proposed my ideas of merging libs or at least merging the efforts, improving collaboration… each time some gurus had really good reasons not to participate to that…

Now it’s ridiculous how the competition has become between Xith3D and jME… “Oh I can get 10 more FPS with jME, let’s take it”, “Oh Xith can support Collada, let’s go Xith3D !” Don’t tell me the usage of jME and Xith are different it’s just political or personal opinion that make you chose one or another…

And now there are duplicated effort… Each one is going to write its own loaders and all just because there are many separate libs that don’t contain every feature they need.

Collaboration is good. What can be shared between Xith3D and jME is, IMHO :

  • Culling methods, and everything in general that can increase FPS
  • Loaders : MD5, Collada, Cal3D and others if there are volunteers…

This is the strict minimum if the community won’t go further which would be creating a unique library, not formally a merger but a common effort.

#2

I agree collaboration can be a very good thing. Particularly from the Xith front, but from the jME perspective what does Xith have that jME doesn’t? Within the next couple months jME will have extremely powerful and full-featured Collada support as jME is moving very much that direction. jME also supports dozens of other major features that Xith just doesn’t have. Granted it’s been a while since I looked at Xith, but from my previous experience with it the forums were not responded to frequently, noobs questions weren’t answered, features were sparse, structure was far too much like Java3D (which in my opinion sucks), and it’s a slower engine than jME. Perhaps these aspects have changed since I was there last, but perhaps you Xith people need to seriously look at what jME has and just realize that we’ve got everything already and just join us. :-p

There’s a reason you don’t see many jME developers around here. It’s because we have an extremely active forum that gets answered very fast and a great community.

Just the opinion of a biased developer, take it at what it’s worth. :wink:

-Matt Hicks

#3

Okay so I’ll just answer completely uselessly at some of your points (as i agree more or less with you on your last point) :

  • “What does Xith has that jME hasn’t ?”

  • JSR-231 support. Hey, this isn’t a small thing. It adds really much compatibility. However, I agree that a port of the LWJGL render of jME wouldn’t be a too big work (assuming jME is well-designed).

  • “The forums were not answered frequently”

  • It was probably true when it was in heavy development process, as Dave Yazel probably hadn’t the time to answer to everything. But now I can tell you it’s all the contrary. Some people like Arne, Croft, William, some others and myself are looking very carefully that n00bs don’t get abandoned.

  • “Perhaps these aspects have changed since I was there last, but perhaps you Xith people need to seriously look at what jME has and just realize that we’ve got everything already and just join us. :-p”

  • Don’t you know it’s just what I thought when I took a look at jME recently (about 1 month)… The fact is, I didn’t found a complete, friendly documentation for jME as the Xith3D getting started guide… And I told myself I wasn’t gonna change of graphic lib one more time. BUT if it’s for the sake of non-duplication of effort I’ll be pleased to declare jME officially the future of Xith make sure that jME support EVERY Xith features (hey we have users to satisfy ^^) and develop jME as actively as I’m contributing to Xith (not that much but nevertheless valuable).

I’ll create a subject in the Xith3D forums to ask this question.

#4

First of all i’m developing with JME for the last 1 and 1/2 years. I played a little with Xith and i found it way to complex from jme, but that is just my personal opinion. Now that mark and renanse are working at NCsoft there is much activity in jme development and JME’s forums are pretty helpful. I agree with MagicSparks proposal for collaboration since there are many things that can be done in an engine-indepedent way but i disagree with the option of discontinuing xith. Perhaps the best way would be to start a new project based on existing knowledge and more game oriented.

#5

Please explain your opinon here : http://www.java-gaming.org/forums/index.php?topic=13795.0

We will lose 80% developers and the project will be abandoned (IMHO).

#6

Well, jME is currently developing support for JOGL so you can choose either LWJGL or JOGL and jME acts as a nice abstraction layer. That addresses the first point I would hope.

About the forums, I readily admit that it’s been a very long time since I was there, but I was one of the noobs that got left behind. :-p

Your basis for sticking with Xith is because they have a Getting Started guide?

Getting Started:
http://www.jmonkeyengine.com/wiki/doku.php?id=getting_started

A few tutorials:
http://www.jmonkeyengine.com/wiki/doku.php?id=the_tutorials

Of specific interest in the tutorials:
http://www.jmonkeyengine.com/wiki/doku.php?id=flag_rush_tutorial_series_by_mojomonkey

And if that’s not enough you can always look at the dozens of tests that come with jME that show you how to do practically everything jME supports from bloom effects to shadows to cloth texturing to model loading to multi-state games to continuous terrain to even extremely simple tasks like just creating a game.

If you think there’s not enough “getting started” information for jME either you’re looking for something completely different or you haven’t looked close enough. And if that’s not enough you can always post in the forums and rarely does a noob post stagnate for more than an hour before a response is received.

The biggest aspect to me is the extremely well defined scene-graph which Xith (in my opinion) just doesn’t have.

-Matt Hicks

#7

I’m sorry it was the case when you tried it. But it’s not the case at all with that :

I find Xith3D very well designed…

#8

[quote="<MagicSpark.org [ BlueSky ]>,post:5,topic:27401"]
Just a small interesting comparison of jME and Xith features :

(from jME’s website) :

  Sample applications
* Game system allows for maintence of the main game loop
* SimpleGame provides a quick entry point for proof of concepts
* GameState provides ability to change game states (menu, game, credits, etc)

We don’t have them but I don’t find it useful

  Bounding System
* All geometry can be enclosed in a bounding system.
* Boxes and Spheres.

We have it

  Curves
* Bezier curves can be used for node controlling.

Being implemented by Croft

  Bezier Mesh
* For smooth curved surfaces.

Being implemented by Croft

  Effects
* Transition from on scene to another.

Easy to do
* Lens Flare.
Easy to do
* Particle System.
Done by jcd
* Screen tinting.
Huh ? Do they mean having a colored semi-transparent quad in foregroud node ?
* Vertex and Fragment Program Support.
We have it
* Cloth Simulation.
Done by jcd.

  Image Loading
* Support BMP, uncompressed TGA, JPG, PNG, GIF.

Not really surprising as a feature

  Texture System
* Supports mipmapping, environmental mapping, multitexturing.

It’s been a long time since we have these features

  Input System
* Robust system allows for easy creation of input actions.

HIAL is just good for abstraction, do your input system yourself…

  Collision and Picking
* Bounding volume and triangle accuracy.

We have it.

  Lighting System
* Handles up to eight lights at a time with utilities for optimal light selection.

We have it.
* Supports directional light, spot light and point light.
We have it.

  Shadow System
* Z-Pass Shadow Volumes.

Hmm not sure we have it

  Math Library
* Provides faster system for linear algebra
* Use of look up tables.

Useful ? Maybe switching to alternate vecmath would be a good idea.

  Level of Detail
* Discrete Level of Detail using a switching mechanism for fast model switching.
* Continuous Level of Detail dynamically collapses triangles of a single model.

TODO

  Model Loading
* 3DS, Obj, MD2, MD3, Milkshape, ASE support.

No Milkshape

  Shapes
* Box, Cylinder, Disk, Hexagon, Octahedron, PQTorus, Pyramid, Quad, Sphere and Torus support.

We have it.

  State System
* Minimizes OpenGL state changes.
* Allows merging of Texture and Light states in the tree.

TODO

  Camera System
* Maintains camera as a seperate object or a node in the scene.

Why ?
* Frustum culling for efficiency.
Done. And occlusion culling, too

  Renderer Abstraction
* Allows for any rendering API to be implemented.
* Currently LWJGL implemented.

We have JSR-231 also

  Render Queue
* Sorts scene elements based on Opacity. Opaque are sorted front to back and rendered first, then transparent is sorted back to front, last screen elements are sorted by z depth.

Done.

  Render to Texture
* Render any scene to a texture object.

Done by I-dont-remember-who

  Imposters
* Render to texture used to display a single model to a texture, can be animated as slow as needed to increase frame rate.

Easy to do

  Billboard Node
* Keeps a node facing the camera

We have it.

  Shader Support
* GLSL
* Vertex and Fragment Shaders (GL ARB)

We have it.

  Sound
* Supports OpenAL with sounds organized in a tree, similar to the Graphics.

We have it.

  Terrain
* Terrain blocks act as single geometry.
* Terrain Pages implements a Quad tree of Terrain blocks.

Easy to do

  User Interface
* JMEDesktop System allows rendering of Swing components in jME scenes.

We have it. Long before them.
[/quote]

#9

Shall we just put an end to this seemingly endless flame war ?

Both are very very different, each has merits and people chose which ever they are comfortable with…easy as that.

DP

#10

You don’t find GameStates useful? :o You never need to switch between a menu to game (or vice-versa) or perhaps provide multiple games inside one application context?

That is not a complete list of features jME has either. I believe it’s been a while since that has been updated or a few things were just left out. However, by your own admission there are several items jME has that Xith does not. The only thing you have mentioned thus far that Xith has above jME is JSR-231 (and that is being implemented). I would say based on this conversation I’ve got quite a bit of assurance that I’m using the better engine. Even beyond that jME performs much better than Xith in every test I’ve seen. jME still can’t keep up with Java3D on some things, but I don’t believe we’re too far off on exceeding them in performance as well. jME blows everyone away in features alone. Add community support and performance and I’m happy where I’m sitting.

The point of this conversation was to discuss the feasability of collaboration between jME and Xith but I still have yet to see anything but JOGL support that Xith can provide to jME…perhaps I wasn’t reading close enough?

DP, that’s the most tactful reply I think I’ve ever seen you post…impressive. :-p

-Matt Hicks

#11

And I believe that is the first time you complimented anyone thats not a frog…impressive :stuck_out_tongue:

DP

#12

I compliment monkeys and llamas every now and again… ::slight_smile:

However, frogs are the coolest of all animals…I hear that “darkfrog” is something pretty awesome as well…you know him don’t you?

-Matt Hicks

#13

I agree.

#14

I just found this discussion here, and…

I don’t want to continue the ‘war’, but one thing was very interesting for me:

[quote="<MagicSpark.org [ BlueSky ]>,post:8,topic:27393"]
User Interface
* JMEDesktop System allows rendering of Swing components in jME scenes.
We have it. Long before them.
[/quote]
Can you give me some info on this? We still have issues with this and I wonder how it was realized in Xith - or was it another feature that you meant (maybe 3d in swing not swing in 3d)?

#15

Swing in 3D, yeah and it works perfectly (we just have some issues with windowed mode on linux & mac because of the size of the border window so it looks a bit difform but you just have to call the calcPlate() function after window init to fix it !).

You can look at the sources in the CVS : https://xith-tk.dev.java.net/source/browse/xith-tk/src/org/xith3d/ui/swingui/

#16

OK I won’t continue the war either. I got the answers to my questions and have decided to go Xith3D.

So collaboration would go these ways :

Xith3D -> jME :

  • Collada ? (Or you want to develop everything alone once again ;D )
  • Integrated Swing

jME -> Xith3D :

  • Cal3D
  • MD5

By the way, does someone know if there’s an MD5 exporter for Blender ? If not, it’s useless to me (although I’d port it happily anyway). Yet Cal3D seems fine to me so…

#17

I apologize if this is taken the wrong way…not trying to continue the war either…but… :-p

Collada support - we’ve actually already got commercial quality collada support, we’re just waiting for NCSoft to give the go-ahead to donate it back to the community)
Integrated Swing - Irrisor has done a phenominal job on the Swing aspects and though there may be quite a lot that could be gained from collaboration concept-wise I can’t imagine how any code collaboration could really occur here since it’s very explicit to the actual implementing engine isn’t it?

I’ve seen an MD5 exporter for Blender somewhere…if I can find it I’ll post it.

-Matt Hicks

#18

http://home.tiscali.de/der_ton/blender2md5.rar

#19

That’s ok.

Your choice if you want to depend NCSoft forever. That may not be problem for you. And I was wrong, I though it “was going to be implemented”.

Maybe. But I think it’s a bit late to talk with David Yazel (which implemented the original code, IIRC).

#20

[quote="<MagicSpark.org [ BlueSky ]>,post:19,topic:27393"]
Your choice if you want to depend NCSoft forever. That may not be problem for you. And I was wrong, I though it “was going to be implemented”.
[/quote]
Depend on NCSoft forever? Once it is contributed back it then becomes the communities responsibility to maintain so NCSoft contributes great commercial support for Collada and then we can make any updates and changes necessary. I hardly believe that classifies as “depend NCSoft forever”. :-p

I know it may seem that I’m opposed to the idea of collaboration, but I’m definitely not. I am just honestly trying to determine what Xith has that can benefit jME. It sounds like we might be able to gain a lot from taking a look at how the Swing integration is done, but it seems hard to find a lot of common aspects that can be collaborated on. I would say model loading is a very good idea to provide engine-agnostic support in, but how do you go about that? Define one common model type like Collada or some binary format and standardize the implementation in both engines to simply support that one model and then collaborate on all the other model loaders to convert to that format?

-Matt Hicks