Why I don't like to extend or use the SDK Scene Composer

[monkeychops]

@normen Most other engines that I have used, including Unity, UE4, Torque3d, Esenthel, NeoAxis to name a few ALL keep the scene editor separate from the code editor. The tooling is focused on the design side of things, whereby the scene editor allows you to place objects in the scene, place and edit terrains, add physics objects etc. etc. Most of the time the IDE is launched seperately to edit the code, with the better ones integrating the two in that they allow scripted behaviours to be written in the code IDE and then attached to nodes in the scene.

I really love the way the jMonkey approach is developer first, rather than designer first, in that nothing is hidden away in magic drag-and-drop components and there is lots of information about how to really get under the hood with JME3.

I have to say though, that both myself and my friend who have been working with JME for a few years now have found the current tooling in the editor to be very cumbersome and unintuitive and I’ve really struggled to get any models imported and laid out in a scene. The terrain editor only supports a single, tiny terrain tile - making it bigger results in memory problems and crashes. There’s no trees or foliage integrated, no support for live editing/debugging the scene (as far as I can see), no mechanism for making prefabs, editing AI etc. etc.
Of course, all this stuff can be added with plugins and custom controls, appstates and such, but in practice I think most people find it easier to just roll their own than try to figure out how to integrate everything into the IDE themselves. Thats what we ended up doing.
In fact, I had to fight very hard to convince my friend to go with JME as our engine choice because one of our criteria was that the engine should have a scene editor and even though I said it does, he said “No, I’m not even going to count that as an editor”.

My point here I guess is - the editor tools definitely need some more thought. I know loads of work has gone in already, and I’ve read your other posts where you’ve explained the logic behind this and the design philosophy and it makes total sense to me to let the IDE do the heavy lifting for updating, building for multiple platforms etc. but I think what daenim has done / is doing in terms of scene editing and an easy to use component hierarchy, visual feedback, grouping etc. is definitely a step in the right direction. It’s so much more intuitive and easy to use, and it just makes sense to people who are used to other game engines right out of the box. If this can be integrated into netbeans with a similar kind of layout and feature set then that would definitely be a better way forward.

@Daenim do you think what you’ve done could be ported to work within netbeans? I’d be happy to help a bit with this although so far I’ve not even managed to get the editor bit of the SDK to compile… I’m getting gradle errors

[daenim]

@monkeychops my last (and failed ) attempt to create a netbeans plugin was a couple of years ago. Maybe a first good step would be to create a plugin for a fuzzy logic control + editor that is in my ML library. I already have an asset loader for a fuzzy control file and a jpanel for the fuzzy logic editor so in theory it should be possible.

[normen]

No there hasn’t been a lot of work going into the Scene Composer at all. I explicitly called it “Simple Scene Composer” and hoped someone would build a more extensive editor (based on the SDK tools). I even kept tools like rotate and move tools out of the editor to underline that its NOT a fully featured editor. It basically only works based on the underlying things like the Scene Explorer, Properties etc., which can be used for any SDK editor.

Then others wanted the move and rotate tools so badly that they implemented them and exactly what I predicted happened: People think this is supposed to be the editor and bash it (like you do).

As you say (and I often said) people rather roll their own. And that is true for this editor as well. You won’t get many people help you or extend it because they rather roll their own than getting into your way of doing things, just like you didn’t want to get into how to implement a SDK editor (even though everything you implemented was there already). I say this not in a maliciously intended way, just based on experience because theres been LOTS of editors like this. All started and ended as one or two-man projects, including the officially offered framework for making editors which is the SDK.

Finally, the SDK can be used as a standalone editor, a standalone code editor / project manager or both at the same time. Nothing is tied to one another there.

Edit: Plus theres a thing that most people don’t seem to get which is that theres not only one way to do a game. Your editor will be useless for 80% of games if you define what a “player” is, what a “level” is etc. Or rather it will only allow you to do one type of game then. That could be plugins for the SDK to do one type of game, using the existing tools (again, Scene Explorer, thread safe Property editors etc.). So when you complain theres no way to edit AI functions then the question would have to be “what type of AI?” “will your idea for the AI be useful for every type of game?”. The SDK allows adding navmeshes which are useful for many types of games and there could be more plugins that allow doing similar things, even add “test NPCs” or stuff like that (although as said you just need to run an AppState on the scene to test that). But again, people roll their own and theres never any synergy.

[nehon]

