Another current topic is 3D engine abstraction, which would allow to replace Java3D e.g. by Xith or jME.

How much engine abstraction do you want ?

Switching an entire engine would be hard and i don't really know why you would want to do that. The java game engines i know currently in activity, xith, jme and agency9 all have a renderer class sort of that allows those engines to switch between one of the opengl bindings or just use a software rendering api (correct me if im wrong). This is a sort of abstraction.

Another type of abstraction is scene-graph abstraction. In this case i don't know of any Java engine thst does this except perhaps xj3d (through x3d) that isn't really a game engine. If you really want the maximum of abstraction possible build a game engine that reads x3d (with the extensions for suporting shaders) and let your game be truly data-driven.

You don't need to do this the way xj3d does (interpreting a set of x3d files). A more flexible way would be to create a x3d to java source translator then compile the generated java source. You could have different translator variants to translate to different engines.

Thats my sugestion.

NOTE: Blender has a nice x3d exporter, something also made opengl and jogl exporters for blender. If you know something about Blender and python you could consider making a blender exporter to your choice of engine source code.

OpenGL abastraction or such are far too low level. FG doesn't even has interfaces to that level.

Scenegraph abstraction would be extremely difficult due to the rich set of functionality and classes. This would be a lot of work just leading to the least common denominator. And FG doesn't really rely on the engine to be a scenegraph. It fits well, but a SG isn't mandatory at all.

What I have in mind is application level abstraction. Thus the interfaces will be 'Terrain', 'Airplane', 'Tank' and such. The abstraction should cover the complete 3D world including collision detection or picking.I think that is approximately the abstraction level seen when going from CounterStrike to CS source.

The reasons to do so are manifold. First, I'd like to stick with Java3D (a) its already there, (b) I wanted to stay as Sun-friendly as possible relying on industrie standards and (c) keeping the way open towards cave rendering and such. The idea behind that is that FG isn't too much of a game but also reaches out for areas like simulation. OTOH, jME or Xith3D seem to be much more suitable for a game. We had a rough port to xith once and all of the sudden had a smooth and highly performant game. But even a native OGL-engine would fit easily under that hood without influencing the rest.Maybe more important: this level of abstraction also allows for an 'engine' that can run on the server (FG *is* a network thing!).

My personal problem today is that there is not much time for myself to work on the project. I have a job (that sucks) and a sparetime job to buy my family a nice vacation trip. If I had time, I'd like to focus on networking, architecture and physics. So at least the complete 3D part is vacant ...

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org