Microbrush 3

Phew. After carefully reviewing and fixing my spatial data structure stuff again and again, I finally got far enough to make a test application.
Was a long road to this point, and it seems I have a lot of debugging ahead. But I’m slowly getting there. :smiley:

For me, this proves to be one of the most difficult parts of editor development.

Sorry for the multipost. I am very happy to say that my spatial data structure stuff, the hardest thing on the road to a new Microbrush, now works as I hoped. ^^

That was a lot of figuring out special cases and treating them right. And it now doesn’t crash even when wildly adding and removing stuff again, and the end result/the collapsed tree is compact again, and it also appears to not leak any memory. :smiley:

Some status updates because the road to showing my first actual brush is long.

I’ve looked a bit at the bezier patch meshes of Quake 3 in GtkRadiant because I someday want to support them, but decided against them for the first release. Not only do you have to plan what you want to have, but also plan what you don’t want to have yet in order to get your project done.

The standard plugins (camera, grid, projections) got their reset values stored in their respective config files now. So when I reset the grid, it just applies the grid config reset values and sets the cell size to 16. If wished, one could also always reset the grid to be circular and stuff. In Microbrush 2, I used a weird display factor in the config to account for the scale in Quake engine games, but this here is now better. My principal coordinate axes will still be different from the Quake axes for the time being, but I have yet to see if that will be a problem.

I’ve made up my mind a bit more about the target level formats, and I think I want to make sure that I can import from and export to Quake 1-3, Doom 3, Half-Life 1, and 2. In Microbrush 2 times, people asked for support for the pre-Source Counter-Strike. That will be possible. Level features that are not supported by the target format will be dropped when saving with a warning when I am at that point.

I’ve modernized my algorithm for calculating the brush geometry to work with my current tech. This was another difficult ingredient of the overall system that’s now done. There are pretty much no big unknowns left at the moment that could obstruct my general plan.

Since the beginning I wanted to change the display of brushes in my editor from flat rendering with 1-pixel outlines to something akin to what can now be seen in Planetary Annihilation: http://www.uberent.com/pa/wp-content/uploads/sites/2/2013/03/PA_units_01_public.jpg (pay attention to the rock formations) – I want to gently emphasize the edges of the brushes with a shader. This posed quite a few problems, of which I think I have solved one now. In the shader, I can work with values interpolated along triangles and I can do a bunch of vector math. Using these ingredients, I will try to display borders of uniform width on all polygons. For that, I can’t just say that one side of a triangle will be marked accordingly, but instead I must be flexible enough to display different combinations of borders and border angles on every single triangle. I think I figured out on paper now how I can do this.

My first displayed brush will be pretty ugly because it will not yet be decorated with that to be developed shader. :9

Don’t force shaders on people, let it be an option, so the people who doesn’t like it - can disable it.

You realize if you simply implemented textures and collision detection you would be giving the world what they so crave, a game where you can have intelligent precise and intuitive tools and create content and assets on the fly. I mean, yeah it’s a lot of work and you don’t have to, but if you don’t I probably will here shortly, not that anyone needs to believe me :smiley:

PS: I REALLY really like what you are doing. And for font might I recommend Tohama, since is scales to pixel fonts really effectively. Me and my friends are doing some initial steps in coding our own autocad-esque hammer game scripter toolkit, like gamemaker, vexels, and autocad and hammer all in one. Good work very inspiring and I really like the pragmaticism.

Why not include a script to read the users font library like microsoft word/photoshop do and let them choose if they hate your font choice so much lol.

[editline]14th June 2014[/editline]

This isn’t a bad idea, however it would be really cool to create a shader plugin system for Open gl, direct x, or whatever-the-fk people want. Just a i/o library folder and whatever IDK, I’m just a plebeian when it comes to the differences between shader APIs.

  • Hell throw in a scripting system for objects/brushes and we have ourselves** a mini game engine** :D** Gamemaker **has a pretty nice approach to this type of scripting with its object based intuitive methods.

Example of a list of functions built into gamemaker that would be really cool to see emulated or applied to your little microbrush program. http://gamemaker.wikia.com/wiki/List_of_functions

The reason I’m sharing this is because I’m not trying to make money off this idea or tool, I just want to see it happen no matter who makes it. If you went with a scripting library based off the syntax of an exisiting one you would already have a userbase ready to script and code games as the YOYO game maker community has been around for a decade and growing. But they are hungry for a true 3D version of the utility, as its largely 2d based. If you somehow managed to pull this off you would pretty much have an instant userbase. :smiley:

Forcing shaders on people: I have to “force” shaders on people. Please understand that they are a tool for making the graphics API do not just what I want, but also what I need in order to fulfill my mission. Shaders might imply super duper graphics features to the average gamer, but to me as a computer scientist they are just the highly versatile programmable part of a modern graphics pipeline. And in the new comtemporary programming models of OpenGL and DirectX, you are supposed to use (simple) shaders even to just get flat-shaded untextured polygons on screen. Disabling shaders usually means disabling all rendering nowadays.

Textures: Need them at later editor stages.

Collision detection: Don’t really need this for my editor, so let’s shove this into the late future.

