A potentially protean world builder for Urho3D and its forks.

• Latest build on itch (64-bit Linux)

• Repository

• Wiki

1159×810

Looks neat. Can’t wait to see what people do with this. Heck, you said you’re still working on it? Just that fact makes this interesting.

Thanks, I started on it today. I gained some experience working on Edddy combining the two frameworks.

Now working on a material editor:

MaterialEditor.png338×511 25.6 KB

I like it. If you or someone else makes a full editor with this will it be merged with the rest of urho?

That is one of the goals I hope to help achieve.
…for Urho to have at least one native editor (in a separate repository).

I’m thinking it might not be such a bad idea to work towards a world builder that has different modes. Like a default mode (akin to current Urho editor), grid mode (like Edddy), terrain and planet mode. A bit like Blender’s UI layouts, but also changing the available tools and keycuts… like when changing the interaction mode in Blender.

Would be awesome if we could brush based map editing without needing to make our own editor/importer for an existing mapping software.

Have you seen the work by @JTippetts1?
Qt knowns tablet pressure.

By brush I mean like a BSP brush, like early ID tech or Source. I find it really useful for blocking out prototype levels.

Ah, that would also make an interesting mode that I overlooked indeed. You’d basically be building custom geometry, right? When it comes to BSP I’m more familiar with the early Unreal approach ; the tunneling variant. But I guess that’s basically a difference in normals.

If you really need an idea of the workflow and you have Quake I’d suggest checking out TrenchBroom. Really good tool that I think is a really awesome example of what a modern quake-like level editor should look like.

@GoldenThumbs I intend to focus on the part that “works like Edddy” and hope there will some day be contributions from people like you (mr BSP mode) and @JTippetts1 (mr Terrain mode).

This project grew mainly out of my discovery of the QDockWidget. They can be tiled, stacked, floated and closed which allows for a great deal of variety in possible UI layouts.

How does ManaWarg sound as a name for this magimythical colonial organism?

Would you accept it as a name of the next official Urho editor?

Made a logo:

The M and G are a bit hard to read. I saw them as N and Q. But the logo itself is good

Indeed, as first scribble, it could use some balancing out. Also his tail should be stringier; less fart-like.

Renamed repo and created icon:

I think this will guide the next version of the logo as well.

4 posts were split to a new topic: The Urho3D logo

The fish is now alive with that logo.
Looks great.

Uniform anyone? —

I have heaps of Quake map parsing and plane-bounded-volume code if you want it. Though it’s all in FixedPoint (Q31.32) it should be trivial to port over (changed FixedVector3 to Vector3, etc). Really, the big deal is the winding handling, even though that stuff is well documented since the 80s and basically everyone does it the same … it’s a complete asshole to write and troubleshoot.

The map parsing stuff is in C#, but stb_c_lexer should do the trick (I load MAP files in C# and emit a compatible binary). IIRC I handle collisions and sliding the same as one of the old Graphics Gems books covers it, which is basically the same as quake. So rays, swept spheres, swept boxes, and swept capsules are supported - I handle terrains using Unreal Engine 2’s method and record movers seperately from the BVH for static hulls.

My handling of Quake3 patches and meshes (the gridded ones, ie. terrains) is garbage nonsense though, I barely understand WTF I was doing there … it works and loads Quake 3 / COD maps though … so whatever.

I just figure all those young blonde girls jumping in shouting “Oh, look, what is it?”

When passing a command line argument to ManaWarg it now checks whether it refers to a material that can be loaded and (if it can) will set a MaterialEditor as its central widget, leaving out all other functionality:

The same should be possible for particle effects, allowing unencumbered resource creation/modification.

I like how it looks like ATF: https://github.com/SonyWWS/LevelEditor

Are you planning on using any library for gizmos?

I’m using Qt for the widgets and plan to create my own gizmos, if by that you mean 3D transform handles.

…but I’m open to suggestions.

Many:

And QML: https://github.com/fferri/qt3d-transform-gizmo

About what I expected. No thanks.

Just steal the gizmo functionality from rbfx, hehe… . He has a fork separately for that. Rip off it

Unlikely.

MaterialEditor.png409×620 152 KB

Some personal reason to use GitLab? Btw nice idea, I want to back to Urho3D soon.

Because GitHub seems to have sold us out.

Microsoft to acquire GitHub for $7.5 billion

https://github.com/LucKeyProductions/MoveNotice/blob/master/README.md

It’s all git, just a different upstream domain; a simple Hu->La.

And it’s good to hear ManaWarg already increases your interest in the engine.

I strongly recommend against LibGizmo, it and ImGuizmo are probably the most absurd pain I’ve ever tolerated for no gain in a library.

I use im3d myself, with some heavy changes for bounds-extent sizing. It’s the only decent one I’ve come across that splits the inputs.

If a gizmo asks for a complete matrix then the only thing it’s good for is a single root object. Value drift makes LibGizmo / ImGuizmo useless for hierarchies in my experience.

At first glance, that looks quite solid, thanks! It may be useful.

Here’s my implementation for IM3D: https://gist.github.com/JSandusky/7a2d99d60c5ad41962d518afe223c41d

Uses geometry shader, but IIRC there’s an OpenGL 3.1 sample for Im3d which doesn’t use geometry shaders. Can be rendered from E_ENDVIEWRENDER, or by adding it into code like DebugRenderer already draws.

