Improving Scene Composer

Hi there guys,
I would like to start working on a series of patche in order to improve the Scene Composer.
The first one and most important is to allow moving lights over the scene.
Who’s with me?

3 Likes

Cool,

this is something I am always reluctant to work on because theres always somebody who wants it differently UI-wise and also when working with UI one tends to want to adapt the base system to how the UI should look which is something I completely want to avoid with the SDK. It should not mimic other editors, it should do things the way they can best be done for jME if you know what I mean :slight_smile:

heres information on how to build the SDK (inside NetBeans or the SDK itself):
https://wiki.jmonkeyengine.org/legacy/doku.php/sdk:build_platform

Heres how to set up the SDK for plugin development and general info on how the SDK code works:
https://wiki.jmonkeyengine.org/legacy/doku.php/sdk:development:setup

Actually the editor interface is supposed to be unified more, at the moment each plugin basically has to implement all functionality from mouse/cam handling down to picking and in-scene widgets. When developing the terrain editor and scene composer it became apparent that there could be a unified API for this which will probably base on the existing “MouseTools” in the scene composer and terrain editor. So you will want to build on these and maybe look into how they can be improved and generalized. The idea would be that single plugins don’t issue scene requests themselves but just hook into the SceneComposers scene request and use its camera tools, see also this issue entry (and the others in the SDK section): Google Code Archive - Long-term storage for Google Code Project Hosting.

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 theres an increased use of exclamation marks and all-capital words.

2 Likes

Sounds like a good idea, the SDK source is actually pretty easy to download and build - didn’t take me long when I did the enhancements to the font creator recently. You should check if anyone else is currently working on the scene explorer first as well, since I know a lot of SDK enhancements have happened recently. @normen is the SDK expert. so will probably know what is going on :slight_smile:

1 Like

Ninjad by the man himself. :slight_smile:

1 Like

I have just noticed all those things you’re talkin’ about. Thanks for the references (i was searching for them).
I’m trying to find some people to discuss and, SURELY, work with!!! In the next days I’ll start to study the whole code, make little changes and see the behaviour.
The only thing is: if we change the “APIs”…we will surely break up the compatibility with both maintained and unmaintained plugins…

1 Like

Yes, the SDK “API” is mentioned to be in flux still so that would be okay. Most “plugins” are only wrapping jme libraries or use NetBeans platform functions directly (like the code completion plugins) so thats not much of an issue. I am delighted to see your enthusiasm :slight_smile: Just get accustomed to how to code/build/extend the SDK a bit and then hit us with your proposals and changes :smiley:
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.

Looks like you’re reading my mind man :woot:

@orfeo18: Btw to avoid later pain make sure you check out the code via https instead of http so you can commit later, gc doesn’t allow commits via http and the url will be stored in the local svn repo, evil pitfall but I think its mentioned in the checkout docs (?)
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.

@normen said: @orfeo18: Btw to avoid later pain make sure you check out the code via https instead of http so you can commit later, gc doesn't allow commits via http and the url will be stored in the local svn repo, evil pitfall but I think its mentioned in the checkout docs (?)
Yep yep it's written I've just used SVN Repos and always developed by extending Eclipse to support logic languages (prolog) http://alice.unibo.it/xwiki/bin/view/Tuprolog/ But I've never used NetBeans so I have to make some initial "training" with this IDE, but I bet it's not so far away from Eclipse.

Yeah, Netbeans is if anything friendlier to use than Eclipse. One thing that may help you is that you can switch netbeans to use eclipse keyboard shortcuts. It’s just a profile you can switch to in the settings somewhere.

Ok guys, I’ve finally found what’s not working in order to move Lights and Audio Nodes. ( 8) feeeeeeeeeeeeeew)
SDK Core’s class:
- SceneToolController
and subsequently SceneComposer’s casses:
- SceneComposerToolController
- SceneComposerTopComponent
they handle only Spatials. Lights/ParticleEmitters/… are entities that share the concept of “position in space” and “orientation” with spatials; a superclass (in SDK Core) is needed in order to abstract enough to get things to work correctly.
As always I’m open for hints and suggestions :smiley:

2 Likes

Heh, wow. I guess you hit the gas pipeline right away with trying to rework this :wink: The ToolController stuffs is actually what should be abstracted to a general input / widget system that should be shared between the plugins. So actually the input/display part and the type selection part should be handled separately. I guess its two interfaces then: The movement / widget and the “what do I do with this when a button is pressed” part.

To explain further… The idea would be that j3o files are always opened by the SceneComposer (or actually the file itself later but thats a detail). Then the SceneRequest should contain some object that the plugins can use to communicate about the state of their tools and if one or the other plugin has control over the mouse and attaches its tools. The plugins would supply some actions that can be put into a toolbar when the scene is opened so that new plugins can just listen to scene requests and add their buttons and input tools. So many of the buttons that are in the special windows now would then move to the main editor window and the bottom windows would remain for special tools that the single plugins bring that can not just be “hidden” in a button. Or for example extended attributes for the selected tool. How far this can be abstracted generally (like for example the single button actions, they would probably be created by some premade AbstractToolAction class or something) I can’t really say as this was something I postponed a bit still. Theres an “editor” package and a general SpatialOpenSupport class that was intended to be used for this (the open support would request the scene and the plugins would jump in) but its only a few classes that don’t really get to the meat of the implementation yet.

