Substractive level editor for The Dark Mod missions?

[Nico A.]

Is it somehow possible to use a level editor that offers substractive editing mode (as opposed to additive as in Dark Radiant) and convert it to a file format that can be played in The Dark Mod?

 

I mean shouldn't it be possible to generate an additive map algorithmically from only subtractive information?

 

If no, why not?

 

If yes, are there any such level editors?

[SteveL]

One of the intermediate stages of dmapping looks like a subtractive geometry map -- the stage after it's finished working out which (parts of) brush faces can be reached by entities and then it's stripped away all the other brush faces.

 

I've never used any other editor so I have no idea whether subtractive mapping would be compatible with our workflow. But all our game assets are set up for DR so I can't imagine it being possible to translate them into another editor. You could make some worldspawn in another editor maybe, but it wouldn't be compatible with dmap which expects the world to be made out convex brushes (actually what gets stored is the map file is just planes, and dmap reconstructs your brushes from where those planes intersect).

 

What's the advantage of the subtractive method? One advantage of our additive method is it forces the mapper to fix their leaks rather than leaving it to the game engine to make guesses (often inefficient).

[Nico A.]

What's the advantage of the subtractive method?

I'm glad you asked!

I wrote about why I think it's superior in this thread:

http://forums.thedarkmod.com/topic/14995-why-not-subtractive-geometry-in-dark-radiant/?p=317410

In short: I consider it way more user-friendly for the map maker. I used DromEd a while ago and I got way more done in the same time compared to working in Dark Radiant.

 

One of the intermediate stages of dmapping looks like a subtractive geometry map -- the stage after it's finished working out which (parts of) brush faces can be reached by entities and then it's stripped away all the other brush faces.

I understand it correctly that the additive mode adds another processing step during compiling rather than building subtractively in the first place? Another argument in favor of the latter...

 

leaving it to the game engine to make guesses (often inefficient).

I don't really see the problem here. Creating a sealed room in the substractive mode it as easy as drawing a brush. No wall brushes to be added, no Make Room command necessary.

[demagogue]

- Draw Brush

vs.

- Draw Brush

- Make Room

 

You're saving maybe half a second.

The other job subtractive geometry does, shaping brushes, can be done with the cut tool in DR.

 

I'm fine with either way, but I do like the flexibility of placing my own portals for DR. /shrug/ mappers have different preferences anyway, so I don't criticise whatever one likes to do that keeps them happy working. I think subtractive is good mostly just psychologically though, but even that's not nothing and if you like it, more power to you.

[Spooks]

You can emulate a substractive building mode in DR if you really want. Make a cuboid as big as you want, then draw smaller cuboids inside it and use CSG Carve, then delete the brush you used for carving, or move it and carve again. You'll soon see the problem with it all though.

 

Quake and its derivatives use Binary Space Partitioning, meaning you can't have concave brushes. The carving algorithms don't have the concept of cutting brushes symmetrically and the carve has to happen right away, so with enough carves your convex brushes will be reduced to mush. Even if you don't plan on doing any additive operations (which would be really hard at that stage), the compiled map will have a lot of degenerate triangles.

 

It's kind of the same thing like trying to carve a torus inside of a sphere in Source's Hammer. Only bad things happen.

[Nico A.]

I'm fine with either way, but I do like the flexibility of placing my own portals for DR.

Well, that's the first advantage of additive level editing I've heard thus far. Okay, I've also heard it should be better with large open world areas, but

a) Thief-like games don't really have/need such open areas and

I don't think you can build great open outdoor areas with Dark Radiant either.

 

If there'll ever be a Dark Mod Version 2 (I mean, why not?), please make the editor so that the mapper can choose between the modes.

Edited May 6, 2016 by Nico A.

[Xarg]

I'll get the team right on it.

 

[Melan]

Note, Dromed is not simply a subtractive level editor, it is a level editor that does both additive and subtractive geometry, and within its framework, does both rather well.

 

However, as much as I like that feature, I have to say team efforts are better spent elsewhere. Missions and more missions - this is what TDM is about. The game is essentially complete, and with 2.04 and 2.05, it will have essentially everything to satisfy players and mission designers. Dark Radiant is a friendly and stable toolset. Like everything, it has its limits and peculiarities, but things rarely get any better in gaming.

[Nico A.]