Interactive editor-game hybrid: This is unfortunately not my goal. I am one person and this is my hobby project. Making a hybrid environment that allows playing and editing at the same time requires a completely different mission statement and, in most cases, a big team of developers.

Font/text display: Still on my todo list for when I can edit levels. Please don’t feel too constrained for now, as the font texture can be edited out of the box. I am making an editor, not a word processor or LaTeX clone, so spending a lot of time on a system or “script” to allow for selecting one font of many would be indicative of missing that point and derailing my own project.

Shader plugin system: At the moment, I know the shader languages GLSL for OpenGL, HLSL for DirectX and Cg by NVidia for both. I support GLSL for OpenGL because my technology uses OpenGL. Supporting Cg would be possible but is not planned. Supporting HLSL+DirectX is not planned.

Scripting system: This editor technology is very programmable. However, the focus of Microbrush is on manipulating the loads of static architecture, so even though I can think of how games with a simple non-realtime UI (like chess) could be built with my API, please don’t expect dedicated support for simulating objects in a game engine manner in a runtime/gameplay scenario.

Basically making a YOYO game maker clone: That is not my mission. I encourage everyone to program stuff on their own. :slight_smile:

Just now, Microbrush 3 computed its first brush.
There’s no display yet, but the raw data I’m looking at in the debugger looks just like I wanted it to.

I don’t think I am significant or special, but I thought you may find a darker theme easier on the eyes for us mappers,

this is just a sloppy mockup obviously I’m just throwing things around childishly, but I hope it sits well with some who may find it appealing or easier on the eyes, and I’m not suggesting this what is HAS to be just a mere suggestion of a theme if you will, thanks good dude brother friend! haha. It is YOUR project okay and us plebs merely can only shout out what we think here and there, feedback if you will, after all I hope thats what you expected!

Lol Microbrush 2 is coming back at me.

Here are excerpts from the Microbrush 3 config:

	rgb    backgroundColor   = vec3(0.5, 0.5, 0.5);
		rgb    activeColor         = vec3(1, 0.75, 0);
		string activeResetString   = ""; //to set the default font color for active controls
		rgb    connectionColor     = vec3(0.375, 0.375, 0.375);
		rgb    highlightColor      = vec3(0.75, 0.75, 0.75);
		string inactiveResetString = "\\c9F9F9F"; //to set the default font color for inactive controls
		rgb    mainColor           = vec3(0.25, 0.25, 0.25);

world controller.cfg:
rgb view.backgroundColor = vec3(1, 1, 1);

This means that you can configure such color schemes right out of the box and even involve the text display colors.

Hope that helps.

Finally, my first brush (it’s one of them).

For the inclined:

void box(vec3 &min, vec3 &d)
	vec3 max = min+d;
	C::Brush b;
	b.planes += (min, vec3( d.x,    0,    0), vec3(   0,    0,  d.z));
	b.planes += (min, vec3(   0,  d.y,    0), vec3( d.x,    0,    0));
	b.planes += (min, vec3(   0,    0,  d.z), vec3(   0,  d.y,    0));
	b.planes += (max, vec3(-d.x,    0,    0), vec3(   0, -d.y,    0));
	b.planes += (max, vec3(   0, -d.y,    0), vec3(   0,    0, -d.z));
	b.planes += (max, vec3(   0,    0, -d.z), vec3(-d.x,    0,    0));

Okay, I have worked on the font rendering stuff a little. It’s now easier to define what texel area the glyphs will have on the font texture, and what aspect ration when drawn.

Here’s the first visible improvement step:

(… it may just be a snapshot from random testing)

I know people have bitched about this already but I think a bolded courier would be a a good choice of font because of how clear it is to read.

New “light”-weight font:

http://shrinker.beyond-veils.de/temp14f/2014-08-02 mb3 font light.png

New “strong”-weight font:

http://shrinker.beyond-veils.de/temp14f/2014-08-02 mb3 font strong.png

Yes, I’m drawing them on my own, because why not. :3

A note to people who rated “dumb” on my post about this being a hobby project and all: This IS my hobby project and all, so if I decide to remake something on my own, because I enjoy it, I have every damn right to do so. If I were a company or somehow contractually bound to do something, criticizing my inefficient ways would make sense, but here I am with my little hobby project and no guarantees about anything and no fees. :wink:

I’m so proud of this now. ^^
Text display demo with a bit of Wikipedia text:

I hope by default it uses arial or something.

Err, no.

I think that last text he showed is fine.

I don’t think it’s good. It reminds me of Comic Sans and is awkward to read.

Why not make it so people can choose between font sets then? If this is just a hobby and you don’t care about the people using it or their user experience, then why would you make a thread about it in the subforum of the demographic that would be most suited to using it? Why not just make it over in the WAYWO thread?

[editline]3rd August 2014[/editline]

It’s fine that it’s your baby and you want to put your own spin on it, but at least take some constructive criticism from the people you’re showing it to…

[editline]3rd August 2014[/editline]

I don’t think the font you’ve drawn up looks bad, I just think it’d be nice to have something more regular like arial or courier if you’re using the tool often.

Yeah the font isn’t bad, but its not exactly something you would use in a development tool. Arial is made to be simple, with nothing giving it a “stylistic” look.