Yet Another Editor

Less than two weeks ago i started working on yet another Urho3D editor. It is not usable just yet, but it probably is in good-enough shape to be showed off, so here it is.

Features:

• Uses imgui for UI
• Scene hierarchy widget
• Attribute inspector widget supporting 99% of Urho3D variant types
• Material resource editor
• Mask widget (for light masks etc)
• Resource path browser widget
• Drag&drop for (some) resources
• Scene settings (renderpath, postprocess)
• Open multiple scene tabs
• Save/Open existing scenes
• Save/Open projects (project includes widget layout, opened scenes, various settings)
• HDPI support

Missing but planned features:

• Create/delete objects
• Undo/redo
• Objects for representing invisible scene nodes (like lights and cameras)
• Icons for components
• Save scene as a new resource
• Create new materials from scratch and save them
• Resource browser with previews
• Drag&Drop with previews
• UI layout editing in a new dedicated tab
• Many more i cant think of right now

Code at: https://github.com/rokups/Urho3D
If you wish to test it - be sure to use -DURHO3D_TOOLS=ON cmake parameter.

That looks quite nice.Will try it out. Thank you for sharing it.
What is the priority of the UI layout editor? I think it will be nice to have that as well.

That really is low in my TODO list. UIEditor itself is somewhat done, but it is in separate application and needs to be “just wired in”. It’s code too could definitely use some love too.

I am just wondering how to design the UI editor that can let people design the UI once, then run seamlessly on any phones with different screen sizes and resolutions. Or how to do screen adaptation generally in Urho3D.

I solved this problem like so:

GetSubsystem<UI>()->SetScale((float)GetGraphics()->GetWidth() / 1920.f);

UI was designed for 1080p resolution. It scales up or down on phones fine. Not sure how it would do on 4k screen on desktop though.

Suppose you design for a screen size of 1000x1000(just an example), then it now needs to run on a screen with size of 1200x1000. The upper right button which is designed at the position of (1000,1000) can only be at position(1000,1000) and cannot reach the real upper right corner. A better solution may be to add a anchor choice to the UI editor, so that we can set this property to “upper right”, then the button will stay at the actual desirable position at the running device.

UI already has these settings. They are called “Horiz Alignment” and “Vert Alignment”.

Will these settings be configurable in your up coming UI editor?

UIEditor (and Editor) present any registered attributes (URHO3D_ATTRIBUTE and similar macros) so yeah - these options are already available in standalone UIEditor and will be available once it gets merged to editor. In fact i am pretty sure official editor exposes them as well.

Got it. I didn’t use the official UI editor because there is no tutorial for a beginner. I will wait for your new UI editor, and hopefully you will have at least a simple beginner tutorial for some basic operations.

Looks interesting. I also wanted to try ImGUI for Editor but didn’t actually tried it yet.
Have you faced any problems with ImGUI? Are built-in widgets bug-free?
What’s performance of Hierarchy? Is it possible to implement drag&drop of hierarchy items in ImGUI?
Does ImGUI support OS files drag&drop?
I’ll try the Editor this evening. Probably I should move this way.

Have you faced any problems with ImGUI? Are built-in widgets bug-free?

Overall i am extremely happy with imgui. I havent noticed any bugs i would need to work around. One notable thing is that built in widgets for integers and doubles cast them to floats internally, so that may be source of issues at some point.

What’s performance of Hierarchy?

I have not noticed any performance issues so far. I even do some string formatting on every frame.

Is it possible to implement drag&drop of hierarchy items in ImGUI?

Sure, and it actually is very simple. My drag&drop support is probably less than 40 lines long. It goes something like this:

1. Set “drag data” to some global spot, like subsystem driving UI
2. Subsystem renders frameless imgui window at mouse position if there is drag data set and left mouse button is down
3. Widget accepting drop checks if there is drag data set and mouse was released on this frame, if so - gets drag data from the subsystem and uses it, subsystem no longer stores drag data.

For hierarchy it would work the same.

Does ImGUI support OS files drag&drop?

ImGui itself does not handle drag&drop at all, but we can possibly make it work. Urho3D supports dropping OS files on to window, with coordinates where it is dropped. That is enough to make imgui widgets accept that drop.

Probably I should move this way.