team efforts are better spent elsewhere. Missions and more missions - this is what TDM is about.

Completely agree. My only point was that at least me - and I think a lot of other (potential) mappers too - would work way faster if it had the combined mode like DromEd.

 

Of course changing Dark Radiant in this way would be way too much work, but I was just wondering if there already was an editor delivering compatible .maps.

[demagogue]

Spooks explained the bigger problem. Even if you had a .map file like that (and you could technically do it by carving into a giant solid brush in DR), when you dmap'd it, the engine wouldn't like brushes trying to be concave and it'd throw degenerate triangles in to avoid concavity at all costs, and then the dmapping would (allegedly) just disintegrate the rooms into a mush of bad triangles. It's not a DR issue, it's an id4 issue. I guess you could test the theory by carving up a big solid brush into rooms and see what happens. I'm actually really curious what triangle mush looks like!

 

Edit: The compromise version would be some tweaks to DR so that when you draw an "air brush" into the void, it automatically "make rooms" it, and when you put an air brush jutting into another, it knows to cut out the intersection part completely and "make room" the part jutting into the void. That would give you the best of both worlds and, best of all, it wouldn't be that radical of a change to DR. Just make a new "air brush" that has a few new rules like that. And I think using that kind of brush would speed up building in just the way you're talking about, which all of us who've worked in dromed remember. Yeah, make a request for that.

 

Edit2: I'm thinking about how a DR-friendly air brush would work. You'd draw it out like a normal brush and it'd first be made as a "prelim brush" (a dashed or another color prism) that you can resize & move around. Then you hit a key to "confirm" it, and then it follows the two rules, "make room" parts in the void, and for parts not in the void, cut everything on the border & erase anything inside. (You'd need a method to determine if the prelim brush surface is "in the void" or not.) And maybe it leaves a ghost version of the original air-brush, so if you want to make a change, you can select the ghost and hit another key and it "reverts" it back to the "prelim brush" form and, if feasible, also erasing the "make room" parts and restoring the erased intersection parts that are still there. Perhaps the new make-room brushes & erased intersection parts are also left in a ghost version for reversion purposes. Then you should probably be able to kill the ghost versions when you're really sure it's set.

 

With that set up, you could make quick alterations by just moving the air brush around & see how it looks, revert it back, move it, see that, etc, until you like what you get ... which would take ages to do the current way but would be pretty quick this way. I'm liking this idea more & more, if it can be made workable. One issue, it suffers from the same problems as the "cut tool", inviting a mess of triangle splinters to make the cut surfaces.

[Nico A.]

moving the air brush around & see how it looks, revert it back, move it, see that, etc, until you like what you get ...

If the two tests (if part of the ghost brush in void and if part of it is in another brush) can be completely reversed by moving the ghost brush, then maybe the "revert it back" step doesn't need to be done manually? I mean, for instance, if you are are in "semi-subtractive mode", then maybe you see the actual geometry of the map but can only select the ghost brushes. As you move them around, you see how the actual geometry changes (almost) in real time. But only if you exit the "semi-subtractive mode" can you make changes to the actual brushes and the ghost brushes disappear. I think that might still be a little bit better than reverting after every single brush... but I might be wrong. Would need to put more thought into it...

 

which would take ages to do the current way but would be pretty quick this way

Exactly what I'm thinking!

 

That would give you the best of both worlds and, best of all, it wouldn't be that radical of a change to DR.

Can tweaks to DR really be done? I thought that would be near impossible.

[demagogue]

The reverting was just to allow you to make changes, but it's just as well to do it the way you explained, have ghost traces, and if you want to revert back to the ghost-mode after confirming, you just hit undo (cntl-z).

 

The other thing I think might help the process is the equivalent of a paint-fill in photoshop to define void space & brush inner space, so it's not guessing. (Not literally painting it, but the algorithm to define the space.) And then it'd be super easy for the algorithm to know which parts to do make room (in the void defined areas) and which parts to erase (in the innerspace defined areas).

 

DR is an open source program. Just change the sourcecode and recompile. Since the team probably won't work on this, you're better making your own branch version for it. You'd have to study up on the code, but if you're really motivated it's not too bad. There's already code for the make room & cut tool functions, so you even have the base to build from. I'd start with a clone of the "make room" function, make a button for it, & tweak it from there.

[Nico A.]

