If you can rotate the squares or not. 

how to mimick what the human does to mop up after a dumb CSG subtract operation. That's why I'd like to see what you guys do. 

to chop a brush up with perfectly optimal geometry if you want to effectively punch a square hole in it.

CSG subtract is not necessary in that situation at all. 

When I found it handy for was making buttons. I could build a button brush, embed it into the wall and subtract it. Now the button has a nice recess to move into. 

Although I will agree that Merge would get used a lot more often than Subtract so if one needs to be done first, Merge would be the choice. 

With regard to what Qmaster said about the grid vertex snapping.

I believe the editor should have a preference for this.

I think it's similar to how I could do this in Quest.

In Quest, the config file has this option:
# ---------------
# snap_to_int <x>
# ---------------
#
# If set to 1, Quest will snap all vertices to integer values upon save. This
# should prevent vertex drifting. This is only used with the old map format.

snap_to_int 1

---

There are couple more settings in the config file that you might find interesting. See quest.cfg: http://pastebin.com/7CCDm8R6 

Kinn, why would someone want to use the slice tool 4 times to cut a square, when CSG Subtract can do it in 1 move. 

My point is that we don't need a stupid "csg subtract but only for square shapes" thing, when everyone can produce the equivalent geometry themselves in a few seconds without that feature?

Either make a proper csg subtract tool, or don't make it at all. 

Will be cool because the code can be used for stuff like this:

https://github.com/kduske/TrenchBroom/issues/276

That was rebb's idea, and it's absolutely great. 

SleepwalkR,

Here is video of me doing CSG Subtract and I show the problems, and explain what I would've preferred the result to be.

http://youtu.be/7P1wS5INeAw 

The problem is inventing the algorithm that produces optimal results when csg subtracting arbitrary brushes. 

Does look pretty cool, and more valuable than subtract. 

This is not merge exactly, but it works in a similar fasion. The idea is to select a couple vertices (either by selecting brushes or by selecting faces), then creating the convex hull of those vertices and creating a brush from that.

If you select a couple of brushes which form a convex shape to begin with, you have CSG merge. The other cases are shown in the images I linked above. 

Is mentioned on github as well - is this in/gonig to be? 

Not sure what that should be called though :) 

Here's another video of CSG Subtract, doing arch window, and what I do to clean it up, and I explain what I would've preferred the result to be.

http://youtu.be/7-x47KvgL9U

Again, the problem is programming the logic, math, magic to be able to do CSG Subtract like this.

Honestly, CSG Subtract is too much magic for me to expect from a new editor anyways. I suppose you'd rather focus on more important things/features. 

Again, there are questions as to how the resulting brushes should be shaped. My current idea is to extrude the outer faces and chop them off at their formal position.

It's basically this feature applied to each face of the brush:

https://github.com/kduske/TrenchBroom/issues/418 

is a response to ijeds question about CSG hollow. 

See, now hollow is something I've never seen a use for. Does that get a lot of play for some people? I know it's good for "my first room" tutorials ... :) 

Apparently some people use it. I'm not a fan of any of the CSG operations, but if I'm going to support one, I guess I should support the others as well, esp. as hollow is quite simple compared to subtract. 

I use it a lot for speedmapping / testmapping and sometimes for blocking out.

When it's time to put an area together properly I usually delete the resulting brushes. 

The more predictable features (and therefore, hopefully the ones that are easier to implement) tend to be the most valuable.

Complex CSG functions have a bad rep for a reason. It doesn't mean they can't be well used though.

What I'm driving at is that the value of a feature is a result of balancing the pros and cons, not one or the other.

And both those should take into consideration things like 'time to implement' and 'will it be a bitch to get it right'. 

"The fun to be had for the programmer", which for such difficult problems, is plenty! 

True.

Here's some of my own coding stuff, may be of interest even though not editor related.

http://spiney.me/schism/forum/index.php?topic=303.msg3743#msg3743 

I have noticed that certain actions in 1.04 now take considerably longer than in version 1 (I updated the .exe to see if they were functionally different, I have now reverted back to the original release). The actions causing slowdown (that I could find) are duplicating items, alt+clicking to copy textures and making new brushes. I think it may be a consequence of editing a map from version 1 in version 1.04. Maybe.
If you want to check it for yourself SleepwalkR I could email you my level