To add on this, we always have ambivalent feelings toward this kind of work.
On one hand it’s obviously amazing, and just deserves awe. Great work btw @daenim.
On the other hand it feels like a waste somehow. Because if as much work had been put into the SDK it would have been a huge step forward. That’s very frustrating for us.

I know netbeans API is daunting. I know it’s hard to get into someone else’s code. But that’s something you must learn to do when fiddling with oss anyway.

[daenim]

@nehon @normen well I will do my best to integrate it into Netbeans. Like I mentioned, I will start with my animation framework because I already have asset loaders for it and it should be relatively straightforward and it blends well with the Control approach. Maybe with that experience I will be able to integrate the sandbox as well. But my biggest concern is then that there would be objections to some of the methodology that I use. For example, I do think that using the concept of a scenes, players, waypoints, … offers a usability advantage. I think it is excellent that the core engine is kept as abstract and pure as possible, but the layer around it should offer more. In my opinion this will also make it easier for novice users to get started with jmonkey.

[mathiasj]

The thing is that when I were to write an editor today, I would personally try to finish it as fast as possible to continue writing on games. I wouldn’t really like trying to integrate it into the SDK, because I already know several GUI frameworks and don’t want to learn a new one for a ‘quick’ side project. When writing games you already need so many different applications (e.g. Photoshop, Blender, MakeHuman, Mocap Software, SDK) so it does not really matter (to me) if I need to start another application to use the editor. I think the little bit of more convenience you get when integrating some editor into the SDK is, at least for me because I merely see editors as ‘side projects’, not worth the effort of learning the Netbeans API and integrating my code with it. Not that I don’t like Netbeans plugins but I would simply go the quick and dirty way.

[nehon]

I absolutely understand the feeling. It always seems faster to go the “safe” route we already walked numerous times.

But that’s basically saying : “I’m doing an editor for my personal needs and I’ll eventually share it with the community”.
That’s already very nice, for sure. But still, it really only fits your need, maybe lack some thought about genericity (because you don’t really need it to be generic for your special need).

Also the “unofficial” nature of your editor, may refrain people from using it. No offense, but we’ve seen so many initiative like this which lifespan was from days to few month max, that it just make people reluctant to walk the step.
Of course you may say : “I don’t care if people don’t use it, I do”, but that kind of thought just deprives you from the nice side effect of OSS : Contribution. Which is too bad.

Contributing the SDK, is not only profitable to the community, it also offers some durability to your devs, because, we (the core team) are backing it up from the moment it’s integrated to the SDK.
In the end the pain of getting into netbeans is a small investment compared to what it can offer. And trust me, I did my share of name calling when trying to wrap my head around netbeans API, but in the end, it’s really worth the effort.

@daenim I’d be thrilled to see all your work integrated with the SDK, so feel free to poke me on the forum or by PM if you need advice/help.

[erlend_sh]

@daenim

But my biggest concern is then that there would be objections to some of the methodology that I use. For example, I do think that using the concept of a scenes, players, waypoints, … offers a usability advantage.

Only way to find out is to ask Poke and prod as much as you’d like. If our users didn’t test our assumptions we’d stop moving forward in a heartbeat.

For every disagreement there might be an agreement that gets us closer to a solution that benefits everyone.

[monkeychops]

I understand the argument that making an editor too game/genre-centric can be a major problem - that’s kind of what Torque3d did, in that their engine and tooling is very much FPS focused, so it goes against the grain a bit to make other styles of game.

On the other hand, once we start talking about creating and editing terrains, placing models in a scene, using character controllers and the like, or even simply saving things into a .j3o scene file, we’re already starting to make some assumptions. I don’t think that’s a bad thing though - I mean, upwards of 90% of the time we’re going to have a character walking around a map or a vehicle of some sort driving or flying around and we need some sort of tools to build that world. Keeping everything completely obscure and generic seems pointless to me, because unless tools are suited for the purpose at hand, it will always be easier/necessary to make a more suitable tool anyway.

Unity for example has everything that’s needed to make a nice terrain, place trees and buildings, place characters and physics controllers in the scene and edit the properties of all the objects. Of course, some people might want to implement their own tree system or replace the terrain with a voxel terrain, but those people know what they’re planning and what they’re undertaking. Those that just want to get up and running with a quick scene and get a character running and jumping around for a FPS, TPS, platformer, tank game, RTS or whatever else can do so in much less time than they currently could in JME3. I don’t think making assumptions about what a character is, how the AI works etc will necessarily lead us to a case of “one type of game”. There’s often a lot of overlap and in the best case it can actually mean that we all benefit from much more advanced, solid and flexible game components in the long run.