you're better making your own branch version for it. You'd have to study up on the code, but if you're really motivated it's not too bad.

Why, cool! I might just try this out. Thanks

[Spooks]

Here's how I see the implementation of such a feature. Long post.

 

DR writes into a .map file, in which the geometry is represented by a collection of primitives described by their vertices. Dmap then reads from the .map file in order to produce the .proc - the pre-processed geometry, triangulated and grouped into surfaces. The consequences of introducing a negative brush means that its vertex data has to be recorded somewhere too, much like with positive brushes.

 

If you put the data in the .map file, then you hoist the responsibility of understanding and compiling that data into convex volumes, ready to be triangulated, onto dmap. This is a bad idea since DR isn't used solely by TDM map makers - if we introduced negative brushes in DR then tuned our dmap compiler to make sense of them, we'd be screwing everyone else who's using DR for their idtech4 projects. (This is why I've not suggested to greebo that he put "convert to func_group" in DR 2.0.4, the thing's only going to get fixed in TDM 2.0.4, it's still broken in D3 and other idtech4 games.)

 

So, it's clear you've got to make this a completely DR-side feature, making DR spew an intermediary file containing negative brush info, then compile a final, regular .map file from that. The .darkradiant files already exist, and they hold layer information, so that'd be a fine place to store negative brush info.

 

Then you draw your negative brushes in DR, and they're a DR thing and not children of worldspawn, and at savetime DR uses all those negative brushes to carve spaces and writes the .map file. But when you reopen it you don't really have the original positive brushes, just the carved versions! To avoid this, DR obviously shouldn't be reading the .map file for [positive] map geometry info, just writing into it.

 

So really, you have 3 things to keep track of - vertex information for all positive brushes, vertex information for all negative brushes (and both of those have to be a DR-side ordeal), and then the .map output, which is the final file which dmap can read.

 

You can see at this point you're not using DR to directly edit the .map file anymore, you're doing it behind an entire new level of abstraction. The whole thing is feasible and I could see some actual quality of life improvements coming from it, but it fundamentally changes Dark Radiant - how it stores brush information and how it displays it to the end user.

 

The front-end is the least of a would-be implementer's problems. The most user-friendly interface IMO is to have a toggle (that could be bound to a keyboard button) to work in either negative or positive space, and a special option to select both types at once for layer assignment, movement, etc. The back-end, however, makes for a lot of problems.

 

How do negative brushes interact with other DR features? If you group a negative brush and positive brushes into a func_static, does it carve everything, or just what's in the func_static? Should negative brushes just be their own entity altogether, like the worldspawn entity, but editor only? If you're using the CSG algorithms to carry forth this whole premise I've outlined, how do you make those algorithms not shit?

 

It's a lot of effort that could be better spent on other parts of DR that would expedite a mapper's workflow by a far greater margin. How about DR having the equivalent of func_instance? Or Bethesda's Snap to Reference (ctrl+f "snap to reference" on that page and you'll find it)? I'm not trying to bust you balls or discourage you here, as I said I'm well aware of the benefits of negative brushes. Not saying those features would be easier to put in either - not by a long shot. But in the grand scheme of things there's far more useful features I pine for - substractive editing is pretty low on the list.

[SteveL]

 

how do you make those algorithms not shit?

Exactly... Don't we already have that functionality in DR, in the form of CSG Subtract? And it comes with a hazard warning NEVER USE THIS!!!!!!!! Because it creates millions of brush splinters in its attempt to surround your negative brush with a set of convex brushes.

I don't know how CSG Subtract works, but the actual algorithms that do dmapping are a bit mind-bending. Brushes do not in fact store any vertex information in the map file. Each brush is defined by a set of planes, each plane being defined by an angle (the plane normal) and its distance from the world (or entity) origin. dmap reconstructs where the brush vertices would have been by where those planes intersect.

That's why there can be no such thing as a concave brush -- it's logically impossible to define a concave brush using only planes. The planes that define the cut-away part will have more intersections outside of the concave volume, or in other words, the planes you need to make a concave brush will be ambiguous, always open to interpretation as a bigger convex brush.

It's done that way because dmapping uses bsp trees to calculate collision models and visible models and portal regions, and bsp trees are just a list of planes. By using that format, DR makes sure that it doesn't ask dmap to do the impossible.

