• Microbrush 3
    142 replies, posted
Hello.  In continuation of [url=http://www.facepunch.com/showthread.php?t=840670]this thread[/url], 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 [url=http://shrinker.seriouszone.com/projects/IterationX/Creeperchest/]a little Minecraft editor[/url]. 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 [i]very[/i] limited scope for starters, of providing the means to make and manipulate brushes, and [i]nothing else[/i]. 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: - [url=http://forum.interlopers.net/viewtopic.php?f=2&t=33377]a companion grid that follows you everywhere and that you can skew[/url] 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?) [url=http://steamcommunity.com/groups/Microbrush3]Steam community group[/url] That's it for now. I will post updates in this thread when noteworthy things come up. [b][url=http://shrinker.seriouszone.com/projects/IterationX/Microbrush3/]Releases of the work in progress versions here.[/url][/b] -S [img]http://shrinker.beyond-veils.de/temp15f/2015-01-29%20Mb3%20patches%20radiant.jpg[/img]
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. :) [img]http://shrinker.beyond-veils.de/temp14f/20140516-mb3-first.png[/img] 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. [img]http://shrinker.beyond-veils.de/temp14f/20140520-mb3-visfunctions.png[/img]
[QUOTE=Noi;44869469]that font is really cheesy and hard to read[/QUOTE] Agreed - it looks like it's designed to look cool rather than to be readable easily, which is what you need really.
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)
[QUOTE=Noi;44869615]I'd suggest getting some fontface from Roboto family. Cool, modern, used by Google.[/QUOTE] Just make it seem like a proper windows application
Well, I am not using the standard OS GUI by choice. Hobby project and all. :)
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: [img]http://shrinker.beyond-veils.de/temp14f/20140522-mb3-gridvectors.png[/img]
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.
[QUOTE=Shrinker42;44902597]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.[/QUOTE] 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).
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. :D [img]http://shrinker.beyond-veils.de/temp14f/20140530-mb3-clusters.png[/img] 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. ^^ [img]http://shrinker.beyond-veils.de/temp14f/20140602-mb3-clustersfinal.png[/img] 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. :D
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: [url]http://www.uberent.com/pa/wp-content/uploads/sites/2/2013/03/PA_units_01_public.jpg[/url] (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 :D 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. [QUOTE]I'd suggest getting some fontface from Roboto family. Cool, modern, used by Google.[/QUOTE] 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] [QUOTE=ryankingstone;45103182]Don't force shaders on people, let it be an option, so the people who doesn't like it - can disable it.[/QUOTE] 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 [B]scripting system[/B] for [B]objects/brushes[/B] and we have ourselves[B] a mini game engine[/B] :D[B] Gamemaker [/B]has a pretty nice approach to this type of scripting with its object based intuitive methods. [B]Example of a list of functions built into gamemaker[/B] that would be really cool to see emulated or applied to your little microbrush program. [url]http://gamemaker.wikia.com/wiki/List_of_functions[/url] 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. :D
[u]Forcing shaders on people:[/u] I [i]have[/i] to "force" shaders on people. Please understand that they are a tool for making the graphics API do not just what I [i]want[/i], but also what I [i]need[/i] 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. [u]Textures:[/u] Need them at later editor stages. [u]Collision detection:[/u] Don't really need this for my editor, so let's shove this into the late future. [u]Interactive editor-game hybrid:[/u] 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. [u]Font/text display:[/u] 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. [u]Shader plugin system:[/u] 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. [u]Scripting system:[/u] 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. [u]Basically making a YOYO game maker clone:[/u] That is not my mission. I encourage everyone to program stuff on their own. :)
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. Whew. [i]*happydance*[/i]
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, [t]http://i.imgur.com/ypqHy76.jpg[/t] 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: [code] config.cfg: akula { rgb backgroundColor = vec3(0.5, 0.5, 0.5); gui { 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); [/code] 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). [url=http://shrinker.beyond-veils.de/temp14f/2014-06-26-mb3-wave.png][img]http://shrinker.beyond-veils.de/temp14f/2014-06-26-mb3-wave_t.jpg[/img][/url] For the inclined: [code]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)); C::addBrush(b); }[/code]
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: [img]http://shrinker.beyond-veils.de/temp14f/2014-07-31-mb3-fontsys.png[/img] (... 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.
Sorry, you need to Log In to post a reply to this thread.