jMonkeyEngine.org

Dear Monkeys,

since the core developer team isn’t exactly huge and many features of the SDK could be improved on I am calling out for adopters of some plugins. Work on them hasn’t stopped but an additional developer improving the plugin would help a great deal as the core developers are concentrating on some base SDK features at the moment. Some plugins are mature and self-contained enough so that other developers should easily be able to improve them without having to deal with other parts of the SDK too much.

Of course anyone who wants to adopt a plugin gets personal instructions and help as well. For an overview on what plugins are “open for adoption” and what needs to be done / how complex the plugin improvements might be see the following list:

Font Creator – easy
Basically adding proper support for font styles, improving the kerning and some other minor tweaking and adding of options. Maybe add support for multi-page fonts / other encodings than ASCII, e.g. UTF-8.

Android Support – easy
Test and improve the project integration, bring more options to the GUI level.

Obfuscation Support – easy
Test and improve the ant build script for obfuscating the build. Also obfuscate the libraries.

Texture Editor – easy
Add more features, improve integration.

NiftyGUI Editor – intermediate
Add a palette, wrap the complete nifty XML in “Nodes” (started already) so it can be easily browsed and its properties edited. The NetBeans platform brings a lot of support tools for XML so basically its just tying this together. Drag&Drop support for new items on the UI side would be nice.

Vehicle Creator – intermediate
Bring it out of its alpha state, improve features and range of compatible vehicle models.

Asset Pack Support – advanced
Improve browser and supported functions.

Cinematics Editor – advanced
Make an editor for jme3 cinematics incl. visual timeline with keyframes etc.

Annotation error checks – advanced
Make an annotation checker for jME3 that allows checking for values being set on math primitives that should be “readonly”, e.g. Vector3f.ZERO. This kind of checker can be used in any modern IDE. Work has been laid out in googlecode already.

Editing the plugins should be as easy as installing the “NetBeans Plugin Development” plugin in the jMonkeyEngine SDK or NetBeans, checking out the jMonkeyEngine svn trunk at https://jmonkeyengine.googlecode.com/svn/trunk/ , building the contained freeform project once (!) and then opening the “sdk” project inside the freeform project. As the projects are all started, the initial barrier for getting into the code should be pretty low. See the documentation on developing plugins here.

Any help is very much appreciated!

Cheers,
Normen

Hm, can’t really tell why that should be. Try following the short but concise description in the post and read further in the linked documentation if something about it is unclear. If that fails then report back
Maybe make sure the SDK version you use is one that was reinstalled lately as the base platform plugins were reset to earlier versions.

I know this is mostly to non-core folks, but I’ll be working with Android over the next few days. Hopefully improving documentation for the current state of the art and getting some lessons from it that we can apply going forward. Collaborators are most welcome

Dodikles said:
Since I’m right now fighting heavily with Nifty and would love to have something like an easy-to-use editor for laying out, I might as well do it myself and have everyone profit from that. I’m going to have a look into it but cannot promise anything at this point.

Cool! As said, the basics are laid out in the NiftyGUI plugin and its mainly a matter of continuing to wrap the XML in NetBeans nodes so they can be displayed and their properties edited. Then adding a palette / drag&drop support / visual editing.

You can just “run” the SDK project. Theres three project “levels”: The freeform project (purple “triangle” icon) in trunk you only need to build when you make changes in the core engine (jMonkeyEngine3.jar) and want to transfer them to the SDK build. The module suite (yellow icon) is the main SDK project you need to run to start the IDE inside.. the development IDE The single plugin projects (blue icon) are where the actual code is.

Edit: Oh and the whole palette stuff isn’t wired up yet.
Edit2: The parameters should be saved inside the Nodes representing the nifty layout / xml.

After reading through some netbeans platform documentation I wanted to ask things first before starting to implement:

So basically we would have for an UI xml file one NiftyFileNode, which holds NiftyFileChildren which in turn are objects like NiftyScreenNode or NiftyPanelNode that work on DOM elements as API objects.

If this is true, I would need to write something like

public class NiftyScreenNode extends AbstractNode {

   public NiftyScreenNode(String name) {
        super(Children.LEAF);
        setName(name);
    }

    @Override
    protected Sheet createSheet() {

        Sheet sheet = Sheet.createDefault();
        Sheet.Set set = Sheet.createPropertiesSet();
        Element obj = getLookup().lookup(Element.class);

        try {

            Property id = new PropertySupport.Reflection(obj, String.class, null);
            Property controller = new PropertySupport.Reflection(obj, String.class, null);
            id.setName("id");
            controller.setName("controller");
            set.put(id);
            set.put(controller);

            set.setName("Nifty values");

        } catch (NoSuchMethodException ex) {
            ErrorManager.getDefault();
        }

        sheet.put(set);
        return sheet;

    }
}

I guess I would have such a subclass for every possible element like panel, label, layer etc.

What about getters/setters of the AbstractNodes for the API objects? Do I have to implement them in every Nifty*Node subclass?

Yep, exactly. Nodes and children that in the end represent the XML
Edit: Oh, and a factory and actual children are not much different, maybe you can try a base class that uses actual children tho.. No need for a Factory I think, just create a class that implements Children. See for example this class:

http://code.google.com/p/jmonkeyengine/source/browse/trunk/sdk/jme3-core/src/com/jme3/gdeGame Development Environment – The basic definition of jMonkeyPlatform./core/sceneexplorer/nodes/JmeAssetLinkNode.java

Especially note:

public static class AssetLinkChildren extends JmeSpatialChildren {

        public AssetLinkChildren(AssetLinkNode spatial) {
            super(spatial);
        }

        public void refreshChildren(boolean immediate) {
            setKeys(createKeys());
            refresh();
        }

        protected List<Object> createKeys() {
            try {
                return SceneApplication.getApplication().enqueue(new Callable<List<Object>>() {

                    public List<Object> call() throws Exception {
                        List<Object> keys = new LinkedList<Object>();
                        if (spatial instanceof AssetLinkNode) {
                            keys.addAll(((AssetLinkNode) spatial).getAssetLoaderKeys());
                            return keys;
                        }
                        return keys;
                    }
                }).get();
            } catch (InterruptedException ex) {
                Exceptions.printStackTrace(ex);
            } catch (ExecutionException ex) {
                Exceptions.printStackTrace(ex);
            }
            return null;
        }

        public void setReadOnly(boolean cookie) {
            this.readOnly = cookie;
        }

        @Override
        protected void addNotify() {
            super.addNotify();
            setKeys(createKeys());
        }

        @Override
        protected Node[] createNodes(Object key) {
            if (key instanceof ModelKey) {
                ModelKey assetKey = (ModelKey) key;
                return new Node[]{new JmeAssetLinkChild(assetKey, (AssetLinkNode) spatial)};
            }
            return null;
        }
    }

Its a very convenient way to get an easy Children object

The children class basically decides what the actual children of that object may be. So for an xml element it would always return all enclosed elements I guess, however it might be useful to leave out some / add other ones for certain properties maybe. The child class in this case is just another AbstractNode in fact that represents one screen element. Each element would be such a “Child”.