I'm trying to avoid this as long as possible. I'll try the different options once I start with this feature... 

@necros, if you want to keep tweaking instances to fit every situation then you are thinking about instances the wrong way. They should be fixed/readonly because they are an object you want the same in multiple areas. If the instance doesn't fit a situation, create another or tweak the surrounding architecture to fit.

Instances are a faster way to work, you don't need to tweak every pillar in a room, just instance one pillar and copy and paste. Variety can be added later with the reskin option. Instancing is about blocking out a room with prefabs and then going back adding detail where it is needed. Plus with the rotation and scale options that should be plenty of variety. 

if you want to keep tweaking instances to fit every situation then you are thinking about instances the wrong way.

huh?
the whole point is so you can make something and later change it and all the instances reflect that change.
that's what i was saying in my post.
if you had pillar1 used in your entire map, you might be making a new room with pillar1 and decide you want to change pillar1 to better suit the new room.
you do that and now you can check how the new pillar1 looks in all the old areas.
if it sucks, yes, you make a new pillar2, otherwise you keep the changes to pillar1. 

Having arbitrarily rotated geometry all over the place in Q1 is a bad idea because it will go on to make a mess of the bsp tree.

Is arbitrary rotation any worse than if someone just went a bit hog wild with the 3-point clipper? I mean it's just planes at funny angles surely, which is all the 3-point clipper produces... 

yes and no...

if you use the clipper so that the vertices of the edges it's creating are off the grid, you will probably get some rounding problems, the same way as if you just rotated a brush but didn't fix vertex positions.
but this doesn't always happen. sometimes off grid vertices don't bother the compiler at all.
i'm not quite sure why though, sorry. 

Yeah, but I think focusing on this is a mistake. Yes, people can create bad geometry with an instancing function. So what? :)

Solution : "Don't do that" 

I have been experimenting with turning off netradiant's "snap planes to integer grid" option so the plane coords get written to the .map as floats, then taking a multi-brush structure, rotating it at a funny angle, then compiling with aguire's txbsp, which handles floats in the .map file.

Results are pretty good so far - faces get merged on the rotated stuff where you expect them to, I can't see any cracks between the brushes, and I can't see any visible downsides yet. That said, I have not tried this on a large scale. 

willem: yes, that definitely is a case of garbage in garbage out. and certainly no reason to restrict the power that a full on instance system would provide. 

There isn't really anything wrong with vertexes being off grid, since vertexes are never stored in either the map file or the bsp.

In the map file the planes are stored using three floating point vectors that mark points on the plane, these do not necessarily correspond to any vertexes.

In the bsp file the planes are stored using a floating point normal and distance from origin.

All the problems that come from building off grid come from I guess weird rounding errors in qbsp that doesn't try to do any sanity checking, or that if you have lots of planes in any possible direction there are going to be lots of splits and cuts and whatever. The algorithms for expanding the clip hulls seem to really get messed up with wobbly architecture.

Ninja edit: Looking through the source for the latest version of qbsp I've got, it looks like someone in somewhat recent times changed the internal representation of map file brushes from integer vectors to floating point vectors. This might explain why everyone from old of have been having trouble with off-grid brushes; the old compilers didn't really support them.
Does anyone know anything more about this and can confirm/deny? 

of course vertices are stored in the BSP! How else would Quake render triangles? It certainly doesn't compute the vertices upon map load. 

I'm kinda confused and I don't really know where I was going with that... 

I would give my firstborn for someone to implement detail brush support into the quake compilers, so that we could all rotate, butt random things into things, and do whatever the hell crazy geo we want and everything will all be hunky-dory. 

something about the quake engine/bsp format means that quake 2/3-style detail brushery is impossible on a fundamental level...? 

detail brush support is a bounty http://www.quaddicted.com/quaddicted.com/bounties and still waiting for a loving coder after 2 years or so. 

when TB is released and has all the features in the to do list, I'll go and take that on ;-) 

necros - are you using an editor that can write non-integer coords to the .map file - or does it snap to ints? In netradiant I have recently turned off the "snap planes to integer grid" option because to make a few of my thin trims flow perfectly around curves I've had to go down into the 0.5-unit grid on occasion. I've seen no ill effects so far at all...

After all, as czg says, modern bsp compilers (in my case bjp's txbsp) read in the plane coords from the map as floats right off the bat, and immediately convert them to a (normal, distance from origin) format anyway. 

I tried one time to add detail brushes but after spending several days wading through the QBSP source with minimal success, I dropped it. That code is a ridiculous mess. :) 

http://forums.inside3d.com/viewtopic.php?p=34311&sid=65be7bbb6be9ef5c76e22e78f6019544

about detail brushage in Q1 - no real progress at the end but some interesting stuff to look into maybe. 

kinn: that might actually be the issue.
i'm thinking of trying to swap over the netradiant. 

If you still use qed3.1, the preference option "Use Brush Float Precision" writes brushes as floats in the map file. 

no, that thing is crazy broken.
the visual part of the editor is fine, but it saves as (badly) rounded coordinates which only show up either compiling or reloading the .map file. you end up with micro brush-misalignments everywhere. 

I like the way willem describes the Valve func_instance. That sounds like a pretty simple and foolproof way to do instances to me. No extra file formats, no modifications to the compile tools required, and the models can easily be built axially aligned and later rotated.

Instead of making an external tool, you could just have an option in your map export like "write instances to map". Which doesn't let you, or at least warns you if you try to save the map over itself. Maybe the concept of .map export is alien to you because you are using standard formats, but Worldcraft uses its own format and so has a map export function, which allows you to export visible objects only etc. That's pretty handy by the way...

Then again, a little program that sits in your compile batch file and deals with the instances would be fine too I guess... maybe better, I dunno :)

Regardless of whether you later rotate your instances or not (I would personally choose not to and make special rotated instances unless it was an instance of a func_wall or other solid_entity) it would be a brilliant feature to have. 

Sorry, why would you not rotate your instances? 

I'd rotate 90, 180, 270 for sure. Other angles I'm not sure... it really depends on whether I start getting errors or not. If I was just instancing something simple like crates, and especially if they were func_walls, there would probably not be a problem, however, with more complex geometry, and especially if it has to fit together with other parts, then it might be better to just build manually. I guess I'd need to test it to see how well it worked before saying for sure if I would use rotation at angles that are not multiples of 90. For light fixtures and simple things it would probably be awesome win win win. 

that's what willem was talking about earlier. just because it could cause errors is no reason not to include it.
it's like the carve function. it can be dangerous if misused.
if you're finding your rotated instances are blowing stuff up, you'd consider different methods.