@mifth said: 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…
Noone is born with the whole knowledge…we’ll learn together and teach something eachother!!!Don’t you worry!!!
@orfeo18 said: Noone is born with the whole knowledge...we'll learn together and teach something eachother!!!Don't you worry!!!
I’m ready. 
I will be spending some more time in the SDK for the next month or so to come, and that means I will run into things that need improvement or fixing. I will make sure to update you on any changes I make; none will be too large, just little annoyances here and there.
I figure I should post some of the changes in this thread.
Today I made the TextureBrowser and MaterialBrowser, and several drop downs, sort their contents alphabetically. Selecting a material for a mesh now should be a lot easier. Also, the TextureBrowser and MaterialBrowser will remember what folder you explored last, so you don’t have to dig down to find the images again.
Any updates on this?
I’m also interested in hearing on updates on this. I had recently opened up editing the scenecomposer myself because I see a lot of potential in it. If this project by this person is dead, someone should get in contact with me and see if we can get something together. My idea of an ideal scenecomposer would be making it something similar to the UDK. Allowing creation of basic shapes on the spot and drag and dropping materials onto them.
@Buzzyboy said: I'm also interested in hearing on updates on this. I had recently opened up editing the scenecomposer myself because I see a lot of potential in it. If this project by this person is dead, someone should get in contact with me and see if we can get something together. My idea of an ideal scenecomposer would be making it something similar to the UDK. Allowing creation of basic shapes on the spot and drag and dropping materials onto them.
Please read through this thread. Making a copy of UDK is exactly not what we want.
I’m not saying it has to be a copy. You can’t deny that some of the features of the UDK are helpful. Especially the drag and drop for materials. My main issue with the scene composer is the movement (or I guess that’s more part of the actual Scene Explorer).
@Buzzyboy said: I'm not saying it has to be a copy. You can't deny that some of the features of the UDK are not helpful. Especially the drag and drop for materials. My main issue with the scene composer is the movement (or I guess that's more part of the actual Scene Explorer).
Yeah, sure. But again, read through the thread. Taking some feature and implementing functions to achieve that is kind of backwards. If you have to build infrastructure outside of the engine features (e.g. metadata or processing when loading the scenes) the functions will only translate to extending this kind of editing / game template. The idea of the SDK is that it gives access to the existing engine features to build editors on top of that.
The current requirements and changes to the SDK editor are outlined in detail in this thread and would allow any kind of extension to be added. “UDK style features” are the next step from that.
Any type of extension can already be added. This isn’t a matter of what ifs. I simply asked if this was still going on or was abandoned and what my hopes would be in further development. There is no need to be rude. I have taken the time to read the thread. I would appreciate if you could stop being passive aggressive.
@Buzzyboy said: I'm not saying it has to be a copy. You can't deny that some of the features of the UDK are helpful. Especially the drag and drop for materials. My main issue with the scene composer is the movement (or I guess that's more part of the actual Scene Explorer).
You need better manipulators?
You can check this project and adapt its manipulators for the SDK as a plugin.
@Buzzyboy said: Any type of extension can already be added. This isn't a matter of what ifs. I simply asked if this was still going on or was abandoned and what my hopes would be in further development. There is no need to be rude. I have taken the time to read the thread. I would appreciate if you could stop being passive aggressive.
Again, I think I pretty clearly state in this thread what I plan for the SDK. Making any “add object” or “move cursor” extensions before these changes are implemented can surely be done by using the base SceneRequest and making a completely new editor that has nothing to do with the current one. But that is not what this thread is about. So I don’t know why you would deem my statements “passive aggressive”, its simply not about “adding objects” or “moving mouse” yet.
@mifth said: You need better manipulators? You can check this project and adapt its manipulators for the SDK as a plugin.
Looks interesting. I will give that a look in a second!
@normen said: Again, I think I pretty clearly state in this thread what I plan for the SDK. Making any "add object" or "move cursor" extensions before these changes are implemented can surely be done by using the base SceneRequest and making a completely new editor that has nothing to do with the current one. But that is not what this thread is about. So I don't know why you would deem my statements "passive aggressive", its simply not about "adding objects" or "moving mouse" yet.
I never mentioned a “move cursor” I was more thinking being able to move with A, S, D and W much like the flycam. Regardless, if this is the way you feel you can treat me, I definitely do not plan to discuss further with you.
@Buzzyboy said: I never mentioned a "move cursor" I was more thinking being able to move with A, S, D and W much like the flycam. Regardless, if this is the way you feel you can treat me, I definitely do not plan to discuss further with you.
I am sorry if you feel offended but please explain where I “treat you wrong”? Maybe the one-liner about not copying UDK isn’t what you wanted to hear but this thread is about implementing the mentioned changes. Thats what needs to be done for the SDK now. If you want to help implementing that I’d be happy, if you want to make a plugin that completely replaces the current editor you can make a new thread with your questions and I will answer them.
I see, overall temper wears thin on these forums :roll:
Apart from that, I still do not get the new architecture as to the integration of scene composer and terrain editor and other tools.
This is what I have been able to gather so far:
Do we have any tools besides the forum and the issue tracker, for example a working wiki where we could all contribute to the documents including also mock-up drawings and so on?
Why not create a project on github now with an empty repository and move the sources later? That way, we can use the github wiki for documentation purposes. Or make it a JMESDKDEV repository with only the wiki and maybe also coding examples and prototypes, something which would not be required to be included with the original repository.
That way we could all contribute to that repository by simply cloning and issuing pull requests, allowing work in progress such as code and documentation on architecture and so on to be integrated as early as possible.
Right now, I find many hints on available code in this thread, but no links to a repository where one could review the code and give tips and hints and also participate in writing the code or even test it.
@axnsoftware said: Do we have any tools besides the forum and the issue tracker, for example a working wiki where we could all contribute to the documents including also mock-up drawings and so on?Why not create a project on github now with an empty repository and move the sources later? That way, we can use the github wiki for documentation purposes. Or make it a JMESDKDEV repository with only the wiki and maybe also coding examples and prototypes, something which would not be required to be included with the original repository.
And who is supposed to do and maintain of all that? Given the resonance for these kinds of threads so far I don’t think its necessary either, if anyone really wants to do something the forum and core chat are enough to get things going. I for one don’t need mockup drawings of anything or discuss ideas with people who don’t know the code, after all this isn’t in theoretical stages anymore. I just need time (or somebody else) to do the coding 
@normen said: And who is supposed to do and maintain of all that? Given the resonance for these kinds of threads so far I don't think its necessary either, if anyone really wants to do something the forum and core chat are enough to get things going. I for one don't need mockup drawings of anything or discuss ideas with people who don't know the code, after all this isn't in theoretical stages anymore.
Hm, github allows you to create for example an organization. Here, all contributors would be made members of say the JMESDKDEV team and by that also contributors to that repository.
The rest is team dynamics and whoever wants to contribute, does so by committing directly to the repository or to dedicated branches. Not to mention that non contributors would have the chance to create clones and thus extend upon the existing code and present that to you in form of pull request.
The github project itself and the repository would be near maintenance free once everything has been set up.
Of course, the pull requests can impose some additional work on whoever is responsible for the repository. But then again, this workload could eventually be distributed across multiple team members.
And we still would be using this forum to discuss things in detail or present working prototypes and discuss about them.
The problem is, I for my part am very fond of smaller to larger sketches, for example layouts of UIs and architectural drawings on how things interoperate.
I just need time (or somebody else) to do the coding ;)
Would this also require some kind of detail plan on how things in the new architecture interoperate and how the gui components should be layouted?
I don’t mean writing down everything up front, but a bit more information including also one or two sketches would help. And also it would be best if we
had this information in a condensed form. Right now it is all a bit messy with the information being distributed across many tools, for example the tracker
and the forum, some of hidden deep within pages long threads with random noise inbetween.
Not that I am not capable of finding it out, but a) the probability that one misses some detail information is quite high and b) it does eat up a lot of time that
one could be spending on actual coding. But this is just my opinion.
Don’t get me wrong. I do not want to impose on you that your existing processes should be changed. I merely want to point out that there is room for
improvement 
and the suggestions I made are open for discussion. And if you do not want to change the existing processes, then this is absolutely fine
with me.
But enough of that, back to my original question:
Apart from that, I still do not get the new architecture as to the integration of scene composer and terrain editor and other tools.This is what I have been able to gather so far:
- integrate all tools into a single top level uber component or tab, in which one could switch between these tools by clicking on a button in the toolbar or navigation bar
- plugins should be able to contribute new actions or sets of actions to either the scene composer or terrain editor or both and need to register these actions with individual node types or sets of node types
- e.g. an audio composer/editor would bind its actions to the audio node whereas a texture composer/editor would bind itself to a geometry and so on, and when the user selects an audio node, the tools for that node become available, replacing other tools in the toolbar
Is that correct so, or did I miss some greater detail? And what about the work being done so far. Was this already committed to the repository in a branch?
@axnsoftware said: Hm, github allows you to create for example an organization. Here, all contributors would be made members of say the JMESDKDEV team and by that also contributors to that repository. The rest is team dynamics and whoever wants to contribute, does so by committing directly to the repository or to dedicated branches. Not to mention that non contributors would have the chance to create clones and thus extend upon the existing code and present that to you in form of pull request.The github project itself and the repository would be near maintenance free once everything has been set up.
Of course, the pull requests can impose some additional work on whoever is responsible for the repository. But then again, this workload could eventually be distributed across multiple team members.
And we still would be using this forum to discuss things in detail or present working prototypes and discuss about them.
The problem is, I for my part am very fond of smaller to larger sketches, for example layouts of UIs and architectural drawings on how things interoperate.
Would this also require some kind of detail plan on how things in the new architecture interoperate and how the gui components should be layouted?
I don’t mean writing down everything up front, but a bit more information including also one or two sketches would help. And also it would be best if we
had this information in a condensed form. Right now it is all a bit messy with the information being distributed across many tools, for example the tracker
and the forum, some of hidden deep within pages long threads with random noise inbetween.
Not that I am not capable of finding it out, but a) the probability that one misses some detail information is quite high and b) it does eat up a lot of time that
one could be spending on actual coding. But this is just my opinion.Don’t get me wrong. I do not want to impose on you that your existing processes should be changed. I merely want to point out that there is room for
improvement
with me.But enough of that, back to my original question:
Is that correct so, or did I miss some greater detail? And what about the work being done so far. Was this already committed to the repository in a branch?
I wasn’t talking about how to do that, I was talking about doing it. It takes time to make a branch, to integrate it, to write the documentation. If I had that time I’d rather use it to do the actual coding. And I still don’t know what audience this would be for, as you found out yourself the thread asking for SDK contributions/adoptions resulted in almost no contributions apart from the font creator which somebody needed to work differently. Frankly I don’t have much use for a programmer that needs my assistance to understand the existing code (sans the inevitable few questions), this thread basically contains everything you should need to get going and ask actual implementation questions.
I don’t want to sound too negative but I don’t see how more work could result in the existing work being done faster
Back to the original question and to provide some more input in form of questions…
Apart from that, I still do not get the new architecture as to the integration of scene composer and terrain editor and other tools.
This is what I have been able to gather so far:
And now for the input:
So, would we have then a JME editor component, which is similar to a standard source code editor but which would then integrate the scene composer/terrain editor?
And would JMESDK start up and present the user with an empty JME editor, which, after the user clicked on either model or scene, texture or material and so on, would then load and present the appropriate detail editor for selected asset to the user?
Or, if the user double clicked an asset, would the new JME editor then be opened and the appropriate detail editor presented to the user?
And would there be multiple of such JME editor instances which then would allow one to open multiple scenes or models or other assets and work on them in parallel instead of having them reuse the same editor, effectfully limiting the user’s capability to multi task, as is now the case with the scene composer? And would the material editor/material definition editor be part of that new top level JME editor component?
I have created a mock up of the “new” user interface as I envision it, please have a look
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.
And I still don't know what audience this would be for, as you found out yourself the thread asking for SDK contributions/adoptions resulted in almost no contributions apart from the font creator which somebody needed to work differently. Frankly I don't have much use for a programmer that needs my assistance to understand the existing code (sans the inevitable few questions), this thread basically contains everything you should need to get going and ask actual implementation questions.
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:
Frankly I don't have much use for a programmer that needs my assistance to understand the existing code (sans the inevitable few questions), this thread basically contains everything you should need to get going and ask actual implementation questions.
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.