Some games might need something very different from the average, but then those games will probably not benefit much from any generic scene editor anyway, no matter how game-agnostic it tries to be.

[nehon]

@monkeychops

to make a nice terrain, place trees and buildings, place characters and physics controllers in the scene and edit the properties of all the objects.

To be clear, we’re not against that. On the contrary we’d love something like that. But it has to stay model agnostic. No entity system or any OO model. It has to stay, Spatial, Nodes, Geometries, Controls and AppStates.
Then users will plug their data model into it.

[david_bernard_31]

As I tried to contribute to both projects DartE and the SDK, and then start my own "editor blender based, I would like add my 2c.

DartE :

• I give it a try in Jul/Aug (very early), I try to understand how to use it and to integrate it in my workflow
• I add some issue to build it, because it’s a NB project with dependencies to other NB project (also available on github) so I have to deal with dependencies manual
• I open some issue, @daenim was reactive so I post-pone experimentation for later (when more mature)

SDK (I’ll only talk about contribution in SDK (not about plugins)):

• I had experience with NB, as I wrote few years ago a similar 3D editor based on NB for a company, so I didn’t start from scratch
• I have branches of feature, bug fix to be able to do PR and correct them with after reviews, to experiment fix, …
• SDK contributions are only for 3.1, I was fine with that because I work on 3.1. But when I start to share my other jme stuff, I had to downgrade 3.0 to allow other use it and to follow Normen advice to avoid 3.1 (very unstable) if I want more stability. So I can no longer use my patched SDK. It was very frustating to wait SDK release (no ETA) to have other user feedback, or to say “it’s in the SDK but nor for you !” to 3.0 user. I remember having the same issue about Scala and the Scala-IDE when released of tools was link to main language, impossible to have simple fix/feature unrelated to core. => with SDK improvements aren’t shared ASAP

So at the end, I +/- stop contributions to both. I start using blender as main 3D editor, including for level design, because I don’t want to re-invent all (mainly the UI, and 3D navigation) to be sure to have a 3D editor not too linked to engine.

I’m stopping here, to avoid to be too long

[normen]

Simple solution would be to develop against the 3.0 stable branch?

[david_bernard_31]

Did you plan to release 3.0.11 with only update in SDK ?
You told me to make PR for 3.1 not for 3.0.

[normen]

You didn’t tell me thats a problem for you… And its the same code anyway. If there was great contributions (and I don’t count an “add box” dialog in that category) then sure there could be a 3.0.11 update.

[zzuegg]

Since i have read this discussion here i tough i give the sdk editor a second chance.

I just simply created an empty terrain, rotated, translated it a few times to check out the cursor. Added some lights and a 5 Boxes.

1. When terrain not axis aligned the whole cursor snapping does not work anymore (Cursor is placed in the air or does not move at all)
2. Spotlights and Pointlights are not movable/scalable/rotatable

I really don’t want to start a ‘for me’ closed topic again. Its just that i can understand people write there own editors for even the simplest tasks. And writing a netbeans plugin is most likely overkill for someone who just want to have a “add box” dialog.

My two cents. Consider me out of this topic.

[david_bernard_31]

It’s because there is no “add box, area,…” in SDK that we need level editor. And as you said use blender to add box, so now I use Blender to add box, area,…

[normen]

A simple asset pack with a box etc. would do.

[normen]

1. Thanks for the bug report, seems like for terrain theres issues with ray casting then
2. Sure you can move it etc., via its properties

And again and again, nobody said that the SDK has a great editor thats made for editing levels of all kinds, I said that just a few posts ago.

Furthermore making an extension or plugin is certainly not more overkill than making a whole app where you first reimplement existing features for half a year…

[zzuegg]

I perfectly understand that its not a editor to make whole levels. Its just that maybe the name is kind of misleading, since it kind of suggests it is a “Scene Editor”

To say it in another way. I really think that editor does not reflect what the engine itself is capable of. For new users which just want to give “Game Dev” a first look, launching the scene editor is probably the very first action the do in the sdk

[normen]

Its called “Scene Composer”, so you compose scenes from existing parts. And as I also already said, it was even called SIMPLE scene composer to highlight that its a SIMPLE example of how to make a scene editor type plugin.