Microbrush 3

Hello. 

In continuation of this thread, I would like to mention that I am now working on a successor to that old editor.
I already made a couple attempts at this, but none worked out until I set a different scope and made a little Minecraft editor. The reception wasn’t very good, for lack of interactivity and a general lack of interest (people prefer building levels in-game, duh), but it was a good opportunity to test my ideas and new technology in the field.

In the past few days, I’ve leaned back and did some conceptual work and arrived at something that looks doable/implementable for me (in finite time!).
Microbrush 3 will have a very limited scope for starters, of providing the means to make and manipulate brushes, and nothing else. There will be no retaining of texture or entity information or anything else: I will consider those things once I have won your hearts in terms of brush modeling and the program became good enough so that people feel an insatiable urge to use it to build their rough level sketches or do heavy brushwork in it, augmenting their normal work in other level editors. Trying to support too many things at once has been my doom in the past, so the limited scope shall save me.

Mb3 will have the same foundation as my Minecraft editor. So even though the respective interactive interfaces for the base plugins don’t feel so good yet, it will offer these things for sure:

  • a companion grid that follows you everywhere and that you can skew and for which you can define another base for the resolution (so instead of powers of 2, use powers of 3 or 10 or something), and which allows for circular/elliptic snapping (with a secondary alignment step to make sure that the world doesn’t explode when compiling the bsp)
  • full control about the projection settings of your viewport, allowing for orthogonal (2D!) views too
  • precise control about the camera placement
  • for these aforementioned plugins, the ability to save the settings in 10 memory slots and easily export, share, store or modify them in text form
  • a plugin to write down notes
  • the ability to clone a viewport on the fly (this is a multi-view editor)
  • the ability to have multiple worlds loaded (this is a multi-world editor with multiple views each)
  • the ability to change the whole business logic (all plugin code) out of the box without third-party programs – I imagine that someday, someone could write a fancy little tool to generate some nice parametrized brushwork
  • you can now assign new keys for flying around and are not constrained to my default wasd config anymore!
  • I will do my best to make it load Half-Life 2 maps natively (… and maybe Half-Life 1 maps too?)

Steam community group

That’s it for now.
I will post updates in this thread when noteworthy things come up.

Releases of the work in progress versions here.


I’ve been following this project for a long time now. Keep it up!

Some name features I’d love to see included is a grid you can rotate so you can work on stuff at an angle, (I assume that’s what you mean by skew) as well as vertex snapping.

The first little step is made. I’ve forked the Minecraft editor and stripped it of Minecraft stuff. This is now the common base. :slight_smile:

Stiffy: At the moment, the grid can not be turned interactively, but you can configure the coordinates of the three main grid axes. Say you wanted to work on a sloped floor: You could just edit the x axis to not be (x = 1, y = 0, z = 0), but (x = 1, y = 0.1, z = 0). That way, the grid would go up a half unit for every unit you go right. This is just the basic bare support for all settings and it allows any grid alignment one could need. It shall be evolved when the need arises later, by me or by someone interested fiddling with the plugin system.

Sounds interesting, Microbrush 2 was a neat tool can’t wait to see what you improve on this time!

The plugin API now has a bunch of functions for drawing basic geometry. With this subsystem, I will draw the visual aids for all the tools, e.g. clip planes and position markers.

that font is really cheesy and hard to read

Agreed - it looks like it’s designed to look cool rather than to be readable easily, which is what you need really.

I’d suggest getting some fontface from Roboto family. Cool, modern, used by Google.

Yes, I agree that it could and should be improved, but that is not a priority for me at the moment because there is no functioning editor yet.

If anyone contributes their own texture replacement for the font, I will gladly link to it as an addon to the editor. The same goes for anything else anyone wants to mod in a useful manner. (once I released a functioning version of this thing)

Just make it seem like a proper windows application

Well, I am not using the standard OS GUI by choice. Hobby project and all. :slight_smile:

