That's good.

func_detail_illusionary would actually be really useful to simulate crouching. The real ground would be lower, with a func_detail_illusionary ground a little above. Of course, this would affect monsters too, so its usage may be limited to small areas. 

I don't care much about quicker VIS times; all I want to achieve is phong shading and occasinally minlighting on brushes without taking up additional entity/model slots. Although marksurfaces eventually forced me to turn many of them into func_wall after all.

As for the issue I mentioned above, there's a workaround. As it turns out, phong and minlight also work on func_group, so making the big face a group instead of detail gets all the effects without the PVS problems. Good to know, albeit even more hax... 

Is there a way of increasing the lightmap resolution? 

texture scale is linked to the lightmap resolution. 

LIT2 (see the opening post) supports increased lightmap resolution and we all went round the block with it a few years ago. No clear community consensus formed.

My own opinion is that it's a poor trade off for hugely increased file sizes, and it doesn't even look as good as you'd think owing to losing the soft edges on shadows. 

It could be useful to add a compiler/worldspawn option to set portal brush contents to CONTENTS_EMPTY, because as it is, using CONTENTS_WATER, portals can't be (partially) placed inside of slime and lava. 

By the way, Quake's episode 4 already has maps with underwater portals. So, allowing portals under slime and lava would bring more feature consistency to mappers. 

Used black for its teleport texture.

I think you mean teleport. Portal is something created by vis.

That's not a terrible idea but I think it would serve better as an entity field: _overridecontents 1 or something to that effect. 

Just copy the teleport texture and call one copy *lavateleport and the other one *slimeteleport in your wad file. 

thats brilliant. 

v0.15.10-beta2

I've been working on qbsp, and did a rewrite of func_detail to fix the vis problem. The big change is, func_detail no longer seals the map (which makes more sense anyway IMHO). No more of this! (baker's shot of a way-too-big-PVS from some spot in ad_mountain).

Also, I added a bunch of func_detail variants (illusionary, wall, fence) described in more detail on the release page. Thanks for the suggestions, mankrip, and Spike a while ago.

This is still bleeding edge so it's marked as a beta, and I still haven't fixed the light issue you reported Pritchard. 

I didn't think that had ever cut vis. I know it doesn't in GoldSrc/Source. Was func_detail something third-party FGDs added to Quake? 

Yeah it was something added later to the Quake tools - afaik originating in Quest.

It's not that func_detail blocked vis, but certain setups would cause bogus portals (what negke is reporting in #835) resulting in bogus vis results. 

 

light: styled lights no longer bounce by default, set "_bouncestyled" "1" to enable.

Just want to confirm this means bounce is disabled on id's lightstyles "flicker, pulse" etc.?

Is that set in worldspawn or on the light entity or both? 

Yep, it's for flicker/pulse and also lights that start off and are switched on. The "_bouncestyled" key is on worldspawn and affects all the flickering / switchable lights in the map.

(The first release I did with bounce lighting didn't support having those lights bounce; now they can, but it's opt-in.) 

great. thanks for all your hard work on these tools. 

thanks for -forceprt1 - I was always editing prt file in text editor to load it to JACK :P 

thanks for -forceprt1 - I was always editing prt file in text editor to load it to JACK :P 

about half the size of the Linux and Win64 versions? 

duh! 

I'm still running a 32-bit system, I didn't realize that doubling the bits would also double file sizes. Makes sense. 

would it increase compiling time if i added "_phong_ to my "func_detail" entry in FGD and thereby all my func_detail? 

would it increase compiling time if i added "_phong_ to my "func_detail" entry in FGD and thereby all my func_detail? 

If "_phong" "1" is set on every func_detail there will be a little overhead, maybe 10% slower, but nothing major.

The main thing I would watch for is unwanted smoothing. The default _phong_angle is 89 which might be a bit high (face normals up to 89 degrees apart will get smoothed together). Check with a "-phongdebug" compile and set r_lightmaps 1 in the engine to see what is getting smoothed.