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


#61

[quote=“Eugene, post:59, topic:2407, full:true”]

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).


#62

I don’t think that is a Qt problem but an Urho issue because it doesn’t support multiple windows.

You can however try to play with SDL_GL_MakeCurrent


#63

[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.


#64

It may be hard to achieve on GAPI side.


#65

Huh.
Movement looks luggy when I accumulate position attribute change this way:

// Somewhere in Mouse Move event
const QPoint delta = event->globalPos() - prevPosition_;
QCursor::setPos(prevPosition_);

And it looks much better if I write

const QPoint delta = event->globalPos() - prevPosition_;
prevPosition_ = event->globalPos();

It seems that such a crap is caused by setPos.
It seems that this call loses some sub-pixel stuff that end up in unsmooth deltas.


#66

For my widget and to control camera on viewport I don’t use mouseMoveEvent.

Somewher in constructor : setMouseTracking(true);

and :

void eRenderView::mousePressEvent(QMouseEvent *me)
{
    QWidget::mousePressEvent(me);

    m_lastMousePos = me->pos();
    m_mouseDownPos = me->pos();

    if (me->buttons() & Qt::RightButton)
        setContextMenuPolicy(Qt::PreventContextMenu);


    SDL_Event sdlEvent;
    sdlEvent.type = SDL_MOUSEBUTTONDOWN;
    sdlEvent.button.state = SDL_PRESSED;
    if(me->buttons() & Qt::LeftButton)
        sdlEvent.button.button = SDL_BUTTON_LMASK;
    if(me->buttons() & Qt::RightButton)
        sdlEvent.button.button = SDL_BUTTON_RMASK;
    if(me->buttons() & Qt::MiddleButton)
        sdlEvent.button.button = SDL_BUTTON_LMASK;
    QPoint position = me->pos();
    sdlEvent.button.x = position.x();
    sdlEvent.button.y = position.y();
    SDL_PushEvent(&sdlEvent);


    const eBool leftBtn = (me->buttons() & Qt::LeftButton);
    if(leftBtn)
    {
        QPoint glob = mapToGlobal(QPoint(width()/2,height()/2));
        QCursor::setPos(glob);
        SDL_SetRelativeMouseMode(SDL_TRUE);
    }
}

void eRenderView::mouseReleaseEvent(QMouseEvent *me)
{
    QWidget::mouseReleaseEvent(me);

    if (me->button() == Qt::RightButton)
    {
        QContextMenuEvent ce(QContextMenuEvent::Mouse, me->pos());
        setContextMenuPolicy(Qt::DefaultContextMenu);
        contextMenuEvent(&ce);
    }

    SDL_Event sdlEvent;
    sdlEvent.type = SDL_MOUSEBUTTONUP;
    sdlEvent.button.state = SDL_RELEASED;
    if(me->buttons() & Qt::LeftButton)
        sdlEvent.button.button = SDL_BUTTON_LMASK;
    if(me->buttons() & Qt::RightButton)
        sdlEvent.button.button = SDL_BUTTON_RMASK;
    if(me->buttons() & Qt::MiddleButton)
        sdlEvent.button.button = SDL_BUTTON_LMASK;
    QPoint position = me->pos();
    sdlEvent.button.x = position.x();
    sdlEvent.button.y = position.y();
    SDL_PushEvent(&sdlEvent);


    if(SDL_GetRelativeMouseMode())
    {
        SDL_SetRelativeMouseMode(SDL_FALSE);
        QPoint glob = mapToGlobal(QPoint(width()/2,height()/2));
        QCursor::setPos(glob);
    }
}

#67

For previews that can’t go fullscreen, it probably makes sense to atlas the viewports in one instance of urho, if Qt can render from that. But I think it’s too limiting to avoid running another instance of urho, because what if you want to pull out the viewport dock and put in on another monitor, or something ? (Although maybe a moot point atm, if the editor isn’t being designed like that).

I’m no big fan of big downloads, but if you only download the minimum you needs, it’s closer to 5gb. I did so myself to test the editor, although I ran into newbie issues so didn’t get far.


#68

5 GB ?
there should be an problem… Too huge.
Did you compile release version ?


#69

Nah, I just downloaded the compiled version. To be fair the UI said it was 5gb, although that was disk space not the download size.


#70

In my case there is a widget that is absolutely unrelated to Urho frame or SDL.
Anyway, the problem is probably in setPos
I need a way to ‘wrap’ mouse using Qt. I am surprised that QT don’t have such simple ability.


#71

Ah, I see I mistook it completely! It’s the opposite then - if the goal is to build a first class 3d editor/3d object manager, probably QT is the only viable C++ option. Unless, of course, you want to enjoy Microsoft-something development :unamused:
Or maybe something like Electron & friends, very handy but I don’t know if node has such low-level graphical abilities… moreover is Js so forget uint8_t…
Anyway I would still value Imgui, many gaming editors seems to have been built with it… but I can’t testify on the final outcome, they seems to be all still in beta…
QT is surely battle-tested for the task. Many companies used it this kind of high end job…


#72

I saw this video today. The guy is obviously using some way to display the material preview in his node based material editor. You can ask him how he does it.


#73

Well, you can do any kind of image or DirectX or OpenGL display inside a Qt widget. That is not a problem.
What we need is a preview done by Urho3D, though (to make sure it looks like the final product).

I don’t think the question is if it can be done (it can, without a doubt), but how to do it best.


#74

maybe the simplest way is to use multiple viewports inside main view like sample 09.


#76

Not all docks and windows.
Just the display of final material result.

It could be done in the main Urho3D window inside Qt.
For example, you edit the material values in Qt -> main Urho3D display in editor updates, showing the material.

I think that would be the only way if we do not want multiple instances of Urho3D running. Since Urho3D cannot render into multiple windows at the same time with different scenes, correct?

But then again, I don’t think multiple instances of Urho3D running would be a big problem, or would it?


#77

Huh, I misunderstood you first time. Yep, this is the simplest, but not very nice.

Probably it would be ok for secondary views to be software-copied Urho’s RenderTargets.
It is not very performant, but who cares?

It’s just dirty, IMO. If I open 50MB skybox in Resource Browser preview, in material editor and in two scenes on two screens, it will end up with 200 MB consumed video memory.


#78

[quote=“Eugene, post:77, topic:2407, full:true”][quote=“TheSHEEEP, post:76, topic:2407”]
But then again, I don’t think multiple instances of Urho3D running would be a big problem, or would it?
[/quote]
It’s just dirty, IMO. If I open 50MB skybox in Resource Browser preview, in material editor and in two scenes on two screens, it will end up with 200 MB consumed video memory.[/quote]
200MB is pretty little, really. Just opening a Chrome with a couple tabs costs 1GB :wink:
Of course, there shouldn’t be too many of these windows open, but I don’t think we need that many. For example, I don’t think we need to allow showing an arbitrary amount of scenes at the same time.

[quote=“Eugene, post:77, topic:2407, full:true”]Probably it would be ok for secondary views to be software-copied Urho’s RenderTargets.
It is not very performant, but who cares?[/quote]
That would definitely also work. Especially for “lower-priority” targets like viewing a material that don’t need to be updated all the time.

This is a solvable problem. Either solution either costs memory or performance, but both at an acceptable level I think. I’d say just do what seems easiest to you :smiley:


#79

Couple of things, a code dump (with support) is in the works where I’m dumping a heap of commercial material at Eugene for optional use in his work. Entirely optional.

  • Storage: 15gb is indeed too much, I know this as a motorcyclist having been smashed to bits by a car annually. 64gb storage is the maximum hardware I carry with me to do actual work with. Your material is always in jeopardy. Sure you’re not looking at debug symbols?

Desktop software development has become so rare that I find it hard to believe how much hostility I’ve just read. Would everyone prefer a crippled web-based editor that can do diddly or a proper desktop editor that can actually use their hardware appropriately?

The multi-viewport issue is a lot easier to just resolve by switching purely to OGL than DX, in DX multiple viewports are pure pain. In OGL it’s not that bad … something OpenGL is actually good at … shocker.

Reality is, those storage concerns are moot, most likely it’s just an inexperienced dev working out the release cycle.

What are you doing that is impressive enough that it gives you right to comment like a god?

I absolutely commend the writer for taking the foray into that which is almost lost as writing real desktop software in an age where everything is javascript this and javascript that as become all too rare.

We should commend those efforts. We should appreciate those that try to be better than mere web developers.

I entrust code to people that I believe can use it. Persons that are top tier, I genuinely believe Eugene is on a roll and will find himself as the cheese sooner than he’d like.


#80

But I think in this case, our problem is that the windows containing some graphics must be filled by Urho3D, and Urho3D itself does not feature rendering to multiple windows at the same time. No matter if done with OpenGL or DirectX.

I actually like Eugenes suggestion of just copying the data in the viewport over to some Qt image display (QLabel would work, but a QOpenGLWidget would also work). After all, we’re talking about things that simply do not need to be done all too often.


#81

Right, that works globally, and most of the cases where one wants multiple viewports a lazy update of less important windows is okay (asset inspector). I was only suggesting the switch in an editor context, not a “switch all things to pure OGL” stance since that’s ambiguous in hindsight.

It’s possible in DX, just a lot more work with the swap-chain’s quirks. Split views in the existing Urho3D editor work, as far as can see it’s just the presentation/system that is missing for handling multiple viewports.


There was a lot of SprueEngine/SprueKit bleed-over into the editor code I sent to Eugene, so right now I’m stripping that bleed-over out to get a cleaner version to send off, I’ll post that to Github as that’ll be easier for commentary and persons can toy around with it at their leisure. It’s all “at one’s discretion code” anyways, what works for the SprueKit programs might not work well for an Urho3d editor.