Improving Scene Composer

Contribution Depot
61
@normen said: Well we already have a TopComponent that opens when you click on a scene.. As was said in this thread the buttons to select editors/plugins would move to the main editor window, they'd select the current manipulation tools (terrain, composer, etc.). There will still only be one instance of the editor for now. Additional window elements by plugins can be shown at the bottom, basically like it is now for the terrain editor, vehicle editor and scene composer. The material editor would not be a part of the scene editor but still works "live" in scenes when you edit materials that are in the scene, as it does now. The SceneExplorer is a global thing and cannot be integrated in the editor window, you can move it to any place you like with the window layout manager however.

Explaining why these things are done as they are coming from the angle of user-level ideas is kind of futile. For example the “one scene open at a time” limitation depends on engine functionality, the way certain windows are embedded and selections are handled are defined by the framework etc. Everybody has an opinion on where a certain button should be, when I ask questions about hard implementation issues (like here) nobody chips in. I mean, with no hard feelings, why do you want to know these things? The UI is a means to interact with the data, not a way to structure it.

As an implementer who is actually concerned about work flow, and as I am also the one who will be using this, I am absolutely interested in UI layout and how things operate and integrate.
And as the UI is a means to interact with the data, the UI should be so that it provides the least painful way in doing so. And the current approach is, plainly speaking, a pain in the ass.
And so is the UI editor provided with the netbeans framework, especially when using layouts. Yet, I believe that the peops over at the netbeans development team are keen on improving the overall UX in order to make more people happy when using their UI designer.

62
@axnsoftware said: I do not know what happened to the OP "Orfeo Ciano", but something or someone must have really pissed him off.

So, frankly, and having experienced your team’s overall demeanor towards newcomers who want to contribute to this project and who are still in the learning phase, I doubt that you will ever find yourself in a position where you actually encourage people other than so-called heroes to become involved. Perhaps you should go into yourselves and begin questioning your own ability and knowledge instead of taking for granted that the newcomer’s ability and knowledge is much less than yours. Especially when it comes to motivating people from the outside. The displayed arrogance and ignorance towards external input, and from what I have perceived so far on this forum, is by far worse than what I have experienced on any other forum so far. It is more like a GuildWars in-game chat sort of thingy where everyone is involved in their own private fantasy world and some of which might share their same feable view on that virtual world and shutting out anyone who might be interested in joining as they are not part of the “team”. No wonder most threads on this forum end in frustration and anger, and, initially interested people who were willing to provide new input, leaving and abandoning the project.

And this does not stop there, no, as you are unwilling to provide people with the possibility to provide code in a form that is not diff/patch based. The integration of such patches is difficult as was the case with the Linux project. Hence the invention of the distributed git repository. And subversion does no longer suffice, as it supports you in preventing outside people from contributing, as you may well have noticed.

Do not get me wrong, I will not and do not want to diminish any of you or your team’s personal achievements for the benefit of the project, as these clearly stand for themselves. But it is your “teams” demeanor towards external input and newcomers who would like to contribute that annoys me and you do everything in your power to actually piss people off. I would call that mobbing if you like.

And if you have ever read my question, it was not about the existing code but rather about the idea, and which is not essentially only yours, of how the existing scene composer and other tools could be revamped to make the SDK experience more fluid and less cumbersome.

To quote:

Personally, you do not want to make use of me and I would not let you to. I want to make use of the JME3 engine and the SDK. And I would like to contribute in order to enhance the SDK. That statement of yours is so full of arrogance and ignorance towards my original and absolutely valid question and attempt to summarize what I think would be my gist of this thread beyond all the noise and rant.

And, frankly, this thread contains bull. It does not even contain any new or even elaborated on ideas except for random noise and a few links to from-the-top-of-my-head side notes posted on the issue tracker and from which no one but the author can make any sense unless they know the code very well.

Except for my post above >|

Now, go and ban my account.

