So there is a known issue with visibility mechanism in SOFTWARE that of course we all know about (if the map is too big space it becomes grayed out, etc...) part of this issue is the fact that you are able to see through some kind of doors using software.

Using basic doors such as in E1M2 this is not a problem. But on some custom levels (such as my and distrans recent map) with custom doors, this becomes an issue.

The reason for this post is: I am searching for people who know this issue, and know how to fix it so that SOFTWARE client users are not able to see through doors when looking at them from a certain angle.

The map is available here: http://qw.quakephil.com/maps/shrine20091006.bsp

If you can fix this by editing the entity hull in the .bsp that would be awesome. If not, let me know, and I can give you .map or .qkm from which you can easier rebuild the .bsp...

r_maxedges 3000

Default is 2000, the map seems not to exceed 3000. Your map is too open and detailed (or full of brush waste ) for Quake's old limits. Always map with r_speeds 1 to get an idea of that.

Load the map in Darkplaces and do "r_showdisabledepthtest 1" and "r_showtris 1" to get an idea why it gives trouble. Basically the whole map is rendered at some places because doors do no VIS blocking.

I assume you did VIS with -extra4? (edit: Seems like it.)

I didn't do the final vis, distrans did. I'll ask him...

r_maxedges is a client setting? How can I make sure everyone honors that?

Does this mean you can "cheat" and use r_maxedges 1 or something like that, and see through doors? Because reppie said he loaded that map in his software and was able to see players through doors...

You can use ezquake's powerup shells as a wallhack too.
Frankly, if I was going to cheat, I'd download an opengl wallhack and use that (actually, I'd probably write one myself, but that's not the point. tbh, I already made one for ezquake's sw renderer, that passed f_* checks too).
My point is, if people want a cheat, they'll want it on all maps, or they won't really care that much.
If the door is completely invisible, then the people who can see through are going to give away thier position when they try shooting through it when its closed, which might be funny.

r_maxedges is a cvar found in sw-rendering engines, and only in software rendering engines.
You can set up a server or mod to stuffcmd requests to set it to something higher, but if you spam it you'll annoy GL users, and if you don't spam it then the SW user can just add it on to their movement binds.

Ok, as I suspected

Thanks for the valuable feedback thus far.

Is there some way to make the map "fit" under the default 2000 value?

bend it - turn your long corridors into an L shape.
convert some details into a func_wall or two, or move them by 1 unit away from the wall, so they don't produce extra edges.
as spirit said, use an engine that'll show you the actual triangles, and remove such areas from the view of the rest of the map.
don't use csg subtraction to cut through more than one brush at a time.
or try a different qbsp.

OK, I've just finished the start level for Tronyn's "arcane" mod and shipped it off.
I'm now officially back on the "make Shrine playable in software" track.
Quite a challenge given the open layout but let's see how I go.
First thing will be to simplify the interior catwalks i.e., no gaps to the pillars.
Next cut back on the secondary slime pits, and add back detail via a change in floor type.
Third, move the "globe" console in to 128 from the door (in an effort to block some vis) and extend the other ground level blockers by 64 each.
Fourth, take the roof off the central structure and rebuild up to the sky block (sky textures break vis into far fewer volumes than straight textures)
Fifth, simplify the lifts and lift wells, which in turn will imply a simplifying of the catwalks above.

If that ain't enough then:
Sixth, add a right angle to the vis blocker near the lightning gun (may need to then move LG slightly)
Seventh, reduce the size of the teleport destination alcove
Eighth, add internal vis blockers to the upper level of the central structure (may or may not effect gameplay too much, needs to be tested)

Enough talk, I go to remake a world

So... the infamous DM3 RL area glitch is still active when using software clients? I thought that newer clients had that corrected. But then again, its is not unusuall for me to be wrong...

I use
r_maxedges 5000
r_maxsurfs 5000

If you try to set values below 2000 client will use value 2000 anyway.
It makes sense to increase value from 200 to at least 5000 because almost nobody knows about these variables.

OK, just sent the rebuild to phil. I think I beat the problem.
Only one major change required, had to get rid of the LG side lift.
Total area of the map drastically reduced.
Anyhoo, we'll see if phil's software buds get the same issues.
Fingers crossed.

:-)
Back in the good old times with my Pentium 3 cpu (which i used to overclock) this bug was on all maps no matter what r_maxedges and r_maxsurfs was set to
Wallhack on dm3 was great seeing from RA-top to quad and to YA-quad