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


#82

I just wanted to reply to the very first post, and the 2 points it brought up:

  • Allow Editor to be called from custom game script. Full or limited editor? How to make interaction?
  • Allow custom game script to be called from Editor. What limitations? How to implement interaction?

I would like to NOT change anything that the editor is currently doing. Mostly because with very little work, I have both options above working in my projects.

To the first point. I just made a small InGameEditor.AS file that is just a stripped down editor.as. So far it includes all the editor, but I am only using the hierarchy windows at the moment. But it’s all there. Ultimately I should be able to change materials and make changes in game with the AS code that already exists. And that is awesome.

To the second point, I pass in a flag that says load the editor.as from my main.cpp. Which has all my components registered. And as long as I have put in the time to make sure they are exposed to AS, they are integrated in the editor like any other urho component. So I can use the editor and my custom components to play around.

Both images are from the same executable.

There might be a point to “clean” up any code. But the flexibility of AS loading into a c++ project allows some really cool ways to integrate the editor. I would really hate to loose that. And I certainly don’t want to write my own editor if it were to get changed fundamentally.

Anyway, thanks to the devs. I find cool stuff with this engine all the time.


#83

Might this be a solution to the multiple viewport problem?


#84

Don’t worry, script Editor will never be changed, in both meanings.
You will not lose any nice feature that you use. You will not get any nice feature that you may want, except small tune.


#85

Yes, for anything that does not need every frame update, you should be able to get away with rendering to rendertarget texture, GetData() the pixels to CPU, then display those pixels via Qt image / bitmap inside a widget without actually having to have multiple GPU views.


#86

Sounds like to way to go for material and model thumbnails in the resource browser.


#87

Nice progress here @Eugene and great to see you back at the forums @JSandusky !


#88

@rasteron took some time to pull my head out of my ass, I’m not back per se, just back in a “I will support stuff I have done and I’m currently doing” sense. The closest to back I’ll get will probably be in IRC, my prior transgressions were too great to reinvolve myself too deeply. I appreciate the pass I’ve been given thus far for my roid rage in the past.


We’ve mostly finished our refactoring of editing related code, it should be good to go this week, had no idea how extensively our types had invaded the editor code.

@ghidra raises some interesting points. The biggest meaningful things actually lacking from the existing angelscript editor are:

  • Tasks (multiprocessing)
  • Timelines
    • Object animation
    • Attribute animation
  • Variable update rate
    • IIRC this has been done, but was a convoluted mess
  • Ease of extension
    • Try adding an “extend” mode to gizmos, pure pain
    • Editor is mostly functional code
    • Ease is extremely variable, supporting different render modes (wireframe, solid, etc) per split-view was easy
  • Difficult to work with physics
  • Edit capability looks like it should support animation recording
    • I can move and rotate the Ninja’s arms, but that’s meaningless

#89

Minor news for ones who is tracking this topic:
Since last update I’ve implemented some concept of ‘projects’, but I haven’t finished it.

QEditor is on hold now. I still need this Editor, so I am not going to drop it. However, it is not the only project that I am working on. Please treat such pauses in developement with understanding.

Then, question.
Any ideas how to make Qt Editor appropriate for UrhoSharp users?


#90

Is this the correct repo and is it up to date?


#91

Yes, it is.
Keep in mind that it is ‘zero-point-zero’ version that is not usable for any practival activity. Treat it as ‘Urho3D Scene Viewer’ for now.


#92

Finished the baseline refactoring for SprueKit’s Urho3D stuff and pushed it out.

Not ready for use at all (even basic capabilities were lost in refactoring [as basic as changing gizmo mode], due to overlap), so I wouldn’t bother forking for a while.

This is not light-weight code by any means, handling many types of documents under differing styles of view was mandatory (SprueKit has to deal with Model, Sculpt/Paint, Shape grammar, Auto-rigger, Texture Graph, and Animation documents in one unified UI where any of those documents may protrude into another).

https://github.com/JSandusky/UrhoEditor

Although an SCE ATF influence is visible in the WIP Dom folder of the “EditorLib,” those aren’t intended for use in scene style projects even when they’re complete (meant for fast data progs.). All emphasis is on specialized controls to deal with their unique circumstances and container widgets that can intelligently present the correct widget (DocumentViewStackedWidget) based on the current document and/or view in that document, in 10 years of desktop UI I’ve never seen a generic model/adapter/decorator actually work so I focused on minimizing the pain involved with specialized controls.

There’s approx. 40 hrs remaining to match the Urho3D editor feature for feature. I’ll come back to it once I’ve cleaned out some of those Github issues I posted and the ones that tie me.

In the near future, the procedural texture graph tool depicted in the readme will be OSS’d and I’ll probably port it over to Urho3D’s native types.

Exposing timelines and permutations are probably far down the road.


I’ll also push out the sold SCE ATF C# based editing and binding code I have. I don’t consider that to be good by any standard, and retrospectively wish I had invested more in matching ATF’s standards for that. It is however, useful for basic throw-away editors. I doubt that stuff still even compiles.


#93

Pushed old SCE ATF based code as well.

I definitely don’t recommend using this as is. But for intimate C++/CLI and C# backgrounders it’s viable. My refusal to actually ‘learn’ C# is quite apparent in this code.

Yes, you read that code correctly, it instantiates a unique Urho3D instance for every single document … woohoo!

Makes for plenty of editing baseline options.


#94

This looks great. It’s good to have multi view child windows.


#95

Nice! Looks great. Is there any support for ramps/splines?


#96

@sabotage3d, if you mean the SplineComponents - that’s just a matter of enumerating the control points as extra gizmos tagged as “control points.” That stuff is pretty solid, already used for FRep segments (limbs/spines), quad-strips, and quad-strip-style texture projectors which are pretty core for my stuff.

If you mean other curves, the stuff needed to do splines/color-gradient-ramps already exists (though not in that code - I use Catmull-Rom and MKCB response-curves in the texture graphs), just needs remapping to Urho3D types - the drawing/editing woes are long done.

The ATF stuff does none of that … I doubt that stuff even compiles. The Qt stuff should actually be usuable in a week or so, I noticed there were some serious nasties to fix document cleanup and hardpaths still in the VS projects.


#97

As I promised, I’m switching back to the Editor.

I was a bit unsatisfied with both my previous work and JS’s QT Editor because of their limited usage.
I wanted to make a tool that could be used for e.g. ingame Editor and isn’t tied to Qt.

So I tried some new approach and here is the example:


All UI stuff is hidden under interfaces, so I could run the Editor under both Urho UI backend and Qt. It may look like overwork, but I definetely like this approach.

Yeah, it’s pretty easy to add such Editor to any downstream project because it’s just a library that depends only on Urho (or Qt, if you wish)


#98

Thanks for your work.

Would you share this repo?


#99

Repo is on my GitHub (https://github.com/eugeneko/Urho3D-Editor)
However, I think you don’t need it since it’s just a unusable draft.

I tried both Qt and native Urho UI, then I tried ImGUI Editor by @rku and I considered that this UI library would be more handy for Urho Editor. So I’m going to move all logic into ImGUI-based editor and try pushing it. I hope that first usable version of that Editor will be ready in few months.