Well you see exactly those people here on the forum that verbosely announce the deficiencies and remedies for the engine and never turn up with any usable code or help. The people in the core team all started to contribute or came up with complete contributions by themselves, if you consider them “heroes” then I suppose yes, this is only a job for heroes. I ask again, who is supposed to do all the work you are asking for? I wrote the SDK alone apart from the TerrainEditor and the ShaderNode Editor, I only have limited time to keep the documentation and things like that updated. When I say I don’t have use for a programmer that needs me to understand the code I don’t mean that I’m too great to get involved with him, it just means that I don’t have the time to babysit somebody through it. Heck, I don’t even have a CS degree and I managed to understand how the NetBeans platform works…

Just look at what you are asking for, I am supposed to make a branch, write documentation and outlines and you don’t even answer my questions about what audience it would be for or what you personally want the information for. All I get is yet another assessment by you about the work that we / I do.

All contact with “Orfeo” I ever had is in this thread, you show me where the part is that could pissed him off. And yes, I said from the beginning that to understand what is said in this thread you have to have the SDK code in front of you, I say in this thread that many of these things are not set in stone and if you came to implement it you could decide how exactly it would look. So in case you are done ranting you might want to actually answer my questions or pose actual implementation questions?

63
@axnsoftware said: As an implementer who is actually concerned about work flow, and as I am also the one who will be using this, I am absolutely interested in UI layout and how things operate and integrate. And as the UI is a means to interact with the data, the UI should be so that it provides the least painful way in doing so. And the current approach is, plainly speaking, a pain in the ass. And so is the UI editor provided with the netbeans framework, especially when using layouts. Yet, I believe that the peops over at the netbeans development team are keen on improving the overall UX in order to make more people happy when using their UI designer.

Well it looks like you should help the NetBeans team instead then, we’ll merge over your changes gradually.

64

Editors are a slippery slope. What works for one game might not work for another. So you have to prepare for many cases. It is incredibly time consuming.
UDK and Unity have good editors, but they also aren’t free. Heck if we could pay a single developer for 1 year to work on the SDK it would be skookum.

What is good about free and open source is that if someone can dig in and create patches, the code will get in there and everyone gets the new features. That’s how all us devs got here: contributing code, dealing with the existing code base, and understanding that every single person working on the project is a volunteer.
We have integrated several SDK changes from the community. The more the better.

65
@normen said: [...] I ask again, who is supposed to do all the work you are asking for? I wrote the SDK alone apart from the TerrainEditor and the ShaderNode Editor, I only have limited time to keep the documentation and things like that updated. When I say I don't have use for a programmer that needs me to understand the code I don't mean that I'm too great to get involved with him, it just means that I don't have the time to babysit somebody through it. Heck, I don't even have a CS degree and I managed to understand how the NetBeans platform works..

Heck, again, I also do not have such a degree and I am also the last who would ever care about such. And, considering my age :D, I also manage to get a grip on how that frickin’ platform works. Yet I am still learning about the details.

As such, I wanted to know from you, how you would envision the next level of integration of plugins into the scene composer and an open ide standards based approach for plugging in new functionality into the existing composer such as tools and so on. As such, I have presented you with a mock-up of how the gui should be like, namely, getting rid of the more or less redundant and space consuming info panel and the additional tools panel in the scene composer and reducing it to the toolbar alone, effectfully combining it and the scene viewer into a single tab. The missing functionality of adding a character control or a physics control can then be moved to the scene explorer/properties window or an additional dialog/wizard.

Having read about the @ServiceProvider annotation, I think that we could consider that as a starting point for allowing plugin developers to provide extra tools for specific nodes into the system, say, a service provider interface SceneComposerToolProvider:

interface SceneComposerToolProvider

 public boolean supportNodeType(Class nodeType)
 public Class[] getNodeTypes()
 public SceneComposerTool[] getTools(Class nodeType)

would be queried for the node types for which the tool provider provides any tool for the currently selected node type, e.g.

 providers[] = Lookup.get...SceneComposerToolProvider.class
 for provider in providers
     if provider supportsNodeType(selectedNodeType)
         for tool in provider.getTools(selectedNodeType)
             add to or replace existing tool in toolbar

