Oh! And a huge advantage, since you have rotational texture locking, is that using this system you can do great stuff like work on a crumbled building or something in a file. Then include that as a func_instance in your level but now you can tilt it 15 degrees or whatever you want.

So, in the level itself, the building is tilted and awesome looking. But your source file is axis aligned and easy to edit.

We'll know to stop asking for stuff when you start screaming. :P 

not having to include the actual "god parent" inside the compiled map sounds better than quarks way (it does have prefabs too actually, but that never worked for me). but having separate files for the source is half nice (since sharing prefabs is easy), half bad (since you must make sure you have all the files or you won't be able to build correctly). 

We've actually experimented with that - I got a func_door_model working, which could reference a .bsp - the idea being that you use them all over the level without exploding the model limit.

We also got misc_models doing the same job.

I spose it could work as a prefab too.

Nobody got excited about it so it stayed as it was.

Problems with this are collision and lighting. Collision needs to be handled in Qc and lighting in engine. We got both of those reasonably functional.

It becomes more of a systematic organisation problem than anything.

The two desirable features for an editor would be a fixed format - as Willem describes you double click to open a prefab .map and all of such must be called blah_prefab.map and the other one being showing the external file in editor.

Food for thought. 

@SleepwalkR, what willem describes is pretty much what Q3 has been doing for years. Create brushwork or models in separate map, compile into ASE file (text format++) place in map as many times as required. The compiler takes the model/map object and compiles it into the map at specified points.

Also you can rotate and scale the model in any direction and something that I find really useful is that you can remap the texture to something else and create sub-model versions. (Useful for creating additional versions for variety reasons, same model different skin etc)

Not having this ability in Q1 is strange to me, something I use all the time in Q3 because I like to rotate stuff to any angle and maintain texture alignment. I always think of level design nowadays as prefabs and set pieces. Manually clipping the instance afterwards is easy. It is rare for a instance to have to be exactly clipped, rough outline can do. 

sock ... If it's being compiled as brush work anyway, why the conversion to ASE first? 

Not sure why, but the ASE model is setup ready for the compiler as a triangle stripe. The best way to describe it is pre-compiled model. The only drawback is that anything touching it has to be align correctly otherwise there is sparkly lines on certain video cards.

The compiler assumes the ASE model has been cut up into triangle surfaces already which sort of makes sense especially if you are dealing with 100s of models. Why waste the final compiler recalculating the prefabs over and over. 

It doesn't have any support for containing meshes.
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.

This is perfectly fine in Q3 where you have the detail geometry separate from the structural geometry that vis is calculated from. 

Sure, but maybe you can make a pillar and stick to 90 degree rotations when you prefab it.

Besides, people do crazy crap with Quake1 all the time. :) 

Maybe I don't understand it correctly, but groups is no problem in standard map format. See how Quest (and possibly WC) does it: group information is stored in comment lines before each brush. This is sufficient for normal use, and much better for compatibility reasons. Func_group entities require additional editing and may be an unnessary source of conflict.

No idea about instancing, but wouldn't it be possible to make it work in a similar way? Editors without support would just disregard the comments, but the brushes remain in the main map file. 

I like the idea that Willem outlined above: Create instances in extra map files which can be opened separately, and store instances as entities. Those entities would then contain the following information:

- reference to map file where the instance was stored (relative path)
- translation
- rotation
- scale
- texture remappings

I would supply an additional program that you would run before qbsp that replaces the instances with the brushes from the original map files - then you won't even have to change qbsp at all.

The main problem I see is that this opens the door to creating all sorts of qbsp compiler problems due to rotation and scaling of instances. But as others pointed out, this is a risk associated with Q1 anyway.

Good stuff, keep the ideas coming! It'll be a while until I can implement them, but I'm keeping all this in my to do list. 

well, it's your program, but i don't like external instances at all.

you'd have to open up the external file, make changes, then load up the actual map and look, then go back in the external file...

it would be better if everything is contained in one map, and you can edit any of the instances and those changes will propogate throughout. the instances shouldn't be read only.

this way, if you're in an one area, and you suddenly realize your pillar sucks, you can change it on the fly and see how your changes affected other areas.

HOWEVER
if you build in a method to change external map files right in the current map then that's fine. i'm just against having to open up extra files and such.

Finally:
maybe consider your own format? as long as you have an export option, it would be fine... like flattening a multi-layer photoshop image into a jpeg or something. 

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.