Fairly certain there’s some broken cludge in there. I recall having previously messed around with doing some alternative manipulators (normal / plane) before opting on just masking out axes of the translate/rotate/scale manipulators.

I intend to create something similar with LogicComponents that use billboards for the grips, rendered in a separate scene. Also Blender-style keycuts for grabbing, rotating and scaling. I never use the gizmos in Blender which saves clutter in the viewport as I set it to be hidden.

Using billboards is a really good idea. Then you can just raycast, get the UV coordinates and sample an Image for alpha to identify a hit. Wish I’d thought of that before.

Rather I was thinking to use the full plane as a hit, to make it less of a precision click, but I will see when I get there.

So, like UE?

Like ManaWarg.

ManaWarg now has HSV sliders:

HSVA seem to be aligned to right, which effectively misaligns the labels. They should be aligned to middle or left.

Fixed!

I set up a wiki for the project:

Materials and models can now be dragged from the Resource Browser and dropped into the Material Editor to either open the material or set a custom preview model.

This now also works for scene files that are dropped onto a SceneViewer.

With the help of @Miegamicis the latest build of ManaWarg/master/HEAD can now be found on itch.

CI/CD ftw!

this is so great. don’t stop until it’s perfect!

I decided to change the default layout:

Looks nice ,
However it won’t work on Mac OS , since Qt on Mac is not compatible with SDL2.

SDL_CreateWindowFrom()
This function expects NSWindow however Qt is passing NSView (in your case its fishTrap->winId())

There were some attempts to modify SDL2 to support wxWidgets and Qt , one of them can be found in

Thanks for pointing it out.
I do not have a Mac, but if anyone figures out a workaround, please do send a PR.

I have now learned the unending pain of trying to get this to work on Windows. Looks like I may be getting close to it though.

So, is this dead? why? Urho’s editor’s horrible coming from godot

Not dead, hibernating.

Switching to Linux is probably easier.

And you just came back to us? Or why are you here if GodotEditor was so much better?

Maybe Zaroio is evaluating Urho3D. Doesn’t make them committed to it.

I do like Urho better, already had a project with it. Wanna finish it.

New welcome screen:

And quite some less visible changes.

Looking sharp.
Maybe add script loading and reload function so we could change component behaviour on the fly :).

In some sense, Urho has no editor.
It is pretty much official position that Editor.as is basically advanced scripting example and was never intended to be an actual Editor in the same way as Godot/Unity/whatever.

In another sense Urho has a dozen - or so - editors, if you were to include the more specialized tools (for particles, terrain and materials), unfinished projects and Blender.

If this could be used for shader editing and extending this would be amazing.

Hi! Binaries don’t works on last ubuntu. And your Qt-APPs freeze on last ubuntu… I tried Edddy and ManaWarg… I was tested with Example.edy project, and when I click on emp or ebs items the qt apps freeze… I did some debug, but I can’t found solution… If I can do some test or give you some information for help to fix it, only ask me. Thanks.

The freezing is a known issue and I’d love to see it resolved, but (un)fortunately I cannot reproduce it. This makes it hard to fix on my own, so your help would be very much appreciated. Please join the gitter room or reply to the issue on GitLab, so we might solve this problem.
Although I must first get some sleep.

I’ll try help… thanks!

hello, me again, sorry for not using gitlab, but I don’t know how to use it. I’ve been testing and researching, the freeze happens when glClear is executed (or other OpenGL operation like X11_GL_SwapWindow, this stuck on futex_wait_cancelable) after loading a project, or resize the window, or double-clicking the material editor. It seems to be something with QT (qt5?) And OpenGL on intelhd boards. Inside the driver it hangs in an xcb_wait_for_special_event. I don’t know QT works internally, so I can’t help too much. Maybe QT + OpenGL is not a good idea. I tried lot of things… I change all signals: for Q_SIGNAL, emit: for Q_EMIT, connect for QObject::connect and fix other bugs on Profiler.cpp in Dry (posible buffer overflow), but don’t fix the problem. :’(
I must add if I close all views with opengl (Dry) it works… but freeze when I open a project because I can’t close the main view.

I’ve been told QThreads may hold the solution.

thanks for reply! what is the patch that you suggest? I can test it.

I have no patch ready and - so far - also no experience with QThreads.

https://www.qt.io/blog/qt-offering-changes-2020

Long-term-supported (LTS) releases and the offline installer will become available to commercial licensees only

This means open-source users will receive patch-level releases of 5.15 until the next minor release will become available. This means that we will handle Qt 5.15 in the same way as e.g. 5.13 or 5.14 for open source users.

This means that they can do anything and change license at any time.

Or does it mean their online installer is a kind of spyware, and that’s their real interest? I’m not researching this up, I don’t care / won’t use Qt. But it’s the first thing that springs to mind, when someone forces online interaction. Maybe they “just” want “telemetry”.

In principle, since it’s open source, someone could write an offline installer. In practice, I wonder who wants to do the work, and spend time fighting Qt?

I’d assume anyone using Microsoft products doesn’t really care about that.

I was more interested in what the FLOSS crowd would care about.

Repository packages and the availability of source code, I guess. Not so much online/offline “installers”.

I tend to forget that Installers are more typically a Windows thing. What does OSX do nowadays? Do things just work by dragging folders around, no installation per se?

Please keep on the subject of the thread.