I presume, that the standard actions for the composer will remain the same, namely, move/scale/rotate and so on. Yet, additional actions need to be available, for example when clicking on audio nodes, numerous extra tools should become available in the toolbar, for example edit :D. The other tools should then adjust to the currently selected spatial, for example when scaling an audio node one might expect that to be the range within which that audio node could be heard and so on. And, when right-clicking on an audio node in the scene explorer window, we should be presented with options such as editing the audio using an external editor, or, depending on the nature of the audio, say procedurally generated, open an editor that allows one to edit the source configuration file or Java source for that node and so on.

Apart from that, I have begun to refactor the existing code and get rid of the single application limit. Effectfully moving out the core.scene to a separate module with reusable components.

66

Yeah, thats how it could look. Again, the one application limitation will stay. You can look at an example of a multi-window / multi-application SceneApplication in the sdk core package, its not used and it doesn’t work as I said due to limitations in the engine.

As I also said already, reacting to selections in the SceneExplorer is already possible, I explain how it works in the SDK development documentation:

As you see in the documentation, adding actions like “new character” or “add box” are very easy to add already, too. Its just one class and it already handles threading, undo and everything else basically.

67
@normen said: [...] and it doesn't work as I said due to limitations in the engine.

Could you please elaborate on why the engine would not allow this?

For my part, I only see the limitation in the core.scene.SceneApplication which is modeled as a singleton. On the application’s behalf, it has its own oglpanel and what not. Therefore, I do not see any limitations there right now.

I mean, scene composer instance 1 uses app instance 1 and after that is was deactivated, the application will be paused. Now, the user opens another scene and starts composing that. The scene will have its own instance of the application.

After the user selected scene composer instance 1, the second instance will become deactivated and pause the underlying application. The first application will be resumed.

68
@axnsoftware said: Could you please elaborate on why the engine would not allow this?

For my part, I only see the limitation in the core.scene.SceneApplication which is modeled as a singleton. On the application’s behalf, it has its own ogpanel and what not. Therefore, I do not see any limitations there right now.

Just try out the existing TopComponent, activate the SpatialOpenSupport and see what happens when you open a j3o in that window. Ask @Momoko_Fan why this cannot be circumvented. SimpleApplication is not designed as a singleton, what makes you think that?

69
@normen said: Just try out the existing TopComponent, activate the SpatialOpenSupport and see what happens when you open a j3o in that window. Ask @Momoko_Fan why this cannot be circumvented. SimpleApplication is not designed as a singleton, what makes you think that?

Hm, I think we have a race condition here. I just edited my post :smiley:

Apart from that, neither SimpleApplication nor Application is a singleton, yes. The fact is, though, that SceneApplication is. And that is, IMO, what causes the problem. Along with the other code that relies on SceneApplication to be that singleton.

70
@axnsoftware said: Hm, I think we have a race condition here. I just edited my post :D

Apart from that, neither SimpleApplication nor Application is a singleton, yes. The fact is, though, that SceneApplication is. And that is, IMO, what causes the problem. Along with the other code that relies on SceneApplication to be that singleton.

This is a bit backwards. SceneApplication is a singleton because Application cannot be instantiated twice and render. Can we stop this discussion now? Until further notice the editor will be a singleton. As I said in this thread the plugin system should be modeled so that it can support multiple editor windows in the future but this will not happen any time soon. If you want to know how it could look in the future, again, look at the existing code for the multi-application editor.

71
@normen said: This is a bit backwards. SceneApplication is a singleton because Application cannot be instantiated twice and render. Can we stop this discussion now? Until further notice the editor will be a singleton. As I said in this thread the plugin system should be modeled so that it can support multiple editor windows in the future but this will not happen any time soon. If you want to know how it could look in the future, again, look at the existing code for the multi-application editor.

Hm. You said:

SimpleApplication is not designed as a singleton, what makes you think that?

And now you say, that the

application cannot be instantiated twice.

My brain was forged for nearly 42 years and the above gives me some headache as to its fundamental logic.

Apart from that, I will try what I can with making this possible and model the API accordingly.

And where can I find the multi-application editor?

72
@axnsoftware said: Hm. You said:

And now you say, that the