I want to collaborate. Thing is biggest turndown for contributing to Urho3D is the fact that bundings have to be maintained manually. That is neither fun, nor straightforward at times… In case of editor that could be less of a problem though.

Could I PM you somewhere?
Skype/Gitter/WhatsUp/Slack etc…

im on gitter, in Urho3D room as well. Username is @rokups

The Editor is now compatible with main Urho repo.
Could be checked out from https://github.com/rokups/Urho3D-Toolbox

How am I supposed to integrate it with the master? Drag and drop somewhere then cmake and rebuild everything?

You are supposed to build master branch of Urho3D and use it as SDK to build Urho3D-Toolbox. At the moment it is little more than a demo. Do not expect useful tool just yet.

That’s OK

cmake .. -DURHO3D_HOME=/home/slapin/Urho3D/build
-- The C compiler identification is GNU 6.3.0
-- The CXX compiler identification is GNU 6.3.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found Urho3D: /home/slapin/Urho3D/build/lib/libUrho3D.a (found version "1.7-66-g1fe5fdac2")
failed to create symbolic link '/home/slapin/Urho3D-Toolbox/build/bin/Autoload': No such file or directory
failed to create symbolic link '/home/slapin/Urho3D-Toolbox/build/bin/Data': No such file or directory
failed to create symbolic link '/home/slapin/Urho3D-Toolbox/build/bin/CoreData': No such file or directory
failed to create symbolic link '/home/slapin/Urho3D-Toolbox/build/bin/EditorData': No such file or directory
-- Configuring done
-- Generating done
-- Build files have been written to: /home/slapin/Urho3D-Toolbox/build
slapin@slapin-pc:~/Urho3D-Toolbox/build$ ls
AssetViewer  bin  CMakeCache.txt  CMakeFiles  cmake_install.cmake  Editor  Makefile  ThirdParty  Toolbox  UIEditor
slapin@slapin-pc:~/Urho3D-Toolbox/build$ ls bin
EditorData
slapin@slapin-pc:~/Urho3D-Toolbox/build$ make
Scanning dependencies of target IconFontCppHeaders
[  2%] Building CXX object ThirdParty/IconFontCppHeaders/CMakeFiles/IconFontCppHeaders.dir/INTERFACE.cpp.o
[  5%] Linking CXX static library libIconFontCppHeaders.a
[  5%] Built target IconFontCppHeaders
Scanning dependencies of target imgui
[  8%] Building CXX object ThirdParty/imgui/CMakeFiles/imgui.dir/imgui.cpp.o
/home/slapin/Urho3D-Toolbox/ThirdParty/imgui/imgui.cpp:576:0: warning: "IMGUI_DEFINE_MATH_OPERATORS" redefined
 #define IMGUI_DEFINE_MATH_OPERATORS
 
<command-line>:0:0: note: this is the location of the previous definition
[ 11%] Building CXX object ThirdParty/imgui/CMakeFiles/imgui.dir/imgui_draw.cpp.o
/home/slapin/Urho3D-Toolbox/ThirdParty/imgui/imgui_draw.cpp:16:0: warning: "IMGUI_DEFINE_MATH_OPERATORS" redefined
 #define IMGUI_DEFINE_MATH_OPERATORS
 
<command-line>:0:0: note: this is the location of the previous definition
[ 14%] Building CXX object ThirdParty/imgui/CMakeFiles/imgui.dir/imgui_freetype.cpp.o
[ 17%] Linking CXX static library libimgui.a
[ 17%] Built target imgui
Scanning dependencies of target ImGuizmo
[ 20%] Building CXX object ThirdParty/ImGuizmo/CMakeFiles/ImGuizmo.dir/ImGuizmo.cpp.o
[ 23%] Linking CXX static library libImGuizmo.a
[ 23%] Built target ImGuizmo
Scanning dependencies of target tinyfiledialogs
[ 26%] Building C object ThirdParty/tinyfiledialogs/CMakeFiles/tinyfiledialogs.dir/tinyfiledialogs.c.o
[ 29%] Linking C static library libtinyfiledialogs.a
[ 29%] Built target tinyfiledialogs
Scanning dependencies of target Toolbox
[ 32%] Building CXX object Toolbox/CMakeFiles/Toolbox.dir/Common/UndoManager.cpp.o
/home/slapin/Urho3D-Toolbox/Toolbox/Common/UndoManager.cpp: In member function ‘virtual void Urho3D::Undo::XMLParentState::Apply()’:
/home/slapin/Urho3D-Toolbox/Toolbox/Common/UndoManager.cpp:191:17: error: ‘class Urho3D::XMLElement’ has no member named ‘AppendChild’; did you mean ‘GetChild’?
         parent_.AppendChild(item_);
                 ^~~~~~~~~~~
