New Urho3D Editor [update from 2017-11-03]


#1

I am working on Qt-based Editor for Urho.

WIP

[details=Initial content of topic]I’ve seen here several threads about Urho Editor. I’ve even started one.
I think that Editor needs tighter integration with game code.
Sometimes I even feel a passion to improve something here, but I don’t want to start without way, milestones and goals.
@cadaver, do you have some strong opition about Editor developement or just good ideas?

Now I can imagine three ways of Urho usage:

  1. Custom app that uses Urho as library.
  2. Custom script that uses Urho player (probably extended with custom objects)
  3. Playable scene that contain all game logic inside scripts like Unity (probably extended with custom objects), with minimal entrypoint script/application
    Changes in Editor depends on that how many ways we want to cover.

I have bucket of different ideas and thoughts (mine and others’)

  • Migrate Editor to C++. Partially or completely? Will it give any benefits? It looks like hard job. (optionally covers 1,2)
  • Allow Editor to be called from custom game script. Full or limited editor? How to make interaction? (covers 2, optionally covers 1)
  • Allow custom game script to be called from Editor. What limitations? How to implement interaction? (covers 2)
  • Add standalone play of ‘playable scene’. It’s simple, but it don’t cover 2-nd way. It’s enough for me, but what about others?.. (covers 3)
  • Just do nothing and let Editor be temporary utility untill user write his own ingame editor with bj&hs. (covers nothing ?_(?)_/?)

I don’t promise that I’ll start work immediatelly or that it will be high-priority task for me.
However, let’s discuss at least.

My final goal is to have something like this:

Now it is hacky and buggy, with almost untouched Editor code. And I hate hack and bugs, do u 'now?[/details]


#2

My view is that the existing editor is somewhere halfway between a complex script API usage example, and a production-usable editor. Many have contributed to it and the code structure is not best. Because of Urho’s nature of “singleton” subsystems it will be hard to achieve calling into the editor from game, or vice versa.

Your analysis is quite spot on that Urho can be used in many ways and therefore it’s not obvious how the editor and game could talk to in all the scenarios.

Probably the ideal would be, if you wanted to improve the user experience at the same time, would be to use an actual native UI toolkit in the editor and rewrite it in C++. Otherwise you’re always going to be struggling with both the editor and game taking over Urho’s subsystems. How this would work best when appended to users’ projects is another largish question. Perhaps the editor could be another library, which adds functionality into Urho base (for example, it registers an Editor subsystem as it starts up)

A lot of smaller-scale engines actually launch a separate exe for the game from within the editor, though in that case you can forget the editor and the game talking.

I don’t have hard / fast opinions on how you should proceed. If you have passion, go for it. However to be realist, or slightly pessimist, you should be ready to do (most of) the work on your own. Many projects fizzle out because they’re expecting a collaboration to form, and that then doesn’t happen.


#3

What i have done, is using Qt for the UI, i have multiple dock widget/windows that i can move around. I create one context at startup for the editor, and one context for the “Game” window. When the user clicks on the “play” button, the active scene is saved/cached to a seperate file, which the game context then loads. This allows to “play” the game, within the editor.

I am moving my editor from VSTS to github within the next week, if anyone is interested to see how it works.

It requires Qt 5.6, and currently only runs on Windows and 32-Bit, but that is only because i have not created the project for 64-Bit yet.


#4

I know how tough it’ll be to port the editor to c++. If you can create a repo for it, perhaps, I can contribute.


#5

it could be a nice community project.
+1 for Qt, I have a good experience using it and urho :stuck_out_tongue:


#6

I have only one reason against Qt: It is not lightweight at all, it have much more that is needed for Urho Editor.


#7

While that is true… who cares?
Honestly, application/download size is a problem of the past, at least in non-mobile environments. And nobody is going to distribute the editor to mobile :wink:
Besides, while Qt has much more than any single application will ever use, it is nicely split into modules/shared libraries. When packaging a Qt app, only used parts will be packaged with it (automatically).

It does increase the complexity of building Urho3D, though, so I’d at least keep the editor optional.

The pros far outweigh the cons with Qt.
For example, I could imagine making changes to the editor for a project at hand to distribute the editor with the application.
The current editor… it is just not something you’d give into the hands of an end user. It’s just too rough, and not even nowhere similar to editors people are used to like Unity, Maya, etc.
So currently, if I wanted to distribute an editor with an application using Urho3D, I’d have to build it myself - which I’d most likely do using Qt, since - well, there is no alternative reaching its quality, not cross-platform, anyway.
Just having to adjust an existing editor for my needs would save much time.


