yeah, "r_useportalculling 2" breaks map if you have some Warnings/clipped portals during VIS. It's very annoying, but 50% of fault lays on mappers side ;)

I was just curious if there are any VIS improvements in your engine, or do you plan any?

As we know VIS in Quake is very primitive and does it's job poorly, so you have to do tricks etc. to limit r_speeds. 

The idea the engine would do the same thing as vis (which can take untold hours to run in some circumstances), and do it better and do it instantly on map load doesn't make sense.

I'm just saying ... if the engine could do that, why wouldn't you take those calculation and throw them into the vis tool instead?

Yes Quake vis sucks terribly, especially at open maps. Kills frame rate, makes demos huge --- like the 10 GB "I played Arcane Dimensions!" demos, makes QuakeC slows, makes map uncoopable with enormous network traffic.

The correct solution is improvement of map compile tools.

/Maybe you should get together with other interested parties and raise a $2500 bounty and try to induce someone who writes tools either in Q1 or in Q3 or at id Software or for another game engine to get Quake vis right or vastly improved.

/One idea. I'm often wrong about these kinds of things. 

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.