My brain was forged for nearly 42 years and the above gives me some headache as to its fundamental logic.

Apart from that, I will try what I can with making this possible and model the API accordingly.

And where can I find the multi-application editor?

The renderer is the issue, not the application, no logic problem here.

The other SceneApplication class, I don’t know off the top of my head what package. Maybe com.jme3.gde.core.editor

73
@normen said: The renderer is the issue, not the application, no logic problem here.

The other SceneApplication class, I don’t know off the top of my head what package. Maybe com.jme3.gde.core.editor

Okay, I will have a look into that and see what I can provide you with.

As for gde.core.editor.SimpleApplication, this is not used by the scene viewer, as it uses its own FakeApplication.

As for the renderer. I think that you mean that multiple renderers would compete over existing GPU/RAM resources.

Well, then, this might be solved by stopping an application as soon as the scene composer window becomes deactivated, freeing up existing resources, or,
according to this post: http://hub.jmonkeyengine.org/forum/topic/running-multiple-instances-of-jme-in-multiple-jframes-possible/
by abstracting away the underlying application and providing multiple view ports which are attached to different scene nodes. At least for a single project.

74
@axnsoftware said: Okay, I will have a look into that and see what I can provide you with.

As for gde.core.editor.SimpleApplication, this is not used by the scene viewer, as it uses its own FakeApplication.

As for the renderer. I think that you mean that multiple renderers would compete over existing GPU/RAM resources.

Well, then, this might be solved by stopping an application as soon as the scene composer window becomes deactivated, freeing up existing resources, or,
according to this post: http://hub.jmonkeyengine.org/forum/topic/running-multiple-instances-of-jme-in-multiple-jframes-possible/
by abstracting away the underlying application and providing multiple view ports which are attached to different scene nodes. At least for a single project.

/sigh

Well, go ahead and rewrite the SDK and the renderer if you care so much.

75

And btw I didn’t say the new SceneApplication is supposed to be used b SceneViewer, it IS a new SceneViewer, it would replace the old one and work exactly as you imagine it. But as said, you have to discuss with Momoko why it doesn’t render when theres two of them open.

76

You can look into TestAwtPanels, which allows you to create multiple panels for an application, or multiple applications each with their own panel.
Its done this way to circumvent a limitation in LWJGL where only one “Display” is allowed and is done via dummy Pbuffer contexts.

77
@Momoko_Fan said: You can look into TestAwtPanels, which allows you to create multiple panels for an application, or multiple applications each with their own panel. Its done this way to circumvent a limitation in LWJGL where only one "Display" is allowed and is done via dummy Pbuffer contexts.

Thats what the existing multi-application panel does. It doesn’t work with multiple applications as I told you. You said you wouldn’t change that.

78
@Momoko_Fan said: You can look into TestAwtPanels, which allows you to create multiple panels for an application, or multiple applications each with their own panel. Its done this way to circumvent a limitation in LWJGL where only one "Display" is allowed and is done via dummy Pbuffer contexts.

Yeah, thanks for the hint. I just found out by myself after looking through the existing LWJGL calls from JME.

My proposed solution would be a separate thread per instance of the embedded application, which would leverage the singleton behaviour of the Display and the OpenAL AL class by loading them from separate class loaders, thus decoupling all instances of these classes and the application.

I am still prototyping this, but I think that it might work.

Perhaps you might be interested in:

http://hub.jmonkeyengine.org/forum/topic/possible-memory-leak-in-awtpanelscontextcreatepanel/

79
@normen said: Thats what the existing multi-application panel does. It doesn't work with multiple applications as I told you. You said you wouldn't change that.

He is only using a single AwtPanelsContext and creates multiple panels from that context, each with their own view ports and so on.

80
@normen said: And btw I didn't say the new SceneApplication is supposed to be used b SceneViewer, it IS a new SceneViewer, it would replace the old one and work exactly as you imagine it. But as said, you have to discuss with Momoko why it doesn't render when theres two of them open.

That is what I meant with refactoring the old code, making a new scene viewer/model viewer, scene editor/model editor and so on, all based on a new embedded jme application.