#8

Ok, I am just almost unfamiliar with Qt.
If somebody is ready to start and/or share some code of Qt Urho Editor, I will contribute.
It is unlikely that I’ll start creating Editor in Qt on my own in the nearest future.
Probably, we will also need some assistance from our buildsystem guru…


#9

I believe to have commented this before, but it doesn’t hurt to reiterate.

If the editor is a separate project, using Qt fits very well. You’d only need solid setup instructions per platform, and the user could build or download Qt themselves and just ensure it’s available for the project’s CMake. Very likely you’d only ever use Qt + editor on desktops in that case.

As part of Urho repo or build itself, we have quite strong principles of automatic dependency build (and even including them in the source repo, since everything used so far is small). There Qt doesn’t fit that well, or would require much more ninja magic.


#10

Huh… I am in doubt.

Qt:

  • Really powerful
  • Heavy
  • Harder to use with executable project
  • Separate repo is worse than builtin
  • I am not familiar with it

Editor library:

  • Builtin, easy to use
  • Can be injected into existing executable project
  • Lack of functionality. Urho’s UI is powerful enough for games, but not for editor.
  • Looks like a kludge

Now I like Qt way more…
Can somebody of Qt guys share some code?


#11

You can check out aster’s 2D Particle Editor here: github.com/aster2013/ParticleEditor2D

uses Qt4 and I would assume you’re going to use Qt5, but still this is a good reference to start with.


#12

[quote=“cadaver”]I believe to have commented this before, but it doesn’t hurt to reiterate.

If the editor is a separate project, using Qt fits very well. You’d only need solid setup instructions per platform, and the user could build or download Qt themselves and just ensure it’s available for the project’s CMake. Very likely you’d only ever use Qt + editor on desktops in that case.

As part of Urho repo or build itself, we have quite strong principles of automatic dependency build (and even including them in the source repo, since everything used so far is small). There Qt doesn’t fit that well, or would require much more ninja magic.[/quote]
Fully agree, Qt does not really fit with the dependencies so far. And it shouldn’t, IMO. I don’t think the editor should necessarily be built when you build Urho3D.
What I would probably do (and I don’t say that I will, because I honestly do not have the time, this is just my developer experience speaking) is to create a separate repo just for the editor. The project structure I’d do as a Qt project (no CMake at all, since it is not required in this case and Qt is cross-platform already and free). Inside that project I would link against Urho3D, which would have to be put into a specific sub-directory of the project (so the user would have to put the binaries there himself, or it could be automated to a degree, even by Qt itself).
That would mean a complete and clean separation between Urho3D and its editor. So the editor would “just” be an application using Urho3D that happens to be using Qt.

Not sure what you mean with that.
Do you mean the ability to have an editor built-in with every project that uses Urho3D? I don’t think that would be a good idea. Such a built-in editor could never be as powerful as an “external” one. I think there is no example of a well-done built-in editor that comes with an engine, but there are countless examples of truly great external editors (just look at Starcraft 2 or Warcraft 3).

How so?
I would even say it is an important separation to make as they are simply different projects where only one depends on the other.
Urho3D could be developed mostly ignorant of its own editor, which IMO is a boon as it allows more focused development. And the editor could be developed “ignorant” of Urho3D’s development (other than adjusting to eventual breaking changes).


#13

Exactly that you said.

Huh. I mean, from the developer’s point of view separate repo is more clean way…
But it would be harder for newcomers to build Editor…


#14

One purpose I feel the editor solves very well, for me at least, is how to use Urho’s UI to do various things. It’s essentially an advanced example. One thing to keep in mind as well, is that someone will have to maintain the editor for a very long time if you switch to Qt. I believe using Urho’s UI makes this task (maintenance) a bit easier.

I do, however, think the editor in C++, rather than AngelScript, is a great idea. At the end of the day however, I see cadaver as being the person who would have to shoulder the burden of maintaining the editor, so it should be done in a way that would make that burden lighter for him.

My proposal, is to take more of a plugin approach; where most features/extensions of the editor is built as a linked lib or script (giving both possible choices on how to create a new feature). This way, a really cool feature by some random person can be versioned, and when it’s not supported anymore it won’t take down the entire editor. This may make the burden on cadaver (and not just cadaver but any main maintainers of Urho) lighter.


#15

IMO plugins is the most important thing that our Editor needs.

Unfortunatelly, it’s pretty hard to simplify current AS Editor AND reuse the same code in Qt Editor because editor is mostly UI and we can’t re-use code for UI.


#16

