Yeah, what are the tech details on the detail brushes? Do they cast shadows, do they cut into the world, do detail brushes cut other detail brushes, etc? Sounds neat! 

The http://quakeforge.net/ tools also include detail brush support so for everyone playing around with them now, it would be great if you could test that as well. 

there was a reason no-one ever used the quakeforge stuff. damned if i can remember it though 

Do detail brushes split the polygons of normal world brushes they touch?

If they didn't split though, would that even produce a valid Quake bsp? Admittedly I'm not a guru, but I was under the impression that the best we could do in Quake would be something that drastically speeds up vis, but you'd still have to chop all the faces up. Maybe the splitting planes from the non-detail brushes could always get priority, which might reduce the number of polys split.

But ignore me, I don't really know. 

Kinn is pretty spot on actually. Detail brushes still split the world, but they don't cause extra portals to be generated the way normal brushes would. Less portals makes vis much happier - vis gets exponentially slower with the number of portals.

The planes from detail brushes are the last ones selected for splitting planes, so that all the leafs in a detail cluster have the same parent node. Not sure if that really means you get less poly splits, but it seems reasonable that it would help. 

Yeah, you can use any light util - the only thing that changes is the .prt file, so the vis tool needs to understand that. But I will look at adding those options to my light util anyway (-gate, -soft, -softdist, -extra4, -anglesense). 

Oh, I never realised QF had that. I'll definitely take a look. Bill writes nice clean code! :) 

Heh, cool I figured that's how it would work :}

If you're thinking about updating light to use the features in bengt's tool, don't forget "delay 5"! 

Tyrann: Could you add to your Qbsp support for floating point rotations of textures (so for instance, rotating a texture 22.5 degrees doesn't get rounded to 22 degrees)? Frib (or I guess a friend of his) added it to Bengt's modification of TreeQbsp, but it'd be nice to have with your func_details!


Some test shots, showing exactly what Tyrann just explained...

http://i.imgur.com/NHpU9eH.jpg
Here, the red textured brushes are func_detail brushes, and we can see that they still cut into the hull of the world. (the crate in the middle of the screen is a floating cube, world geometry)

http://i.imgur.com/LpQbmQU.jpg
Here you can see that that the PVS does not consider the func_detail brushes, as the floating crate cube is still rendered.

http://i.imgur.com/ajkNDg0.jpg
Here is that same view, except the red textured brushes are normal geometry, to prove that the crate would normally not be rendered in this location.

These detail brushes are good for speeding up your Vis time by simplifying the PVS. They are NOT for reducing r_speeds. 

I see. I was thinking that you'd somehow managed to create a semi-solid feature that is in Unreal Engine. 

Sure, will add that. Should be relatively trivial. Hint and skip are also on the todo list. 

will need to play with this on the weekend! 

Is there a way to put in some kind of occlusion brush in the same way that water used to be used before watervis? 

To keep Scampie's texturelocked trims aligned. 

Is great. Thanks Tyrann. 

This is great news (I do still compile Quake 1 maps occasionally). I will add a link to your tools to my tutorials once they support the full monty.

Actively maintained tools are basically the lifeline for any kind of modding. Thumbs up. 

I'll look into providing binaries for Mac OS X, would you like to host them on your site? 

Thanks SleepwalkR - I was meaning to do that anyway so I've just done a quick build on my ML machine and thrown that up on the utils page. Does that look ok?

Any tips/advice for providing OS X binaries appreciated. I'll hopefully be doing the same for TyrQuake with the next release. 

Will definitely give these a whirl next time I compile a map.

Maybe it's just fantasy, but I'm hoping there is also going to be a map release from you this year... :) 

"After it took 36 days for my map to vis on a fairly decent 8-core machine I knew it was past time that we had something like this for Quake."

How long does your map take to vis now? Have you detailified it yet? 

Maybe it's just fantasy, but I'm hoping there is also going to be a map release from you this year... :)

I thought the same. Might go replay moonlight. By coincidence was looking at OUM the other day as well. 

...but working on it. 14k+ brushes! :) 

* Brush models (func_ entities) can have a minlight value so that there is no solid black surfaces. It is easy for a secret door to have a solid black surface on the opening edge, which is difficult to get rid of. No one wants to minlight a whole level but certain entity types could benefit from a minlight boast.

* Phong Shading on grouped brushwork. This would be awesome for terrains where the lighting is consistent across surface edges. It is difficult at the moment to create terrain wall sections without obvious light seams.

* AI clip brushes, a surface that is invisible like clip but can block AI/Players. At the moment all floor gaps need func_wall entities so that AI can walk across the gaps properly. For some reason clip brushes are not in the clip hull that the AI movement code uses. 

* AI clip brushes, a surface that is invisible like clip but can block AI/Players. At the moment all floor gaps need func_wall entities so that AI can walk across the gaps properly. For some reason clip brushes are not in the clip hull that the AI movement code uses.

That's an engine issue I believe. 

If we even got the first 2 things on Socks wishlist that would be incredible. Is that even possible though?