Crowbar - an open-source editor

NoodleCollie

Stoat fiend
aa
Jul 30, 2009
383
335
With the TF2 SteamPipe conversion predictably breaking the SDK (though admittedly Valve did do a good job of putting a beta out quickly), I began thinking about what it would be like to create an editor from scratch. As lovely as Hammer is, it is incredibly old in places and is lacking some of the more basic functions of a 3D editor - namely things like rotating around arbitrary points, aligning to arbitrary points, nice displacement editing controls and the like. I thought it might also be useful to have the editor open-source - I know that developing an editor from scratch on my own would take inordinate amounts of time and effort and so a collaboration with like-minded people would make sense, but this would also allow anyone who felt like the editor was missing a feature to either request that it be added or go and implement it themselves.

The editor I am calling Crowbar (previously Carve, but a scan through the first three pages of this thread will reveal reasons behind the name change). A list of things I am hoping to implement in and above basic Hammer-style tools is as follows:

  • Allowing rotation around an arbitrary point.
  • Aligning to an arbitrary point.
  • Allowing rotation and translation in both global and local axes.
  • Click-and-drag on faces to select or paint textures.
  • Clipping along an arbitrary plane (even picking a face of a brush to use as a clipping plane) and being able to translate/rotate this plane accurately before performing the clip.
  • Manipulating displacements using brushes similar to those found in terrain editors such as Far Cry.
  • Allowing selection and transformation of arbitrary groups of vertices on displacement surfaces.
  • Allowing the option to select multiple brushes and tie them either to one whole brush entity or many individual brush entities.
  • In-built support to export arbitrary groups of brushes with Propper.
  • Extend Arch tool to add Hole tool - takes a bounding box and creates the convex structure around a hole with 4 or more vertices. (Equivalent but neater way of carving a cylindrical hole in a wall)
  • Vertex rounding. (Idolon)
  • Previews when in the process of creating complex generated primitives such as arches. (Idolon)
  • Measuring tool (Deodorant)

If anyone has other reasonable suggestions to add to this list then I will gladly consider them.

