Probable GDE integrationsto be implemented at a later point - please comment/offer help!
particle/fx creator
code templates for scene objects
terrain editor (needs proper jme3 terrain system)
scene editor
material editor
shader editor
GUI editor
Possible GDE integrationsideas and possibilities
Community-driven code snippet database
Texture manipulation/tools (normalmaps etc.)
If you have any ideas about features for jMonkeyPlatform please post them here (ideally with concrete hints on how to integrate the feature) Those of you that already have started projects that would fit into the GDE can contact me about integration of those into the GDE. If you have no experience with NetBeans module development, rest assured that integration of existing Swing components will be quite easy and it is in general not very different from developing standalone software. Those that already have experience in developing NetBeans modules, unleash your knowledge ;)
Please note: The choice of the NetBeans Platform is final, and arguments for/against is for a different topic. The choice was based off of core developers' preference and we are confident it will be the quickest and cleanest way to implement GDE capabilities, all considered.
In no way does this make JME3 'NetBeans Exclusive'. Rest assured, base libraries of jme3 can always be used without the GDE, so you can use the jme3 libraries with Eclipse for example to create your programs like you are used to. Still, you could use the GDE and its tools to import models etc.
Imo this is a good idea. One thing that lacks with many engines out there is a coherent toolset. While it's good not to force people into a certain development paradigm (e.g. the concern of that only netbeans can be used to develop with jmonkey), I think having real quality tools is a must-have and far outweigh any disadvantages.
Does asset management include converting content files to j3p binary at compile time?
It will include importing models and scenes and other assets and saving them in a jme3 compatible format. Handling of assets can be donw via a nice browser window. The jme3-pack function will be removed from jme3 in favor of normal jar packages. The j3p feature did not bring the advantages hoped for.
After taking my first hard look at the Netbeans platform, it does look nice :) I especially like how untethered to the platform they all feel (In contrast to Eclipse RCP which almost never sheds the identity of Eclipse). Thanks for forcing my eyes open
Is it also planned to arrange the scene like e.g. monkeyworld3d tries to?
Basic scene editing will certainly be something thats addressed sooner or later. The first version will include a viewer for imported models/scenes incl. content tree view.
For more advanced things that need more than just a gui interface and will not be included in every project, a combination of library and GDE plugin would be appropriate, e.g. game entities with AI or physics simulation.
What about having a CSG-based map editor like Valve Hammer? I believe such tool will be handy for FPS games and it is much easier and more powerful to use.
Something I would personally like to see (this aplies more to the scene editor part) is a "SelectedObject" class that looks something like this:
public class SelectedObject {
public static Spatial currentSelection;
}
this so it is easier for other programs to interact with the scenegraph (for instance a model editor or event editor that needs to know what to influence. Spatial could be changed to Object as well, maybe even better.
If this is not the place to metion it I apologize.
A map/terrain editor would certanly be great, but the jme3 terrain engine has to be brought into shape first…
The gde will have one window with a rootNode that other plugins/features can use to display stuff. It will contain a tree view of the things it displays and could also be used to select and manipulate the objects shown in the window. Multiple OpenGL windows would be a bit of an overkill for the computer…
Have a look at a first screenshot here. Notice ogrexml file handling and the template based project with separated asset folders.
normen said: Have a look at a first screenshot here. Notice ogrexml file handling and the template based project with separated asset folders.
Looking good :)
Do you think it would be beneficial to use a regular folder icon for asset management? I found it a bit confusing to see package icons next to things like "fonts", "materials", and "models".
Do you think it would be beneficial to use a regular folder icon for asset management? I found it a bit confusing to see package icons next to things like "fonts", "materials", and "models".
This is basically how it looks when you have multiple source folders in NetBeans. Since the j3p feature is going away, a separate folder for the assets is needed to pack the assets jar easily. Maybe it could be removed from the project view altogether, but I am thinking about making models for example expandible there (tree) to browse them from the project view.. Lets see how it comes out in the first pre-alpha, then theres still a chance to change it, maybe even just the icon :)
Edit: but in fact those folders become part of the classpath, so.. dunno lets see :)
ttrocha said: come on,...let him do what we wants to do and don't come with something like changing icons after a very first screenshot....
I was hesitant in posting it in the first place because I'm well aware that it seemed childish in the first place but at the same time I was already seeing the "HELP!" threads about why the assets weren't 'showing up in the code' or something like that. In terms of making it easier for folks to understand it seemed like an appropriate thing to at least bring up :)
I was hesitant in posting it in the first place because I'm well aware that it seemed childish in the first place but at the same time I was already seeing the "HELP!" threads about why the assets weren't 'showing up in the code' or something like that. In terms of making it easier for folks to understand it seemed like an appropriate thing to at least bring up :)
Yea, no matter how easy you make it there will always be the troll who didn't get it.. :) Actually the input was very welcome, I was just thinking about this structure and if the package icon would be a problem. In the first alpha it wont be a source package anymore but a tree completely created by me/the gde incl. icons :). So everything Skye ever wanted is going to be there :P
This will reduce setup time for a developing environment, probably making it easier for a lot of people to jump into jme. Also the NB RCP allows for plug-ins right? This will also make it easier for the community to write plug ins, like maybe porting the terrain editor to a NB-RCP plug in.
Would love to have some extra tools there like a shader designer, particle editor, texture tools, so all the stuff needed is within the app.
There's an OpenGL plug in for NB but I haven't use it much except for shader work.
Well, hope this continues to bee under development and I await anxiously to test it!
I'd be interested in what came out of an attempt at creating a shader designer. The ones I've played with thus far have always felt clunky and unintuitive to use.
