In worst case scenario, if every view needs it’s own Urho3D instance, that still seems ok to me. Urho is pretty light weight, and for most of the views, a reduced Urho build could be used.
How much is the delay? It’s not a matter of urho’s inactive fps?
I’m not sure those issues are big enough to change path.
Only one 3D view for single Urho3D instance. Some small preview windows like in Resource Browser or Material Editor will now require launcing sepearte Urho3D Application.
Why do you want to use Urho3D for a Resource Browser? Isn’t that just a view of files easier done in Qt anyway?
A Material Editor using Urho3D to display the result would be neat, indeed. But outside of displaying the result, I’m not sure such an editor wouldn’t be better done in Qt.
Either way, as others have pointed out, it is normal in editors to have multiple views/windows each running an instance of some kind of 3D display.
No real way around it, I think. And I agree that it wouldn’t be too much of a performance issue. After all, most of them will be inactive most of the time (aka not updating).
I spent some time recently about UI integration on game engines…
As a background, I come from cocos2dx, which has a UI system of its own, mostly reusing a single Sprite class itself and getting ui widgets out of it, very cocoa-like…
Something like QT is not really viable. At a monstre 15gb download on my mac, it’s as big as the Microsoft virtual machine for development, fully packed up with windows os. So really, no. It’s not just an editor; it’s an ecosystem. Of course, it has all the widgets you may want…
Here’s a list with some lighter ui tools i found which can be used more flexibly, and possibly be mobile friendly.
All these projects looks recent and mantained. The one i’ve tried:
Imgui - is light and works very well. It’s fast and is widely used on gaming projects. You can see it in action in bgfx https://github.com/floooh/fips-bgfx for istance together with nanovg https://github.com/memononen/nanovg (a fast svg direct command library for drawing) in example 20. Anyway, imgui is a immediate gui mode, that’s good for an editor, not-so-good in-game.
Cegui - Gorgeous, skinnable, rich graphics. Well known. Anyway, it’s heavy.
Turbobadger - wasn’t able to make it work correctly on my mac, so i don’t know. Probably not-retina.
Librocket - seems to be already integrated with urho. didn’t tried it yet.
MyGui, Gamegui, Guisan, same as librocket - not yet tried.
Does someone else have experience with these?
I could not disagree more.
The task of this is not to create a game UI (which Qt would be completely wrong for, indeed, but for other reasons).
The task is to create an editor, akin to Maya, Blender, Max, Unity…
This is a completely different thing.
And you can completely forget about doing any of that with any of the libs you listed if you do not want to spend weeks after weeks of implementing basic windowing, widget and misc functionality, which you’d all get for free.
And that doesn’t even cover that editor applications are expected to follow a certain OS-like style in their layouts (note how Eugene’s screens so far make it look somewhat similar to a dark Visual Studio).
Or they will simply end up looking amateurish (as the current Urho editor does). And will be very hard and unintuitive to use.
Good luck designing that with CEGUI
I tried working with most of the libs you mentioned. They are horrible for anything more than very basic layout needs. And most of them come with no kind of layout designer (or pretty bad ones).
IMO the only viable GUI library for games which will not cost your sanity is do-it-yourself with libcef3 (as that offers all that can be done in a browser) or the commercial alternative that already did the integration (forgot the name to be honest…).
At a monstre 15gb download on my mac, it’s as big as the Microsoft virtual machine for development, fully packed up with windows os.
I cannot believe that we still get this in 2017. 15gb is nothing. Get over it.
And besides, the actual distribution size of a Qt app is way, way smaller than that - an application I am developing that is using a lot of Qt functionality comes at a size of 200mb, of which Qt is not even 100mb.
Do you have any ideas how to merge these two images?
As far as I know, any GAPI widget like DX or GL view always overdraw entire rect area.[/quote]
I think what he meant (correct me if wrong) was to show windows containing Urho3D views on top of the Qt application.
Like… little windows that are hovering over the normal application.
Did I get that right?
If so, this can definitely be done with Qt.
Even the other way around can be done: Displaying Qt elements on top of a Urho3D scene (including transparency).
[quote=“TheSHEEEP, post:61, topic:2407”]Like… little windows that are hovering over the normal application.Did I get that right?
[/quote]
Nope
That might be a better way to do it then. Window-filling 3D-accellerated background with viewports that rescale along with their associated transparent QWidgets.