The mind bending stuff doesn't end there though. The other weird aspect of all this is that there is no concept of inside and outside for a brush defined as a bunch of planes. The planes don't have any info about which side is the front or the back. Even though it is obvious in DR whether a given point is inside or outside the brush, dmap does without that information. It sets up all brush walls in its model and identifies the 3d spaces (gaps) between them. Then it uses the entities in the map to trace out (flood) the gaps. Any brush walls hit by flooding algorithm are considered part of the map. Any brush walls (or parts of brush walls) not reachable by flooding out from an entity are considered to be in the void and are stripped away before the visible and collision models are generated. That's the stage where the map looks like a subtractive map during dmapping. And that's why dmap fails unless you have at least one entity in the map -- it has no way to label the gaps between brush walls as "inside the map" vs "void".

For anyone thirsting for even more detail , Fabien Sanglard has a good illustrated summary here: http://fabiensanglard.net/doom3/dmap.php

[Nico A.]

Thanks for the long post and the food for thought!

How do negative brushes interact with other DR features?

The negative brushes would instantly lead to adjacent positive brushes. Only in the semisubtractive mode (SSM) would you be able to select the negative brushes, and only these kind of brushes. (But as you make changes to a positive brush, I figure you can't go back to SSM. That would be too complicated to implement I guess, but maybe it could be possible.) So the negative brushes would only be there for the user to handle (when she is in SSM that is), but Dark Radiant would handle the current configuration as if there would only be positive brushes. So back to your question: The feature interaction would be the same, as there are basically no negative brushes (it's only a tool for the user).

If you group a negative brush and positive brushes into a func_static, does it carve everything, or just what's in the func_static?

There'll be probably no grouping while in SSM.

Should negative brushes just be their own entity altogether, like the worldspawn entity, but editor only?

Yes. I guess...

If you're using the CSG algorithms to carry forth this whole premise I've outlined, how do you make those algorithms not shit?

I have no clue whatsoever. I'm not even a real coder, I'm afraud (pun intended). Hell, I even have to learn how to use github.

It's a lot of effort that could be better spent on other parts of DR that would expedite a mapper's workflow by a far greater margin.

For me, this is the main thing that would speed up my workflow. This would also be something that would motivate me enough to actually try it out if I can achieve something. If yes, I think it would be a nice feature that map makers can use as they like. If not - I don't think you've lost a great coder

Also, what'd speed up my workflow significantly (maybe even up to the point where I can release my first map before 2019) would be a preview for entities, models and textures, that lets you view multiple instances at a time rather than clicking your way through. But I think that's far more complicated to do.

[demagogue]

Me and Nico were already talking about those issues. The negative brush would be an abstract DR entity that acts like make-room, subtract-tool, and delete-brush in one, depending on which space a surface is touching, void, brush, or inner (determined by some flood-fill algorithm, eg, from if an entity is in it like dmap does it). For gui purposes, it'd be a ghost brush, with ghost-positive brushes around it & ghost-deleted brushes inside it showing what it'd look like once set. Then you set it and it sets the brushes/subtracts/deletes and all ghosts disappear.

 

The big trouble spot, as mentioned, is the shattering triangles of the subtract-tool part. For that problem, the algorithm for that should start with the "parting curtain" method that mappers already use whenever possible. The function should mostly just be for rectangular prisms intersecting with each other, or anyway rectangular intersection subtracts, where you don't need the exploding triangle fragments. And in that context, it'd be a very helpful tool for making basic rooms, the bulk of all the early base building.

 

Edit. I know one argument is we already have make-room and the subtract functions. One response to this is to flip it and say, since we already have them, isn't it that much easier to combine them into one air-brush function so they're more useful?

[Nico A.]

I don't quite get what a concave brush is exactly. Is it a brush that has a reflex angle (> 180°) on at least one side view? If so, why not just split this brush in two then along this problematic angle?

[SteveL]

Concave means its's got a cavity. If you were to stretch a rubber sheet around your brush to find the smallest shape that can fully enclose your brush, would there be any empty space in there? If so it's concave. A round cake for example is convex. If you cut a slice out of it then it's concave.

 

Your suggestion sounds reasonable. I don't know why CSG subtract has a problem dividing concave shapes into convex ones TBH. Maybe it's a Hard Problem for reasons I haven't got my head around, or maybe it could be improved.