Improving Scene Composer

Nice! I’ve solved all my troubles and, after a lot of hours studying a little bit of NetBeans, I’ve found the cleanest way to implement the whole structure.
ANY composer tool will be a separate module so it will be easier to update, easier to make clean code and blablabla…This will allow to download third-party/community/untested additional tools :wink:
I’ll start coding ASAP and send a snapshot of the new system for testing purpose!!! :wink:

@orfeo18 said: Nice! I've solved all my troubles and, after a lot of hours studying a little bit of NetBeans, I've found the cleanest way to implement the whole structure. ANY composer tool will be a separate module so it will be easier to update, easier to make clean code and blablabla....This will allow to download third-party/community/untested additional tools ;) I'll start coding ASAP and send a snapshot of the new system for testing purpose!!! ;)
Well thats kind of the point of the whole thing and why the terrain edtor is a separate module ;) The content of this post is meant to be read as a straight information or question without an implicit dismissive stance or interest in having the other party feel offended unless theres emotes that hint otherwise or there’s an increased use of exclamation marks and all-capital words.
1 Like

We are finally mentally aligned XD XD

Starting to be frustrated: my plugin won’t load. Plugin manager says that “it’s a library”. I’ve created also an installer but nothing, changed category and nothing. It always says it’s a library and won’t let me install it…

Huh? Strange. But what do you need a new plugin for actually? You could do everything in the existing SceneComposer, Core and TerrainEditor plugins I guess?
The content of this post is meant to be read as a straight information or question without an implicit dismissive stance or interest in having the other party feel offended unless theres emotes that hint otherwise or there’s an increased use of exclamation marks and all-capital words.

Solved. I’ve recreated the whole project. I want to rewrite everything so we can get a cleaner playground :smiley:

Okay also cool, but mind you the core SceneRequest system should be kept so that plugins can also take over the scene completely.
The content of this post is meant to be read as a straight information or question without an implicit dismissive stance or interest in having the other party feel offended unless there’s emotes that hint otherwise or there’s an increased use of exclamation marks and all-capital words.

surely don’t worry!

1 Like

Btw Netbeans is a poor tool. I’m trying to use all the Netbeans 7 functionalities…but there’s not so much documentation!!!
I.E. I was going crazy to show the SceneComposer window. Everyone is saying “TopComponent” is a Singleton, but it is not a singleton. A Singleton is something that you can call statically by using the methods instance() or getInstance().
To override this thing the Netbeans Devs created the WindowManager.getDefault().findTopComponent(“Identifier”). But the WindowManager allows to add a lot of TopComponents with the same name and that method gives you the first result.
After going crazy I found a smarter (???) solution via annotations:
[java]@TopComponent.Registration(mode = “output”, openAtStartup = true)
@ActionID(category = “Window”, id = “com.jme3.gde.newSceneComposer.SceneComposerTopComponent”)
@ActionReference(path = “Toolbars/jMonkeyPlatform-Tools”, position = -80)
@TopComponent.OpenActionRegistration(
displayName = “#CTL_SceneComposerAction”,
preferredID = “newSceneComposerTopComponent”)[/java]
the only problem is that the icon is active also if the toolbar is inactive (???) XD
I have to say that Eclipse is MUUUUUUUUCH more smart!!! Back to work!!! :smiley:

Yes, the SceneComposer as well as SceneViewer and SceneExplorer TopComponents are supposed to be singletons. Instantiating them is not planned at the moment. TopComponents per se can be instantiated multiple times though, e.g. for multiple documents. Eclipse lacks support for proper project support, its all very loosely tied and you get practically nothing for free in terms of project management, thats why I preferred NetBeans among other things. I find the NetBeans docs quite exhaustive, just don’t search via google but via their site.
The content of this post is meant to be read as a straight information or question without an implicit dismissive stance or interest in having the other party feel offended unless there’s emotes that hint otherwise or there’s an increased use of exclamation marks and all-capital words.

1 Like

Ok. I’m following the right way. I need to cleanup a little bit the code, but from now I’ve handled:

  • Context Menu action (and double click)
  • Toolbar action
  • Opening the window
  • Opening the SceneViewer with the context (using SceneRequest as you asked)
    I think that these are the most complicated thing for me, since this platform uses paradigms that I’ve never seen!
    Before continuing I would like to ask you:
    Do we REALLY NEED all those buttons in the main toolbar?
    I think that they are not in the right position.

Isn’t there a way to add a custom Toolbar to the ToolbarPool that will be located our scenecomposer window?

1 Like

That would be the idea, moving the buttons to switch between SceneComposer, TerrainEditor etc. buttons down in the upper row of the SceneComposer window and the button from the existing plugin windows in the bottom row (or keep them in their windows for now). The plugin windows and button rows would toggle with the buttons pressed above. Thats why I mentioned the commented-out code to collect the actions referenced in some filesystem folder In SceneViewerTopComponent.