/home/slapin/Urho3D-Toolbox/Toolbox/Common/UndoManager.cpp: In member function ‘void Urho3D::Undo::Manager::XMLRemove(Urho3D::XMLElement&)’:
/home/slapin/Urho3D-Toolbox/Toolbox/Common/UndoManager.cpp:328:13: error: ‘class Urho3D::XMLElement’ has no member named ‘Remove’
     element.Remove();
             ^~~~~~

Upgrade the master and copy autoload, data and coredata by hand

@slapin you need latest SDK build.

@johnnycable that part is bit wonky. Build system is supposed to symlink them automatically from ${URHO3D_HOME}/bin but sometimes that requires to run cmake twice. If it is normal SDK install then yeah you would have to copy over resources. In the future editor should work within your project’s resource path instead.

I have a urho3d_home/build/bin/autoload etc. installation. Those are symlink already. It’s trying to create the symlink of a symlink, which on Os X results in creating an “symlink name copy” symlink in the original directory, and not in your build/bin…

I don’t know where you got that SDK from but the error is from latest github master build.

Please verify if you have this method: Urho3D/XMLElement.h at master · urho3d/Urho3D · GitHub

I tested build with MSVC 2015 before posting here.

Linux gcc build doesn’t work.
Sorry I did not konw this editor was windows-only.
Sorry for the noise then.

Does you Urho include dirrectory contain XMLElement::Remove?

slapin@slapin-pc:~/Urho3D-Toolbox/build$ grep Remove /home/slapin/Urho3D/build/include/Urho3D/Resource/XMLElement.h
    /// Remove a child element. Return true if successful.
    bool RemoveChild(const XMLElement& element);
    /// Remove a child element by name. Return true if successful.
    bool RemoveChild(const String& name);
    /// Remove a child element by name. Return true if successful.
    bool RemoveChild(const char* name);
    /// Remove child elements of certain name, or all child elements if name is empty. Return true if successful.
    bool RemoveChildren(const String& name = String::EMPTY);
    /// Remove child elements of certain name, or all child elements if name is empty. Return true if successful.
    bool RemoveChildren(const char* name);
    /// Remove an attribute by name. Return true if successful.
    bool RemoveAttribute(const String& name = String::EMPTY);
    /// Remove an attribute by name. Return true if successful.
    bool RemoveAttribute(const char* name);

See, no XMLElement::Remove. Update your SDK.

So you don’t have latest Urho revision or haven’t built it.

Well, I pulled in the morning and build with that. Now I pulled in today’s changes so I will check with these.

[ 88%] Linking CXX executable ../bin/Editor
../ThirdParty/imgui/libimgui.a(imgui_freetype.cpp.o): In function `ImGuiFreeType::BuildFontAtlas(ImFontAtlas*, unsigned int)':
imgui_freetype.cpp:(.text+0x67b): undefined reference to `FT_Get_Glyph'
imgui_freetype.cpp:(.text+0x9c1): undefined reference to `FT_Glyph_To_Bitmap'
imgui_freetype.cpp:(.text+0xb87): undefined reference to `FT_Done_Glyph'
imgui_freetype.cpp:(.text+0xfc7): undefined reference to `FT_GlyphSlot_Oblique'
imgui_freetype.cpp:(.text+0xfd4): undefined reference to `FT_GlyphSlot_Embolden'
collect2: error: ld returned 1 exit status

Well, it looks like for some reason the freetype lib is not picked up. Ideas?

Try using engine as SDK without installing it. That is how i am using it. Just set URHO3D_HOME to cmake build dir of engine.

Always did it like this, like since forever.

Weird. Now that i think of it - not sure why on earth it builds for me with freetype… Anyhow do this:

1. Remove imgui_freetype.cpp from here
2. Comment out this
3. Comment out this

I fixed it like here: https://stackoverflow.com/questions/23888274/linking-freetype-with-cmake

works now.

Thanks for help! (20 characters)

I’m interested in this. As I have been working with ImGui