Java3d pushing the limits...

Hi, Philjord

Thank you for the interesting information. Well, what is your opinion – is it possible to use your system for simulation of 3D scenes in a video surveillance? I mean, what is you estimation, how many time is necessary to create a simple 3D model of a number of rooms in a building with moving persons to obtain videos for testing behavior recognition algorithms? What additional software tools are to be used for it?

Thank you,

Alexei

P.S. I have no time to worry about the future of Java3D, because I am using it in my Actor Prolog project already... :)

Alexei,
I see 2 issues that (probably) make my code not what you want...

The ElderScrollsExplorer code looks good because it uses the world data from Skyrim and Fallout etc, but the downside of this is the only way to change the data from the what's delivered by the game install files is to edit those files (the ones with the esm extension).

In order to edit them you need to use a tool called Construction Kit (or G.E.C.K), which is very widely used and documented by the game modding community. But it's a monstrous and powerful tool that takes weeks to get to understand and be able to use with any sort of efficiency, it's like the effort required to learn 3DStudio or Photoshop properly.

So that's the first issue, a long ramp up time.

The second is that there is currently no AI in my code at all. Each character is static like the plates and barrels. It does randomly play animations, but it does not move or make any decisions.

So you would need to add quite a bit of code to make them look alive.

Finally, and not so important, is that it will only load models that already exist (unless you also want to make models, which would mean learning Blender...), so your building and people would be forced to look either medieval or post apocalyptic, both good looks but not standard for machine learning...

I'm not familiar enough with other engines to offer a decent opinion on analternative, but I'd suggest Ardor3D and JMonkeyEngine are better places to start.

Thanks,
Phil.

Good job and I agree about “the same as FFP”.

Hi, Phil,

Yes, I read the discussion on the Java game engines with interest. But could you please explain what the advantage of your approach is? Is it a higher level of 3D scene description and, probably, simplicity of programming its modifications?

Thank you,

Alexei

Alexei,
I've been playing with Java game programming for twenty years, I was writing my "engine" before Jogamp, Lwjgl, Ardour3D, JMonkeyEngine, libGDX and especially minecraft existed, so my approach of extending the Java3D scenegraph is looked on as a folly by everyone that's working on the "real" Java engines.

Based on that I'd say nothing I'm doing is easier or simpler :)

The only aspect of what I'm doing that could be considered good practice is the following:

Game engines only exist in relation to an asset pipeline,
The definition of the 3d models (in a file format) allows a game engine to render things and allows it to to do advanced rendering techniques.
The definition of the 3d models (in a file format) allows artist to record what they create, though they create in a 3d studio tool.
The definition of the 3d models (in a file format) dictates file size, load speed, and many other performance factors (byte colors, half floats, compressed geometry etc).

So before you even think about writing a game or 3d application by using any engine or writing a single line of code, you MUST know your asset pipeline, which is at root knowing (or defining) your 3d model file format, and to a lesser extent your compressed texture format.

A lot of Java engines do not come with file formats other than the open ones that Ogre3D and Blender support, for example the .obj format; because of this many, many games are re-written over and over as the file format and everything derived from it comes up short.

So I decided to use a commercial strength format that was leading the way, the nif format, right from the beginning.

And that is the only thing about my work that is "good design", for everything else the other engines are better written and better supported.

philjord wrote

So I decided to use a commercial strength format that was leading the way, the nif format, right from the beginning.

And that is the only thing about my work that is "good design", for everything else the other engines are better written and better supported.

It's highly subjective and questionable. If the developers and the artists used some interchange file formats for long term storage, some editor specific file formats for modeling and editing and some engine specific file formats for loading, they wouldn't have to rewrite everything.

JogAmp's Ardor3D Continuation supports Collada which is a standard interchange file format, you can use Blender or another popular modeller to export to Collada and JogAmp's Ardor3D Continuation has its own binary file format too. If I really wanted to use exactly the same format in the modeller and in the engine, I would rather choose an open standard like the Blender file format which is supported by JavaBlend rather than a proprietary file format.
Anyway, there is a risk of being unable to do anything with a model if it becomes unreadable because of the numerous incompatible changes done in the file format of a modeler (which isn't an interchange file format) or because of the changes intentionally done in a closed file format in order to force the end users to pay to read their files (typical in Autodesk and Adobe file formats including FBX and DXF/DWG).
Therefore, there is no need to rewrite a game when you use a widely supported file format (including WaveFront OBJ even though it's good only for static things). In the worst case, you may have to write an import/export script for the modeller and/or an importer/exporter for the engine. Choosing a closed file format is the best way to put yourself into the worst case, especially if there are a few people using this file format. For example, Blender has no build-in import script for MD2 since its version 2.50.