I agree Baker, the only problem with vis, IMHO, is the thing where certain uses of func_detail can cause vis to see through your map where it shouldn't. I'm not sure exactly where the problem lies (qbsp or vis) but I'm sure it's fixable.

Unless the problem I mentioned leads to exaggerated PVS in AD maps in a lot of places, vis is not really to blame for large demos in AD and the large unreliables, that's just the particle system based on entities and lack of use of static entities combined with protocol 666. 

Yeah, my main complaint are open spaces. I know how to optimize vis for indoor maps.

I did hedge maze and of course everything is rendered, because of open space above it... I'll have to add some obstacles to separate sectors better, or try some hint brushes, but I think hint won't help in this case.

Best option would be occlusion culling like modern engines do, but of course it's impossible with BSP.

Anyway thanks :)

PS
Btw. how different is Q2's VIS? (except doors blocking it) and how much we can borrow without a need to upgrade BSP ? :D 

ericw, you've done awesome work with the tools so this isn't directed at you. It isn't your responsibility to fix vis. You are a volunteer. This isn't a reflection on people that do the great work on the tools.

But yeah ...

vis is certainly to blame. It is supposed to block faces and entities from being drawn. That includes things like AD particles.

http://quakeone.com/markv/media/ad_mountain_r_lockpvs.png
http://quakeone.com/markv/media/ad_mountain_r_lockpvs_directq.png
http://quakeone.com/markv/media/arwop_roman1_r_lockpvs.png
http://quakeone.com/markv/media/r_drawworld_0.png

/I don't like thinking about it because it is very disappointing. Nor do I seek to bring it up. Kreathor brought it up, haha. He's the bad guy.

Dead horse, I don't wish to beat it. I won't be bringing up, and I didn't raise the topic this time either. 

Nor do I seek to bring it up. Kreathor brought it up, haha. He's the bad guy.

Yeah but I haven't brought it to blame you guys, but to ask if there are some better solutions on the horizon and what can we do to improve this situation.
I saw that Mark V has some nice features, so I thought I'll ask if there are some features supporting VIS...

Speaking of raising a bounty I'm in, but...
Considering I'll give $100 I'll have to find other people willing to pay $$$ to get $2500 in total, which probably is impossible, so I think it's time to finally dive into code and see what we can do in that matter. 

Reporting problems is only a good thing in my book.

Wow, ad_mountain's vis looks really broken. Assuming the player was in-bounds and then you used lockpvs and noclipped outside?

The ARWOP screenshot doesn't look too bad to me.. assuming the player was at the start position when pvs was locked? Also I am 99% sure ARWOP predates func_detail being used commonly so it would be immune to the bug that can cause total breakage (vis seeing into entirely separate areas).

The last one of ionous/pulsar's map, I'm not sure there is much unneeded stuff, that's a big open arena type area.

Another point to remember at least with Quakespasm, it has the anti-flickering patch so if an entity exceeds MAX_ENT_LEAFS, the server will always send it. So testing in Quakespasm, large bmodels that exceed max_ent_leafs will always render, and it'll look like VIS messed up but it's just a server quirk. 

So testing in Quakespasm, large bmodels that exceed max_ent_leafs will always render

Yeah, I wasn't trying to draw attention to the bmodels.

Although those aren't Quakespasm screenshots Mark V uses the same mh/spikey solution. 

@kreathor. Mark V supports external vis which allows, for instance, true transparent on id1 maps without vispatch (files on the Mark V page).

Mark V supports sv_cullentities 2 -- which on poorly vised maps can cut-down on network traffic substantially and (sadly) increase rendering speed.

sv_cullentities from essentially borrowed from FTE (although I may use R00k algo?) and DarkPlaces has a similar feature.

It also has r_lockpvs and r_lockfrustum borrowed from DirectQ which mh said he borrowed from Quake 2. 

I think I mentioned before that there should be some kind of brush that mappers could place that allows more freedom over culling.

Unreal Engine used to have "visibility culling" that you placed a brush to give hints for vising purposes. Maybe Quake has something similar (is this how hint brushes work??). 

I would assume that if they're supported at all, hint brushes work like described here:
http://tastyspleen.net/~panjoo/rust/tutorials/hint/hint.htm

I do wonder if using such brushes would improve maps... It's another layer of work on top of what is already required but with some bigger maps it could be worthwhile. 

Mark V supports external vis which allows, for instance, true transparent on id1 maps without vispatch
Thanks, I'll have to check this feature out

I do wonder if using such brushes would improve maps... It's another layer of work on top of what is already required but with some bigger maps it could be worthwhile.
If you do it correctly then yes. Problem is if you have big open spaces, then it won't help you much... although in my case I used it to cut portals behind big building standing in center of open space.

I like this "tutorial". Explains it properly:
http://omnicide.razorwind.ru/wiki/index.php/Tutorials:Understanding_a_VIS_and_Hint_brushes 

What did more modern engines such as Source do to improve their VIS? Half Life 2 has plenty of huge open spaces that run well. 

