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. 

I was saying it was an awesome feature and I would use it, but perhaps not be too comfortable just rotating everything to 12.7784 or whatever in all axis and expecting things to be fine :)

Then again, I've used Worldcraft forever and it does not support floating point coordinates and does not do any brush validation, so although it gives you a little bit of flexibility, you have to be vary careful or you start getting all sorts of errors and have to open the map in a text editor to fix things that are broke (not due to rotations, but other things like clipping to get a brush with 0 faces... OMG! Duh!)

Anyway, I'm really looking forward to getting my hands on a windows or linux build of trenchbroom at some point.

SleepwalkR: ould I ask, what is the map in the trenchbroom screenshot here: http://kristianduske.com/trenchbroom/images/screenshot.jpg Are you making something with you new editor? :) Also, are those rocks just manually made prism-soup or is there something fancier going on? 

what is the map in the trenchbroom screenshot here:

http://www.quaddicted.com/reviews/ne_ruins.html 

I am too busy with programming the editor, but I'll get back to mapping eventually. The stuff in the other screenshots is a map I've been dabbling with, but that's on the back burner until the ports are done. 

This is a real simple one:

a tool that lets me define two points, then both draws a line between those points and tells me the length. :)

also, a tool that will let me display an arbitrary sized sphere might be helpful as well. 

Quest had that, very useful. Probably even more so in an all-3D environment. 

just occurred to me:
in addition to arbitrary measurement, it would be nice if there was a toggle that would display a line between two selected entities (or last brush in a bmodel) along with measurement.
bonus if it does that for more than 2 selections (but you might want to cap it if you selected like dozens of entities)