That’s true. And I like the UI as it enables a user to get started rather quickly.
It’s big downside is scope, though. It can’t (and IMO wasn’t designed to) and shouldn’t compete with top-notch UIs out there, like Scaleform/Noesis/CEGUI*/etc. (I’ll be using libcef personally).
For example, if you need a UI that scales perfectly with resolution, you’ll have to look at alternatives. Which is pretty much mandatory IMO for non-mobile games if you don’t want to subject users to weird scaling issues.

I’m not fully convinced of that. I mean, most of my experience in open source development comes from Ogre, but there different people were responsible for different aspects.
And since cadaver has developed such a great tool and is no doubt the driving force here so far, I would love him to be able to focus on the core of Urho3D. Which I do not consider the editor to be a part of.
For me, an editor would be a perfect project if another person wanted to contribute to Urho3D in a more long-time fashion :slight_smile:

Which is why I wouldn’t do any major changes to the editor, actually, before someone doesn’t say “Yup, I’ll do this!”.
I’d love to do it, I know Qt rather well and like working with it. And it would also be a perfect way of getting to know Urho3D better before starting with my project (which will begin in ~1.5 years).
But I just don’t have the time for such a commitment :frowning:

[size=85]*admittedly, calling CEGUI top-notch is a bit of a stretch.[/size]


#17

[quote=“TheSHEEEP”]
That’s true. And I like the UI as it enables a user to get started rather quickly.
It’s big downside is scope, though. It can’t (and IMO wasn’t designed to) and shouldn’t compete with top-notch UIs out there, like Scaleform/Noesis/CEGUI*/etc. (I’ll be using libcef personally).
For example, if you need a UI that scales perfectly with resolution, you’ll have to look at alternatives.[/quote]

I can agree with this, and you’re right.

One other concern, I think, would be licensing. Perhaps someone wants to deploy their game with a modified version of the editor. How would Qt effect this? Would they have to rewrite their own editor to remove all of the Qt elements. Would wxWidgets be any better? And does statically linking your library effect this process as well with Qt (or wxWidgets)?


#18

Qt comes in both GPL (which I’d never choose, and there is no reason to) and LGPL (which is the one you can use for open-source and closed source/commercial both).

I am not a lawyer, but the general consensus for LGPL is that as long as you link dynamically, don’t modify the source code, don’t rename the lib files, put the license somewhere* and (some say this is mandatory, most say it isn’t) make the source code of the LGPL-licensed software (so not your software) available somewhere, you are fine.
It really is not much to do and almost every software that does anything with audio/video manipulation does that for FFmpeg, for example.
Besides, this wouldn’t even affect the editor in Urho3D since that would be open source anyway.

wxWidgets has some very weird kind of custom license, which seems to be a more permissive variant of LGPL allowing you to modify its source code as well.
But I see no reason to use wxWidgets. It isn’t exactly lightweight, either and not as versatile as Qt. And it doesn’t have an editor that could rival Qt Creator even nearly.
I tried working with wxWidgets before, more than once. But it always ended with hitting some brick wall that doesn’t exist in Qt…

The only reason not to use Qt would be if someone wanted to have everything (including Qt) statically linked for the editor.
But why would anyone want that? To hide from other programmers that he did not write an entire interface library for every platform himself? :smiley:

[size=85]*You know, those “license” buttons in software that nobody really clicks on? Like that :wink:[/size]


#19

So far, Urho has done so well with choosing libraries that are great for other people/companies. I work on a lot of projects that are NDA-bound, and license is a real concern. Like you said yourself, they would never choose GPL… I’ve also had a friend ask me to recommend a game engine her team could use, (she works at IBM in the R&D dept… they do crazy things heh). I recommended Urho because of the license and the light-weight nature of it.

Now, I’m honestly not sure of the “correct” direction for the editor. Maybe this will just be a community thing and not part of the official Urho repo; but if the editor were to change (officially), I believe careful thought would need to be taken. Any direction would have long-term consequences to the future of Urho (I hope I’m not being too dramatic).

I just want to make sure all of the questions and concerns, especially the long-term consequences, have been considered.


#20

Well, the truth is that many people are afraid of LGPL for no real reason. All it requires you to do is acknowledge the tools/libs you are using.
You don’t have to share your own code at all.
You can still be secretive and earn money :wink:
I don’t think that is too much to ask, not from anyone, NDA or not.

And I especially don’t think open source software should try to specifically cater to closed-source needs.

But yes, as said before, I think the editor (if being rewritten in whatever way) should be its own, separate project.
But the current one should probably stay as a good example for the UI.