Geertjan's Blog

  • June 17, 2014

Neuroph/JMonkeyEngine SDK Mashup

Geertjan Wielenga
Product Manager

I recently attended a presentation where Milos Randjic demonstrated JMonkeyEngine SDK visualization within Neuroph, together with Tihomir Radosvljavic, who is working on the development of an AI Engine that will be used to integrate Neuroph and JMonkeyEngine SDK. Both Milos and Tihomir are working with Zoran Sevarac (Duke's Choice Award Winner, Java Champion, NetBeans Dream Team member) at the Open Source Development Center at the University of Belgrade in Serbia.

To give an impression of the result of the integrated visualization, here's two screenshots I got from Zoran:

I mentioned this on Twitter, where Sean Phillips, a Duke's Choice Award winner and NASA contractor, then asked how this is achieved. Well, of course, both these applications are based on the NetBeans Platform. That makes it possible to share modules with each other, as the Neuroph team has done, in discussion with the JMonkeyEngine SDK team.

But the question is "how". There are several answers imaginable, here they are.

  • Reuse the Sources. Both of the two projects are open source. So you can download the JMonkeyEngine SDK sources, copy NetBeans modules from there into your own, e.g., Neuroph sources. This is the approach that the Neuroph team took and it is definitely only a good idea if you want to change the sources somehow. I.e., if you want to tweak the sources in some way. But the better approach would be to ask the JMonkeyEngine SDK team to tweak their sources themselves, if making this request makes sense. The Neuroph team mentioned that their main challenge was to make the JMonkeyEngine SDK sources compilable within Neuroph. Ideally you wouldn't have this problem because you'd use one of the other approaches below.

  • Create Library Wrappers. Instead of copying source files, here you take the JARs and wrap them into an existing NetBeans module or create a new library wrapper module that contains the JARs. In general, this is a good approach if you're wanting to incorporate a few JARs that don't already belong to a NetBeans Platform application. Via the library wrapper module project template in the IDE, you can browse to the JARs you need on disk and then you'll have a new module that contains your JARs. Or you can go to the Project Properties dialog of an existing NetBeans module, open the Libraries tab, and you'll see a tab for browsing to the JARs you need on disk.

  • Create Clusters. If you're incorporating JARs that come from another NetBeans Platform application, that is, as in the case of JMonkeyEngine SDK, a set of JARs created and organized as part of a NetBeans Platform application, you can add the entire NetBeans Platform application as a new cluster, i.e., a set of related modules that will be organized into a separate folder in the installation directory, such as 'platform' and 'ide', as described here, as well as here. From the cluster, you can select which specific JARs, which might only be two or three, that you need to include in your application. The user will install your application and then have a new folder named "jme" (or "jmonkeyengine" or whatever the cluster name is that you define) containing the JARs from JMonkeyEngine SDK that you can then treat as APIs, i.e., use their classes as you would any other JARs in your application. You'll also benefit from the public/private package-level settings, e.g., you'll only have access to those packages that have been explicitly declared public.

The latter is the preferred approach that the Neuroph team should take, except if they need to get at the sources somehow, which is not desirable.

As an alternative to incorporating JMonkeyEngine SDK, the team also considered using JavaFX 3D instead. But they decided to pursue the JMonkeyEngine SDK approach, rather than use JavaFX in their existing Java Swing application.

Join the discussion

Comments ( 5 )
  • Sean Phillips Wednesday, June 18, 2014

    The Cluster approach is a great way to share proprietary modules with customers or teammates without necessarily sharing your custom source code.

  • Sean Phillips Wednesday, June 18, 2014

    A note on this concept:

    "As an alternative to incorporating JMonkeyEngine SDK, the team also considered using JavaFX 3D instead. But they decided to pursue the JMonkeyEngine SDK approach, rather than use JavaFX in their existing Java Swing application."

    A question from some readers whom are considering what route to go might be why they chose JMonkey instead of JavaFX 3D. I'm a big fan of both JMonkey and JavaFX 3D so I might offer a suggestion. Zoran from the Neuroph team could have used JavaFX 3D to implement the scene shown above. The benefit would be that it would be a relatively easy implementation. However the drawback of going the JavaFX 3D route is that you have a lower ceiling of capabilities. JMonkey on the other hand is such a polished mature engine that there would be no perceptible limitations for a tool such as this. The draw back is in the integration but given both libraries are common to the NetBeans Platform, this is relatively minor. A nice decision by the Neuroph team.

    For JavaOne I will be working with Zoran to build a JavaFX 3D version of the above 3D scatter plot. We will compare and contrast the JMonkey version vs the JavaFX 3D version in a JavaOne session focused on the capabilities and limitations of JavaFX 3D.

  • Geertjan Wednesday, June 18, 2014

    Great point on clusters, Sean, thanks! And looking forward to that JavaOne session, will be really useful.

  • Zoran Sevarac Wednesday, June 18, 2014

    We needed to make some changes to turn off some windows and dialogs on start, and change Look n Feel settings, so we had to include modified module sources.

    It will be inetresesting session at JavaOne with Sean, and we hope to come out with 3D Visualization API for NetBeans platform at the end.

  • guest Monday, June 23, 2014

    Svaka cast!! Great stuff

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.