Big part of why Trenchboom looks interesting to me is because it has the modern styled 'all in one 3d window' approach as opposed to multiple fiddly panes 90's set up. 

I'll really have to try it out and see. I like 2D viewports but that might just be because I'm so used to them. But I use them in UnrealEd, 3D Studio Max, etc. So ... I feel they must be useful. :)

Would like to play with it though since it's not just REMOVING the 2D viewports but rather it was designed to not need them. 

That's a very interesting idea that I hadn't thought of yet. I don't see why this wouldn't work. I guess the greatest problem is that it has to survive map save / load cycles and it'll be hard to stuff the additional information of what was instanced from what into the map file.

I'll keep it in mind. 

You could create a second file that goes with the original map file that includes the extra instances. Personally I would prefer if you could use a standard prefab format like ASE for example. Only downside to a prefab format is the compiler would need to understand them as well. 

sleepwalkr:

it's worth mentioning that aguirre's qbsp compilers (really, the only qbsp compilers worth using) support the -group switch which turns anything in a func_group into normal brushes at compile time, so you could maybe use func_groups and attach additional info with comments 

There's the bsp2 compilers, based off AguirRe's but supporting the extended formats.

Maybe additional data could even be incorporated inside for things like instancing. 

Ideally, and this might be pipe dreaming, but if you could do what valve does with their func_instance entities ... that would be fucking AMAZING.

Basically, you build your instance in it's own MAP file at the world origin. Then in your real map you add a func_instance entity and tell it which filename to reference. It draws it in the world in a different color and you can duplicate it as many times as you want to.

To edit the instance, you just double click it and it opens up that file in Hammer. Save your changes, flip back to your level, and all of the instances have been updated.

At compile time, Hammer copies in one copy of that file for each instance in the map. Done! Then the tools don't have to change and everything is clean. 

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.