I currently have the workbench branch of the editor on GitHub; it's written using the Qt5 framework in C++ and will utilise OpenGL. I'm not 100% sure how GitHub works (I'm assuming requests can be made to submit revisions etc.) but if you fancy taking a look it's all there. At the moment I'm at the stage of having created an MDI window which can display a (future) FPS, show you an "About" dialogue courtesy of Qt and can close itself. This I'm intending to be the basic application which is then extended by both static and dynamic plugins (static ones being the document system, rendering system, etc. which can be relied upon as core components).
 
Last edited:

Idolon

they/them
aa
Feb 7, 2008
2,105
6,106
I wouldn't mind correct carving. There's an article by someone named Nacimota about how the carve tool should operate that I can't locate (I think his website is gone forever), but the process he described was basically this:

2Ud1g.png

Carving in theory isn't a bad idea, it's just rejected because the tool sucks.

On a related note, I would suggest making vertex rounding an option, as well as being able to show brush creation previews in the 3d viewport so we can stop guess-and-checking arches.

I'll look into trying to create stuff for this. I don't have any experience with C#, but I could definitely use a reason to learn it.
 

NoodleCollie

Stoat fiend
aa
Jul 30, 2009
383
335
My friend told me a while ago that C# is the nicest language he's ever used, and after having used it a bit myself I have to say I'm inclined to agree.

That is an interesting way to carve, actually - the bounding box idea is such a good one I'm surprised Valve didn't implement something like that themselves. Would it still work with carving using a concave (ie. multiple convex) objects? I'm assuming it would but might generate slightly messier results.

As for the feature suggestions, I'll add them to the list. Is vertex rounding rounding the position to the nth decimal place?
 

NoodleCollie

Stoat fiend
aa
Jul 30, 2009
383
335
Here are some thoughts I've had on implementation of features:

UI
One 3D view. Can be set to orthographic (align with any plane in 15 degree increments, draws grid, can set depth of created brushes arbitrarily by Ctrl-Mousewheel [front plane] and Shift-mousewheel [back plane] but otherwise is as deep as the last selected object) or perspective. When in the process of constructing brushes or objects, progress is not lost when changing view mode. Status counter shows current depth when in orthographic mode. When in perspective mode, "depth" axis when changed with mouse wheel is the X/Y/Z axis closest related to the depth axis of the camera.

Arch tool (Came up with this one in bed, I'm proud)
Depth determined by above counter. First press sets origin, drag and first release sets radius; second press sets arch thickness, drag and second release sets degrees from initial point through which to create the arch (defaults to 15 degree increments but can be set arbitrarily by holding Alt) and finishes arch. At any time during creation the mouse wheel can be used to increment or decrement the quality (number of vertices) of the arch and escape will cancel the arch creation. If an ellipsoid arch is required, first press and release sets origin, drag and second press sets width, drag and second release sets height and third press and release sets thickness and degrees as above.



IO
Logical entities can be connected to each other in an IO window regardless of where they are placed in the map, so you don't have to go around chasing down an entity in 3D space to namepick it. Logic_cases are streamlined by creating a wrapper object allowing for a max of 16 x 16 random outputs (3 logic_cases).

Displacements
Displacements will auto-sew to neighbours by default (can be turned off). When adding a displacement that fits between multiple neighbours, vertices will be set up by default to be linearly interpolated between the positions of each opposite side vertices (ie. if a vertex at one edge is 10 units high and its counterpart on the opposite edge at 3 units high, vertices in-between these two counterparts will be set to lie along the "connecting line" which begins at the higher vertex and ends at the lower vertex). Displacements can be locked, which means that when they are sewn with other displacements only the vertices on these corresponding displacements will move.

Rope tool
Streamline the PITA method of creating ropes: a string of nodes which can be edited at will to change global properties of a rope such as thickness, slack, etc. (and where each node has the option to have its own properties edited further to deviate from the global settings). Is intended to remain as a wrapper object in itself and be evaluated at compile-time, but can be collapsed back to basic rope entities manually if need be.

Stream tool (Inspired by Crysis)
Tool to easily allow creation of flowing streams using the CS:S animated-texture-on-displacement method by specifying flow direction and placing nodes which specify the width of the stream at their position. Can be collapsed down to basic displacement faces if required.

Water flow tool (Currently unsure how flow works, the following is a possible prototype)
Allow node paths to specify the direction and speed of flowing water as supported by L4D2/Portal 2. Seeing as Valve used a custom Maya/whatever plugin to accomplish flow it makes sense to try and accomplish this without requiring a specialist modelling tool and clunky exports from Hammer to paint flowmaps.

Will add more if there are any suggestions.

EDIT: One thing that crosses my mind is whether we should switch to OpenGL early (ie. now), since DirectX would limit the use to Windows machines and it may be advantageous to be multi-platform later on. The only issue with this is that I'm building the thing in VS2012 (which is very nice) and I don't really know how to compile for other platforms, or even if C# would work with them. I'd rather not over-complicate things with C++ if I can help it (it takes a hell of a lot longer to get anything done), although having said that http://www.wxwidgets.org/ looks quite good.
 
Last edited:

Ravidge

Grand Vizier
aa
May 14, 2008
1,544
2,818
The by far smartest thing to add to a new editor would be to allow the community to make add-ons and plugins easily. Or replace existing tools/add their own tools.

If it's setup so that the developers add tools the same way a community member would, that is perfect. The more power you give the users the better, especially for creative communities like these..

Trying to out-create the larger community yourself, or fulfill everyones wishes is hard. Better to just make something that works and is stable by itself.

Sort of how Soucemod works. The base install of SM is pretty basic, but you can add so many things to it that makes it better for your needs. The role of the SM developers is not to make the plugins/tools/addons, it's to provide a stable platform for the community to create whatever they want and/or need.
(I would say sort of how 3ds max works, but I figure more people know the basic workings of SM rather than a modeling application around here, but yeah if you've ever downloaded plugins for max, then you know what I mean)
 
Last edited:

Arne

L3: Member
Nov 22, 2012
114
55
I got three ideas which I think would be useful to use, if possible.

1. Fully customable 2D viewports with support for multiplie screens. Hammer have only y/x, y/x and z/x. Why not add x/z, x/y and z/y? That would make some difference.

2. Preference Tool. A tool that places a edtior-side entity into the source file. Where you can t.ex. see the miniuim height for a standing player, so you know how high your roof should be. And t.ex. the range of a sentry, so you know how you know how to balance the map. The preference entities don't get into the compiling so they don't affect the compiled version of the map. They are only saved and visible inside the source file.

3. Projectlie simluator. Nuff said, a tool that simluates how the map and it's physics "affects" t.ex. the soldiers' rockets, demomens' grenades and stickies. Everything which are projectlies are affected and simluated by being shoot/launched from a "shooter"-entity with customable angels, position settings and weapon type. The result can be visible by a simluated trail of where the projectlie went in the viewports.
Like the preference tool, they are not included in the compiled map.
 
Last edited:

NoodleCollie

Stoat fiend
aa
Jul 30, 2009
383
335
I definitely agree on the plugins front - the difficult bit would be for me to learn how to actually code a plugin interface. I guess it's something to look into.

As for the preference-style entities, I think they're quite a good idea. Again, if plugins are concerned they sound like they could be something that could be added in that way.
 

stegarootbeer

L2: Junior Member
Jan 15, 2012
78
100
I would ask that you change the name so we don't have to tell anybody to use carve. Would be confusing to someone who is new and we might try to help out. Also telling them to never use carve (which is something people will also find said in many tutorials) would be detrimental to the success of the program.
 
Mar 23, 2010
1,872
1,696
petition to change the name to crave
 

Pocket

Half a Lambert is better than one.
aa
Nov 14, 2009
4,694
2,579
If you're aiming for OS X and Linux compatibility, I recommend using some sort of cross-platform framework to begin with. Source Filmmaker was built (rebuilt?) in Qt, and the existence of Hammer tool icons hidden in its files suggests that Valve's own next-gen map editor is as well.
 

Arne

L3: Member
Nov 22, 2012
114
55
We have to find a better name for this Open-Source VMF editor.
So here's my suggestion.

OpenVEditor

Anyone got more?
 

WhyNott

L1: Registered
Oct 21, 2012
27
1
Mabe to keep the "tool" theme of level editors, something like "Wrench" or "crowbar"?
 

A Boojum Snark

Toraipoddodezain Mazahabado
aa
Nov 2, 2007
4,775
7,669
As Ravidge said, I've always wanted plugin support for Hammer. It would be the most ideal solution to all the things people want.

One 3D view.
Please no. Something like this should always be an option. Never force the user to have a specific viewport setup. Giving customizable viewport locations and types is best.

Logic_cases are streamlined by creating a wrapper object allowing for a max of 16 x 16 random outputs (3 logic_cases).
Wouldn't that be 17 logic_case? For what reason, too? How often are you going to need so many options that an automated case-chaining is helpful? It's fine to throw it in if you want, just strikes me as frivolous.



Stream tool (Inspired by Crysis)
Tool to easily allow creation of flowing streams using the CS:S animated-texture-on-displacement method by specifying flow direction and placing nodes which specify the width of the stream at their position. Can be collapsed down to basic displacement faces if required.
This sounds like you are venturing into things that the engine simply doesn't do. A displacement can only have one texture alignment on it. Maybe I'm not understanding the method for accomplishing this.

Water flow tool (Currently unsure how flow works, the following is a possible prototype)
This stuff? (pdf) Would be neat to have in the map editor, but is potentially a big project since there are so many situation cases and artistic touch things you would need to supply an interface for.

1. Fully customable 2D viewports with support for multiplie screens. Hammer have only y/x, y/x and z/x. Why not add x/z, x/y and z/y? That would make some difference.
Isn't y/z and z/y the same thing? Or do you mean having the viewport rotated 90 degrees? I don't really know what you mean because there are only three major planes and flipping or turning them doesn't seem very useful.

3. Projectlie simluator. Like the preference tool, they are not included in the compiled map.
What would you use this for? If it isn't actually compiled in the form of env_shooter or env_entity_maker I don't see how it is easier to set up a test entity rather than just launch the map and shoot stuff (especially if you want to do more than one location).
 

Ravidge

Grand Vizier
aa
May 14, 2008
1,544
2,818
I definitely agree on the plugins front - the difficult bit would be for me to learn how to actually code a plugin interface. I guess it's something to look into.

As for the preference-style entities, I think they're quite a good idea. Again, if plugins are concerned they sound like they could be something that could be added in that way.

If you start out with the mindset that -everything- is a addon/plugin/tool you'll have a much nicer program in my opinion. When you create the "create brush" tool or "create entity" tool, you should add those as addons to your program, not hardcode them in. Add them to the program just like a regular user would have, the same access etc.

The program should be as bare bones as possible, and shipped with a bunch of standard/default tools that you've made. But everything can be replaced.

This is how I'd do it at least, if I had the knowledge and ambition to take on a project like this. A stable platform with a flexible UI. I absolutely love modular applications.