Detail Brush Support for Q1

Trying to figure out detail brush support for Q1, but not being a tools person it's quite a pain. Now, I know that the stock reply here is "the QuakeForge tools support detail brushes", BUT:

QuakeForge detail brush support was never actually tested. Otherwise how in the hell did this get through?

  Code:

      face_t     *f;

      for (f = brush_faces; f; f = f->next);

      f->detail = 1;

... AND ...

The QuakeForge tools use a different .prt file format.

So in other words they can't be trusted for this purpose and even if they could be they're useless anyway. Not portable to other QBSP tools and/or not usable by other Vis tools, you see.

Anyone with tools experience willing to chip in?

Detail brushes are brushes which are like normal brushes but simply don't take part in vising, is that right?

I think that means that a separate BSP step has to run in order to have a BSP (leafs etc) that corresponds to the detail-less version of the map.

But Q1 visibility info uses the leafs of the rendering hull (hull 0), so you would need to make a corresponding map between the hull 0 leafs and your detail-less BSP leafs, supply this mapping to the vis step, and use it after doing the vis.

So I'm thinking without the Q2 cluster system, detail brushes won't make much sense for Q1.

What's the difference between a detail brush and a brush entity, then..?

What about the Quest tools? Or did the QF ones took the code from them?

What's the difference between a detail brush and a brush entity, then..?

A detail brush can cast shadows, a brush entity can't. A detail brush doesn't count against MAX_MODELS.

Detail brushes are brushes which are like normal brushes but simply don't take part in vising, is that right?

I think that means that a separate BSP step has to run in order to have a BSP (leafs etc) that corresponds to the detail-less version of the map.

But Q1 visibility info uses the leafs of the rendering hull (hull 0), so you would need to make a corresponding map between the hull 0 leafs and your detail-less BSP leafs, supply this mapping to the vis step, and use it after doing the vis.

So I'm thinking without the Q2 cluster system, detail brushes won't make much sense for Q1.

My thinking is that since most Q1 BSP tools already support a form of detail brush - translucent water - this should be just a logical step forward from that, although like I said, my tools knowledge is limited.

I don't know if it is possible to have a leaf which is actually solid but pretends not to be for vising. It is no problem for the collision hulls, but it may be a problem for the rendering hull, which is used for hitscan and missile collisions.

There is a single "solid leaf" in a Q1 BSP used by every solid face in the rendering hull, and I think lots of pieces of code (in engine and tools) will assume there is never a real leaf behind a solid face, and fail in minor or major ways when encountering a real leaf behind the solid surface.

BTW it would not be hard to modify a lighting tool to allow brush models to cast shadows, although it would slow down the lighting process a lot.

I guess making func_walls with a certain spawnflag (or func_details) able to cast shadows would be an acceptable compromise...

they would still count against max_models, but that's OK since protocols like 999 allow a large number of them.

I think e1m6rq has like 600 models, so a really large map would need four times that or something. 4096 as a limit maybe.

I think that the wise person would probably wish to makestatic them too otherwise they'll be running thinks on the server and going across the network.

Anyone tried the Quest tools? Claim to support detail brush
http://quest-ed.sourceforge.net/dl/index.html

I've looked at the source code and it's quite obvious that QF was ported from Quest (although Quest is missing the crash bug in LoadBrush). Same incompatible changes.

I'm reckoing right now that andrewj's suggestion of modding the light tool, together with a makestatic, is probably the sanest way to go.

I guess making func_walls with a certain spawnflag (or func_details) able to cast shadows would be an acceptable compromise...

Spawnflag would be bad, there are a limited number of them and this could interfere with some mods.

Better to add a new key; perhaps call it "_castshadow" (by convention the quake engine ignores anything starting with an underscore.)

I would actually want two keys, "_worldshadow" to cast shadows on the world, and "_selfshadow" to cast shadows on itself (a moving object shouldn't cast shadows on the world, for example, but would still benefit from self-shadowing if the geometry is complex.)

BTW this has been on my tools wishlist for a long time.

[Just reading thread enjoying the deep thinking discussion going on here.]

I like the idea of adding two keys but - in common with the spawnflags idea - it works on the assumption that the default behaviour is the way things currently are. Nothing wrong with that in principle, but it does defeat the purpose of "detail brushes" a little, which is to create a class of object which is to all intents treated as if it were part of the world by default, but is ommitted from vis testing.

So here's how I'd propose it working:

• Have a func_detail entity which is by default makestatic and which casts shadows on both itself and on the world.
• Add the keys as options for other object types and let the mapper decide.

That way we get the best of both. In cases where the mapper knows that an object will never move it can be made a func_detail and everything will be looked after automatically; no need to sweat over whether or not you remembered or forgot to add the appropriate keys. In cases where the mapper wants a moving object that can be done too, and the mapper has flexibility in deciding how it's lit. In both cases we get to accelerate vis times and the worst case for light times should be no worse than if the objects were part of the world anyway.

99.9% of "detail brushes" are going to be static geometry. Ignore case of moving detail brushes?

99.9% of "detail brushes" are going to be static geometry. Ignore case of moving detail brushes?

I thought we gave up on detail brushes and started talking about brush models casting shadows as an alternative.