My view on jME3 (as it is right now)

Development
1

So I've been playing with jME3 today, I've basically converted my test environment to use jME3, and I have to say that that was quite some work. After speaking to Erlend, we decided it'd be a good idea to voice my concerns/problems to you, developers and fellow users, for insight or ideas :slight_smile:



Geometry

In general, I think the learning curve for jME3 is steeper than for jME2, because of the Geometry system.



From jME2 tutorial 2 (changed it a bit):


Sphere s = new Sphere("My sphere", 10, 10, 1f);
s.setModelBound(new BoundingBox());
s.updateModelBound();
s.setDefaultColor(ColorRGBA.Blue.clone());



This is easy, it makes sense (or atleast it makes perfect sense to me). This piece of code now converts into


Sphere sphere = new Sphere(10, 10, 1f);
Geometry sphereGeom = new Geometry("My sphere", sphere);
sphereGeom.updateModelBound();
Material mater = new Material(assetManager, "/resources/Common/materials/SolidColor.j3md");
mater.setColor("m_Color", ColorRGBA.Blue);
sphereGeom.setMaterial(mater);



Now, I understand why this geometry system works like this (as explained by Momoko_Fan) but it just looks so cluttered. This brings me to my next point, materials.

Materials
Although partly explained aswell, I don't see why an object has to have a complete material definition for a simple static color.  If it cannot change, no problem, but please return this in every 'setX' method to allow chaining :)


Material mater = new Material(assetManager, "/resources/Common/materials/SolidColor.j3md")
                                 .setColor("m_Color", ColorRGBA.Blue);



Now this material definition file..even though they are not hard to understand, it feels like they require a lot of extra work to achieve the same. I understand they are much more versatile, since pretty much anything can be done in the material definition files (or..potentially everything :P), but a material def file for a solid color?

App Initialization
I had to do this:


final TestEnvironmentApp app = new TestEnvironmentApp();
        app.setShowSettings(false);

        final AtomicBoolean done = new AtomicBoolean();
        final AtomicInteger result = new AtomicInteger();
        final Object lock = new Object();

        final SettingsDialog.SelectionListener selectionListener = new SettingsDialog.SelectionListener()
        {
            public void onSelection(int selection)
            {
                synchronized (lock)
                {
                    done.set(true);
                    result.set(selection);
                    lock.notifyAll();
                }
            }
        };
        app.settings = new AppSettings(true);
        SwingUtilities.invokeLater(new Runnable()
        {
            public void run()
            {
                synchronized (lock)
                {
                    SettingsDialog dialog = new SettingsDialog(app.settings, TestEnvironmentApp.class.getResource("/resources/Common/images/banner.png"));
                    dialog.setSelectionListener(selectionListener);
                    dialog.showDialog();
                }
            }
        });

        synchronized (lock)
        {
            while (!done.get())
            {
                try
                {
                    lock.wait();
                }
                catch (InterruptedException ex)
                {
                }
            }
        }
        app.start();



Because I couldn't find a way to customize the settings dialog's image. Is this going to change?

Now for more..positive points!

Skybox
I like what you did with the Skybox. It just turned into a Geometry, which results in more abstraction, and has become more versatile.

Libraries
Love everything about it! Physics is in there, NiftyGUI is in there, don't have to worry about lwjgl natives - I didn't have to go hunt for the right files myself, it was simply a change of dependency directories and off I went!

Some questions:)
CameraNode, LightNode - are they going to be in jME3?
Is the settings dialog image going to be easier to customize?