Something Ive always wanted in hammer was the ability to be able to rotate the grid. If you could have something like that in Microbrush it would be fantastic!

Yes, and I went a step further.
You can freely configure the three spanning vectors of the grid, independently of each other, per view on the world. This allows not only for rotations, but also for any kind of angled alignment.
And you can freely define all grid colors, line widths, and when a highlight comes, and to which base the resolution increments work (base 10, base 2, base 3, base whateveryoulike!). And you can disable snapping on just one axis while keeping it enabled it on the other. And all of that works for circled grids too. Here you can snap on the circles/ellipses, or the central rays, or both.

These four views all look on the same world:

Without meaning to sound dumb, what do the buttons “C”, “_”, and “M”, “X” mean in the top right corner? Collapse, minimize, maximize, and close? I’m just wondering.

Also, I’m totally digging this project.

Almost. C is for cloning the view on the same world.

The best thing to add would be a way to “walk” through the world, in my opinion. Just a little preview to see how things would look in-game.

Oooh man, but that’s full of collision detection. Really not sure about that.

But with the currently planned API for the plugins, a tool could be made to just cast some rays in many directions and tell the user if the player can fit where he currently is, or not, or even reposition the camera at eye height to “rest” an imaginary player on the floor. The FOV can be altered too. So at least technically, a bit of assistance in that regard is possible… but I gotta add normal level editing stuff first.

I’m just investing some time into polishing the spatial data structures I’ve implemented for Microbrush 2 a bit. In a nutshell, everything in the world is be organized in a tree data structure that rebalances itself as things in the world are transformed, added, removed. This allows me to pick things with raycasts fast enough to allow for paint-selection, and updates to the rendered meshes sent to the graphics card RAM come with a certain locality. Unlike last time, I also make an effort to expose the parameters for fine-tuning those performance aspects in the config from within the program.

In random playing around yesterday, Mb2 handled 200,000 brushes at acceptable performance, with paint-select working just as good as with 20 brushes.

Out of interest, what kind of spatial structures are you using? Are you using a solid-leaf BSP like source does, using the brush planes as splitplanes?

No. BSP is good for the processed map where the hidden surfaces are removed and you deal with high-load shaders, lightmaps, visibility sectors to show and hide high-resolution models and the like, but it is computationally very expensive and not suited for being done on the fly.

I am using a tree structure where brushes (and later, other world artifacts) are grouped together based on how they form clusters in 3D space, so direct neighbors likely land in the same cluster. A bunch of brushes in a leaf cluster node of this tree is rendered into one buffer object on the graphics card. Every artifact in my world has an axis-aligned bounding box (AABB) around it, and the tree’s inner nodes’ AABBs span the AABBs of their children, and the AABB of a leaf node (which is rendered) spans the AABBs of its contents (the brushes).

This data structure allows for showing and hiding content that is roughly grouped together based on a simple distance metric to the cam. But that’s not the important part.

Calculating the geometry from a brush is computationally expensive. In Microbrush 1, everything was just rendered into one buffer on the card, without caching the brush calculation results in any way, so every little update to a brush triggered a full recomputation and rerendering of everything, even in densely populated worlds (change a wall => the whole world is processed again). Now, when I have a sane amount of brushes in a leaf node, updating that one is a lot faster. And with a little more caching, I can get even more performance out of it at the cost of more RAM used.

Casting rays through this tree data structure, to select things, is also faster. Fast enough to allow for casting a ray on each mouse move event, forming the paint-select feature.

There are alternatives to this, like variants of octrees, but I didn’t like their worst case scenarios very much, and the level geometry is usually not distributed very uniformly, and they don’t like massive overlaps and interlocking pieces very much. A tree structure like I have now needs to be updated too on every operation, but while this happens, the nodes are rebalanced, so nodes with too many children are split and nodes with too few are merged, all in a logarithmic time complexity.

In the end, this will hopefully allow for smooth editing of a complex world with a few hundreds of thousands of brushes (and maybe other things).