The SceneViewer/SceneRequest system basically works like the Lookup system and shares one object for communicating the state of the scene, its not really complicated. The threading for the jme3 update loop works asychronously.
The content of this post is meant to be read as a straight information or question without an implicit dismissive stance or interest in having the other party feel offended unless there’s emotes that hint otherwise or there’s an increased use of exclamation marks and all-capital words.

Hey orfeo. In the name of our designers I wish you good luck on this, they are really excited about an enhancement of the scene composer :slight_smile:

1 Like
@normen said: That would be the idea, moving the buttons to switch between SceneComposer, TerrainEditor etc. buttons down in the upper row of the SceneComposer window and the button from the existing plugin windows in the bottom row (or keep them in their windows for now). The plugin windows and button rows would toggle with the buttons pressed above. Thats why I mentioned the commented-out code to collect the actions referenced in some filesystem folder In SceneViewerTopComponent.
I'll think better about that. My basic idea is that there is the SceneViewer with selection support. So I have to select an "entity" in the space to popup every tool can manipulate that entity! Maybe if there are too many tools all we get is CHAOS. I told you: I need to think. For now I bet it's better to keep things as before. My basic idea is to have a "better, easier and cleaner playground". One I get there everything is possible.
@tirnithil said: Hey orfeo. In the name of our designers I wish you good luck on this, they are really excited about an enhancement of the scene composer :)
Thank you so much tirnithil (no typo for you nickname, yeeehaw!). I started using JME in order to make a new simple game. But since the SceneComposer is almost completely useless...I need to work here for now (and I hope in the future development of this fantastic SDK). I hope I can accomplish this task. :arrow:

The thing is that the user should be able to switch the “functions” (provided by the plugins) just like he is able to switch between the Terrain and Scene editors now. That requires the plugin to take over the input and controls completely and it can not be decided on by the current selection because there could be multiple plugins operating on the same kind of scene object with multiple different mouse input tools, widgets and manipulation effects. Or did I get something wrong?
The content of this post is meant to be read as a straight information or question without an implicit dismissive stance or interest in having the other party feel offended unless there’s emotes that hint otherwise or there’s an increased use of exclamation marks and all-capital words.

The SceneComposer will switch control between the plugins. If a button comes from the plugin X, then (when the button is clicked) the plugin X will be the one that controls mouse and keyboard. In order to accomplish this task all the buttons will come with one or more InputListeners (still I don’t know the name of the class) associated.
For an easier SceneComposer plugin development there will be a factory to create all the buttons :wink:
I think this will work…and I hope to not be wrong.
So the steps are:

  • select an entity
  • show on toolbar all the tools that supports this entity’s manipulation
  • onclick:
    *** Remove the control from the last plugin’s tool
    *** Give the control to the new plugin’s tool associated to the button

Obviousely the “selection tool” will be always enabled. This is not a problem for now. We’ll talk about as soon as I get into the real problem (and i review the code)…
Uh I forgot: I want to add, for each tool, a sort of “property panel” in order to give the chance to configure the tool’s behaviour.

2 Likes

How you put it? “Now we are mentally aligned” :wink: The actual selection and what you can select might be dependent on the tool as well though, you gotta see how well such flexibility can be implemented, no need to forcefully put that in if its becoming too complicated.

Edit: The “properties panel” for that tool would probably what the main plugin windows are now (the SceneComposer and TerrainEditor windows). Not going with the default “properties” selection or displays of NetBeans will probably be better here as I guess some tools better have special displays, like the terrain editor now. So maybe unify that too or just let each tool have its own and bring them to the front on tool selection.
The content of this post is meant to be read as a straight information or question without an implicit dismissive stance or interest in having the other party feel offended unless there’s emotes that hint otherwise or there’s an increased use of exclamation marks and all-capital words.

2 Likes

@orfeo18 i wrote a small world editor. And i think I want to add some of my stuff to SDK.
http://hub.jmonkeyengine.org/forum/topic/simple-world-editor/

When you finish the most part of refactoring just give me to know. I’will try to dig into SDK too. To make the best SDK all over the world. :slight_smile:
Also, we can do it together.

@mifth said: @orfeo18 i wrote a small world editor. And i think I want to add some of my stuff to SDK. http://hub.jmonkeyengine.org/forum/topic/simple-world-editor/

When you finish the most part of refactoring just give me to know. I’will try to dig into SDK too. To make the best SDK all over the world. :slight_smile:
Also, we can do it together.

Wooow!Nice!!!Currently I’ve stopped development because my girlfriend is in city and I have to prepare some cool and hard exams for university…btw I think I’ll post the code to github as soon as the final code structure is ready, stable and rock-solid. I’m excited to have someone else to work with!!!

@orfeo18 said: Wooow!Nice!!!Currently I've stopped development because my girlfriend is in city and I have to prepare some cool and hard exams for university...btw I think I'll post the code to github as soon as the final code structure is ready, stable and rock-solid. I'm excited to have someone else to work with!!!

My skills are very weak… but i want to try…

I don’t know multythreading, and other SDK/Swing stuff…
But anyway i can do something helpful for tools. As you already saw my editor…