I've found that some of the tests don't work (apparently Nvidia GeForce 9400M doesn't support HDR?), but all in all - I do like jME3, and will continue to work with it. Please don't see this as too much of criticism, just trying to wrap my head around things! Great job on jME3, and keep it coming :D
2

Thanks for the input,



I can somehow understand the complaints about materials and geometry, but its only true when you look at the simple cases of creating boxes and such. In jme2, when you would want to have a shader and some lighting going on in a material, you would have to create a renderstate and load the shader in code etc.



Jme3s material system allows completely flexible handling of materials and how they are created. In the future the j3m files will be reloaded by the models so you can add complete material sets for different systems (with/without shaders etc.). So you are supposed to use j3m files and not do it programmatically in most cases.



For the "complicated" creation of geometry I have to say: The mesh and the material are what makes up the final geometry, both require special handling and I think its a good thing to remind the user of the existence of both. Almost no production game will want to use "simple" solidcolor geometry anyway :slight_smile:



Cheers,

Normen

3

Thanks for the explanation, I do understand the train of thought behind this better now. You're right, and I kind of thought about this as well - yes it's a bit annoying to create a simple box with this system, but mostly only new people are going to do that, why not explain them the basics of Geometries, because when they are going to anything more complicated than simple boxes, they're going to need the material system - then they're going to like that they've already learned how to use it. Okay, I can see that :slight_smile:



You're don't usually put gray boxes in your super-cool game :wink: Unless it's about super-cool gray boxes :slight_smile:



Thanks, I understand it better now :slight_smile:

4

The material system of jME3 operates at a higher level, so it is easier to achieve advanced effects, however that also means more effort is needed to achieve a simple effect.

It might take a lot of lines to create a box, but it only takes two lines to load a game level:


assetManager.registerLocator("wildhouse.zip", ZipLocator.class.getName());
Spatial scene = assetManager.loadModel("main.scene");

5

Another question, why can only one binding per axis (and negative) be registered for registerMouseAxisBinding? I wanted to catch mouse axis events, but still allow the flyCam to operate. I saw in the code that they are saved in an IntMap, on their axis as int, and name as String, so only one registrar per axis is possible. What I did now is


//inputManager.registerMouseAxisBinding("TestEnvironmentMouseXdddddddd", 0, false);
//inputManager.registerMouseAxisBinding("MouseY", 1, false);
inputManager.addBindingListener(this);

(...)

public void onBinding(String binding, float value)
{
    flyCam.onBinding(binding, value);
    if (binding.equals("FLYCAM_Up"))
    {
        System.out.println("VALUE: " + value);
    }
    (...)
}



But it feels kind of hacky. It works though :P Is this the preferred method? Why only one registrar per axis?
6

If it is about solid color materials, I personally used them if I wanted to do a debug drawing. To be more precise, I always had in my scene: x, y, z axis (red, green, blue) + some grid on the x,z plane so that I could see where am I placing models in the 3D world. So I think that having a possibility to create solid color material is as important both for beginners and advanced users (debug).



PS: Is there a documentation about jme3 material files available somewhere?

7
woytah said:

If it is about solid color materials, I personally used them if I wanted to do a debug drawing. To be more precise, I always had in my scene: x, y, z axis (red, green, blue) + some grid on the x,z plane so that I could see where am I placing models in the 3D world. So I think that having a possibility to create solid color material is as important both for beginners and advanced users (debug).

PS: Is there a documentation about jme3 material files available somewhere?

You can use processors to create wireframes regardless of the material applied.
Documentation of materials is coming. For now, hae a look at the j3m (Material) files in the jme3testdata.jar file and the j3md (MaterialDef) files in the jMonkeyEngine3.jar that are used by the j3m files.
8

But if I use such processor (I failed to find it by my self in jMonkey source) is it possible to adjust it's color? Could you provide an example code of its usage for creating coordinate system axis?

Good to hear, that documentation will be available soon ;]

9
Levia said:

Some questions:)
CameraNode, LightNode - are they going to be in jME3?
Is the settings dialog image going to be easier to customize?


mhm.. I've implemented CameraNode for jME3 (LightNode won't be too hard from that), only the core developers can tell whether they'll go in or not.
look at this thread: http://www.jmonkeyengine.com/forum/index.php?topic=13826.msg100845#new
10
tim8dev said:

mhm.. I've implemented CameraNode for jME3 (LightNode won't be too hard from that), only the core developers can tell whether they'll go in or not.
look at this thread: http://www.jmonkeyengine.com/forum/index.php?topic=13826.msg100845#new

Sure, your controller looks great. Its just that right now we're messing less with the jme3 code.. I am quite sure we'll throw it in.