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. 

Your video certainly looks very nice. 

By the way, Retroquad animates sky & liquid texture frames at 15 fps, rather than the default 5 fps of regular animated textures. Alphamasked "fence" textures are animated at 20 fps. This was hardcoded just for that demo, but a standard for custom timing of texture frame animations would also be a good thing.

However, the 15 character limit for textures makes it a pain to add more customization. The name "*watersa]0]1+19" is 15 characters long already, and even if we remove the "sa" characters from it, there would be no room to define a 15 fps interval, which would require a special character plus two numeric characters (e.g. *water]0]1+19,15). 

By the way, sorry for hijacking the thread, but I'm just trying to encourage more coders to implement such features, and maybe define some standards for them. 

Engine issues and engine support of mapping enhancements are always on-topic. Not sure what you are apologize for.

Your results look nice and are smooth.

It seems wrong to put the timing in the text name, yet with Quake we do water, alpha masking, animated textures, etc. by the name .. so ...

The naming convention you are using seems quite sensible. 

In my config file, I use:

r_texprefix_scrollx z_exit

...just for the nifty effect (scrolling EXIT signs).

Though in some places where the mapper uses the texture somewhere else (like the start of terra4) it looks... odd. Like only the fullbright part is scrolling, and not the rest of the texture. Not that I'm complaining -- I like experimental features to play around with (as long as they default off!)



And yeah, I used chase_active, but I wanted to see myself from the front too. Mirrors were (well, they should have been...) the quickest way for me to do that, heh. I did not know about the various FTE features (splitscreen, eh?).