In a world of quake bushes it is essentially a clip tool. The edges are planes intersections, you cant have overlapping planes of the same brush. 

This is why I said that it wouldn't work in TB as it's currently coded because the added edgeloop would be optimized away the frame after it was created. The only way edgeloops are useful is if TB will leave the brush alone until some point when the user "commits" the change.

It's probably more work than it's worth, to be honest.

But it's not a clip tool. :) 

And yes clipping is different, but it serves the same practical purpose. 

flipping edges would be interesting, but i'm not sure how that could be done in TB since each brush exists on it's own independently of it's neighbours. 

You guys have to remember that I'm not familiar with any 3D modeling package ;-) 

Basically, if you have a quad broken into 2 triangles, edge turning turns the quad so the triangles from the other corners.

So

|/| becomes |\|

Useful for correcting shading and lighting errors on 3D stuff. 

Since TB merges coplanar faces automatically, it doesn't seem to be useful. 

@ the extrude image: Yeah, that was about what I meant. Pull the new brush out along the face normal. Usually followed by moving the "new" vertices to where one wants them, then extruding again (typically used for quickly blocking out shapes, like for example curves).

Edge loop is clip:

Not quite. In terms of brushes, it would do much the same thing, but clip isn't as user friendly or intelligent.

If you can make the clip tool able to do multiple parallel clips in one go, and intelligently choose the clipping plane according to the position of the mouse cursor and keep all the new brushes after the clipping, and let you slide the clipping plane(s) along the brush with the mouse, then it might get close.

slapmap: Anything that speeds up the workflow is a good idea, IMO.

It's up to Sleepwalker if he considers any of this useful, of course.

Regarding edge turning, it would probably also give the mapper some control over which way the quads are split in the BSP process. For outlying terrain at least. Smooth triangle strips, all tris going the same direction, render faster, afaik. But then, inside a complex map, this wouldn't be enough to control the splitting, of course. Now if you had triangle terrain and you turned it into detail brushes, then you might be able to influence the splitting. 

Sorry, yes it's what Willem said, however, there is an application for it in TB.

You have 2 brushes with 2 adjacent 3 sided faces forming a 4 sided surface. The 2 3 sided faces are not coplanar.
You want to change the split between the two brushes while preserving the position of the vertices: http://necros.fov120.com/temp/trenchbroom/edgeTurning.jpg 

I think this would be useful on a terrain mesh. Using it would flip the dividing edge between two triangular brushes, which allows you to smooth out surface geometry of a terrain without adding more tris, but simply by optimising the flow of the edges in the mesh.

http://openmesh.org/Documentation/OpenMesh-2.0.1-Documentation/mesh.flip.png

I often do this manually when modifying terrain in Worldcraft. Terrain is about the only place I think I would use it though. 

yeah, it's of somewhat limited use, but where it is useful (terrain), it's powerful.

so it's kind of a toss up really. 

I would definitely like edge flipping. I used in WC also, I can think of more applications than just terrain (though admittedly this is the primary function). 

TB, the clip tool is already pretty smart at choosing a clip plane even if you have only one clip point. And you can split brushes with it, that is, keep both sides. 

Is really good actually, I didn't even use 3 point clipping at first because I never really used it in WC but I'm getting into a good work flow now. 

Yep, clip tool is nice. Clip, clip, and you already have a 4-piece/piece of terrain. Duplicate, duplicate, etc. and you have land of terrain. Drag edge/vertices, and wallah!

FEATURE REQUEST:
For light entities, draw a faint lined circle around the entity in the 3d viewer. The circle is as big as the "light" setting of the light entity. If light = 300, then circle is that big. These circles can be turned on or off.

---

SIDE NOTE:
Double check that the entity panel has the stuff in it from the .fgd or .def file. You know, it shows the description and the available keys for you to use, for that particular entity you're creating. 

That would be a nice feature. Even nicer feature - light simulation. 

To add to deqer's idea, having the color/intensity of the light show in the center. 

Light value visualized by circlesize or just the digit + color.
Only if selected..
And light simulation, what a candy that would be! 

'visualization spheres' or whatever are rarely that useful in all the editor's I've used them in. I think the devtime making these should be work toward a proper 'lighted preview mode', with the spheres used in the interm, and as the basis for doing the shading.

To do spheres right, you are going need to implement detecting all the different 'delay' and 'wait' settings. And spotlight cones. I feel if you're going to do all that, it should be on the road to shaded preview. 

you�re probably right, since one cant tell surely the amount or value of light by the size of a sphere.
Shaded preview therefore seems the better approach, and the more elegant either. 

a good 'lighted preview' mode would be amazing. 

Not sure if it's possible, but maybe the programmer can use a pre-made script that already does live rendering of lighting when adding lights, similar to the editors used for Quake4/Doom3.

According to this page: http://icculus.org/gtkradiant/developers.html#gamepacks the GTK Radiant 1.5 release was the editor used for those games.

It's open source, so, if it's the same as TrenchBroom, maybe you can grab the code from there?

Basically, soon as you add your first light, the entire map turns black, because now it's live rendering lights, and only light is shown on the walls from the lights in your map.

Anyways, definitely would be candy. Probably too much to ask for. 

It seems like alot of work, but pre-baking the lightmaps to brush faces seems doable no? The source to Light.exe is available, I'm sure it's not so simple, but isn't it possible to adapt it to bake lightmaps to brush faces instead of a completed bsp?
Would be pretty nice, you could pre-bake your whole map (would be longer than light maybe, since no faces are culled at that point), and then maybe have options to only bake selected lights/brushes to update pieces you're working on...

But yeah, I'm sure it's not a simple feature to implement. 

Iirc realtime lighting preview IS a far goal for TB. 

be just an approximation of Quake's lighting model implemented as a shader. I don't think it's feasible to compute the lightmaps using light's code. But I will surely look at the code so that I can approximate it as closely as possible.