Heres the relevant issues on googlecode:
http://code.google.com/p/jmonkeyengine/issues/detail?id=388
http://code.google.com/p/jmonkeyengine/issues/detail?id=493 (posted this one already)

Finally, if you didn’t plan on rewriting the SDK… :wink: I guess the support could be hacked into the moveTools etc. but as you see its already quite the long spaghetti you pulled there :slight_smile:
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

Nice. Let me know if I’ve understood what you mean.
We need to create a sort of “Graphic Server” that handles both I/O and modifications on the Scene and notifies all the registered plugins for changes in order to accomplish tasks (because the plugins will accomplish all the tasks).
Example:
Mesh Added -> Call onAdded(Mesh m) on all registered plugins
Mesh Selected -> call onSelection(Mesh m) on all registered plugins -> All the plugins will show their tools on the toolbar -> user will select which to use.

Am I right?
Sorry if I always go by examples but I’m Italian and I’m not so good with english. :smiley:

P.S. Have you got a nice reference (with examples) on how to write a Netbeans plugin??? I have to pick-up the official reference or you have some good tutorials???

1 Like

@orfeo18: Yeah basically like that, if you look at the current mouse controllers it should be apparent… Maybe a bit more like “Tool type toolbar button pressed → This tool now defines what the mouse and clicking does and how the mouse widget looks”, “Utility toolbar button pressed → This utility now defines what is being done with the selected object”. The single plugins would register their toolbars when the scene is opened and then the user would press one of those buttons, effectively not knowing what actual “plugin” he triggers.

If you look in SceneViewerTopComponent you also see some commented out code that could be used to gather a set of Actions from the global registry to put them in a Toolbar. This way the global action system could be used and the toolbar actions would automatically be assignable to global keyboard shortcuts (those kinds of actions appear in the list w/o any further intervention, just use the wizard to create them).

The SDK overview/setup pages I linked do in turn link the NetBeans developer docs as well as outline the general process of setting up a module / plugin, one of the best resources on NetBeans is their own FAQ :slight_smile: NetBeansDeveloperFAQ - NetBeans Wiki

1 Like

Nice. I bet I’ll start rewriting or better organizing the code in order to make some practice with the APIs as soon as I finish my exams :smiley:
Thanks for your quick answers anyway!

No problem, looking forward to seeing something :slight_smile: I’ll see if I can start the unification a bit sooner than planned so you can pick up from there. Btw the “graphic server” etc. all that is implemented. There is a central app that processes the scene requests etc., check the development docs about the SDK, I put most info together there.
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

I’ve started rewriting the Scene Composer. I’ll try to explain my basic idea.
Scene Composer (for now) is based on a Dynamic Toolbar and acts like a Proxy between the SceneViewer and the generic SceneComposerTool (I.E. TransformTool is resposible for rotating/scaling/moving an object in Scene).
The idea is pretty much simple:

  1. The SceneComposerTool registers to the SceneComposer;
  2. The SceneComposerTool gives to the SceneComposer a CapabilityList (what kind of classes can I manipulate?);
  3. The SceneComposerTool gives to the SceneComposer a ButtonList to be added or removed from toolbar;
    maybe this image will make you understand how does it work:

    So when the user selects something in the scene, the toolbar will be populated with the corresponding buttons according with the CapabilityList of the SceneComposerTool plugins

Registration
To implement the registration process I want to use the Lookup mechanism: the SceneComposerTool registers himself to the Lookup and the SceneComposer will be notified everytime something changes. Now I have a little problem that I haven’t found on the NetBeans guide:
1 - How do I start the SceneComposerTool class?
2 - How do I register the SceneComposerTool class in the Lookup?

Maybe I haven’t understood the guide??? :frowning:

3 Likes

Yeah, that sounds very good. Do not use the lookup system for the callbacks yet though, just use the existing SceneRequest system for now, then it can all be moved to the Lookup system together: https://wiki.jmonkeyengine.org/legacy/doku.php/sdk:development:scene I am not 100% sure if using some Lookup callback would be the best idea anyway. But the rest sounds exactly as intended, theres a central instance where plugins register their toolbar and mouse manipulators so they can be coordinated (who controls the mouse when etc).
Generally you create a Lookup when the object is created and let it gather its data then, for example the AssetDataObject automatically adds its ProjectAssetManager to its lookup. But as said, the Lookup listening is mainly used for direct scene selection changes as the state is a bit too unstable sometimes: https://wiki.jmonkeyengine.org/legacy/doku.php/sdk:development:sceneexplorer
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.

How do I manipulate lights and audio from the Scene? Do I need a Controller for both of them? Using this method I cannot make directly register a Tool to the SceneComposer:

my idea is to use the lookup in order to get the scenecomposer singleton.
Sorry I don’t want to be but I’m very new to JME3 :frowning:

1 Like

Do it via the sceneRequest, its passed to any listener and they register via the global SceneApplication.
So in sceneOpened() you’d go something like: if(request is editor scenerequest){request.addMyPluginToolHandler()}
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