First, just to clarify things: cuts are
not always grid aligned by new method. This is the artifact of a chosen cutter brush (cube, as it seems).
Of course, this problem exists. Brush subtraction could result in much simpler shapes, and could snap the split planes to exising edges. But this new algorithm can't do that: it designed so all split planes intersect at a single point (shared apex of all pyramids victim brush being cut into). So, the only variation possible with this algo is to move apex point to the position where most splits will pass through the existing edges (or vertices at least).
Mattn, improving the algorithm to what you are asking for will require a major rewrite, changing it's nature. Definitely possible, but will require about 10x of work compared to the current version. I think, it will be better if my project newbie enthusiasm
will be directed to the renderer -- which definitely requires a lot of improvement to meet modern standards. Not to mention the bugfixes.
After all, the renderer is what player sees -- not the Radiant.
On the other hand, it is possible to reintroduce old behaviour as a configuration choice. Looks like it does pretty axis-aligned cuts with boxes, and that could be useful. Just fix the code to avoid insane geometry -- original subtract tool was able to create something really bizarre, like 17-faced cube (of which, 9 faces are invisible, and 3 faces are coincident). No wonder ufo2map had problems handling map made with CSG subtract.
Even more, it is possible to do the hybrid tool, which retains the old behaviour for axis-aligned faces, but uses pyramid cutter for all other. Could be a 3rd configuration choice.
These two are very simple'n'easy, and I'm willing to do them if someone makes the configuration and UI code. In case they are requested, of course
Show Posts
Happened to me in skirmish game yesterday.
At least, I traced everything that is called from R_RenderFrame(), so it's supposed to be complete.