Half Life 2 (Source) is using PVS and occlusion culling for outdoors. 

So how is PVS (Potentially Visible Set) different from VIS? The Valve Dev wiki describes PVS as a collection of visleaves which might be visible from a given location. Isn't that just how VIS works? 

VIS is just a tool/process of creation of PVS, so to be 100% correct with nomenclature, we shouldn't use it to describe PVS ;)

Anyway we are OT a little, maybe we should move with this conversation to Mapping Help, before Baker gets mad :P 

For the curious: https://developer.valvesoftware.com/wiki/Visibility_optimization

By the way, Source uses vvis.exe. 

I needed to look at a modified FvF player model in a mirror today, but could not do so because Baker took away the mirror control from the user....

"The Id1 Mirror Texture Only Works With Id1 -- It's Intended Behavior
...
if someone is playing Soul of Evil or Travail or something and some random texture is pointlessly a mirror because it is window02_1, that would be annoying as hell ... "

But r_mirroralpha is a user-controlled variable, and if a user wants it on, it should be on, no matter what mod they are running. It should also be defaulted to "off" ("1"), so if it IS on, then it's definitely intended to be on.


I had to load up FTE to look at myself in a mirror in FvF, and even that engine wouldn't let me activate it in Multiplayer mode, telling me it was a cheat. Boo! (I'm the server operator -- I am the one who should decide what is or isn't a cheat on my server, and I don't feel mirrors are a cheat). But at least I could use mirrors to look at the modified player.mdl in FTE Single Player mode.

I dislike when engines decide for me what settings I am allowed to use in what modes. 

I may end up coming up with a method to allow a gamedir mod to enable that as choice. 

Does Mark V supports scrolling textures? What's the name convention? 

Yeah, type "find scroll" in the console.

It's only in the GL build. 

sv_cheats 1; restart;
then you can do whatever you want.
and so can other users on your server, so have fun with that.
unfortunately nq doesn't do serverinfo, so that'll only work with an fte server.

use mirror_* for mirror textures in future. those should always be mirrors, and need not be considered cheats. window02_1 on the other hand is present on many maps, and in many of those it potentially exhibits serious graphical glitches that allow it to act as a wallhack or whatever. so yes, its generally considered a cheat unless the mapper explicitly intended it.

for similar future needs, you might want to consider using chase_active or equivalent (most engines support it to some extent), or maybe try fte's splitscreen.
its generally easier to look at it from other angles then. 

His server coops existing maps. He doesn't have any choice in what the texture names are so he doesn't have the option to change the texture names to mirror_ * 

I've tried to test it by entering "r_texprefix_scrollx wizmet", but it didn't work. I'm using the version 1.36. 

That feature was slated for removal, looks like is broke. I probably was working on mirrors and removed it, but forgot to nuke the cvar and friends.

It works in this ancient build binary + source.

The reason that feature is slated for removal is largely because:

1) I can't imagine a scenario where it could be turned into a standard.
2) This method has no ability to control the speed.
3) You can do animated textures in maps using the +[texture name] animated textures method in regular Quake and it works on everything, although it is jerky and has a 10 frame limit.
4) Low interest in porting scrolling to WinQuake, hehe.

There's also probably better ways to do it too.

Was a nice experimental feature back at the time, I just wanted to see what it would look like. 

Retroquad uses the [ and ] characters to prefix parameters for scrolling.

[ is negative
] is positive

The first of them in the texture name indicates horizontal scrolling. The second one indicates vertical scrolling, and it's optional.
The second one must be followed by a number indicating the speed. The first one only must be followed by a number if the second one is omitted.
If the speed value is omitted in the first one, both will use the same speed:
]1 horizontal scrolling, 1x speed
[1 horizontal scrolling, -1x speed
]0]1 vertical scrolling, 1x speed
[]1 diagonal scrolling, -1x horizontal & 1x vertical speed
]1[2 diagonal scrolling, 1x horizontal & -2x vertical speed

Retroquad's texture naming parser can also recognize parameter prefix characters anywhere in the texture name, allowing for multiple effects to be combined. The water in this video uses 20 textures named from *watersa]0]1+00 to *watersa]0]1+19 . The parser reads it as:
*water it's a water texture
sa the texture's individual name
]0 zero vertical scrolling
]1 horizontal scrolling at 1x speed
+00 to +19 animated frame index

The only thing I couldn't decide is whether the speed value should be in units per second or in loops per second. In the first case, big textures would need big numbers to fully scroll, and in the second case, small textures would need fractional numbers to scroll slowly. However, the first case also makes it easier to sync multiple scrolling textures with different dimensions.

The reason for all these is to make texture naming as economical as possible while still being flexible, since vanilla Quake only allows 15 characters per texture name. 

4) Low interest in porting scrolling to WinQuake, hehe.

Getting it to work properly in the software renderer takes a lot of work, so it's understandable.

A cheap way would be to scroll the texture per-texel in the surface cache. WinQuake uses a similar method to scroll the sky overlay, which is why its movement is so jerky. This would only look good on fast scrolling textures, but at least it would work.