Big open maps and culling are not the problem. The current culling is perfectly capable of handling them, a minor optimization to R_RecursiveWorldNode makes it a little better (software Quake has the optimization, GL doesn't).

The problem is in the renderer and server processing. QuakeSpasm now has the necessary renderer work to be able to handle big scenes. It could go faster by bumping the hardware requirements to GL 3.x and implementing array textures for lightmaps, as well as putting in some instancing for MDLs, but that might be too intrusive a change to the codebase.

Server processing is a problem and QC is just too slow for large entity counts. That's the next tree that has to fall. 

I agree with mh, it still works impressively well on big, open maps, and it matters a lot on AD maps. ad_tfuma was fastvised it right up until release, because Fifth and I both assumed vis would take forever and not be able to optimize much, since it's more or less a giant box with some underground areas. Just before release, one of the testers complained of low fps, so I tried full-vising it - took only 20 minutes (8 threads), and the wpolys visible from the start position were cut in half (30k to 14k iirc).

QS's brush model renderer was the first renderer thing I changed (this was ~2014 for RRP, ijed's map had some complex bmodels), they're not merged with the world, but each is drawn using the world renderer.

QS uses the Fitz sky renderer unmodified. (same for liquids).

GPU lightmaps: blending the 4 lightmaps per face sounds like a straightforward good idea. I'm wondering if it will be difficult to do the moving dynamic lights from rockets/etc. IMHO they need to be kept at the low-res of the lightmaps - when I was experimenting with high res lightmaps and LIT2, I remember noticing that rocket trails really stuck out like a sore thumb when they were over a high-res lightmap. @mh did you do any experiments with this part of GPU lightmaps? 

I draw dynamics as additive blended extra passes over the scene. Full per-pixel quality. TBH it doesn't bother me but maybe this is one of those things that annoys different people in different ways.

I guess you could use a low res attenuation map texture but I just do the maths.

Optimizations: Eric Lengyels scissor test optimization is mostly designed for shadows but helps here too. Frustum culling the dlight. Only light surfaces that were drawn in the main pass.

I also add dynamics to BSP brush models using this scheme.

Light styles: I actually use 3 textures, one for each of R, G and B and encode the styles into the color channels. Animation is a 4-component DotProduct per channel and combine them to the final color. 

Another side effect, not related to rendering, of the vis problems combined with spritey particles is huge demo sizes.

As you know, the vis information is used to determine what entities the server side thinks is visible to you.

If you record a demo in most of the Arcane Dimensions maps, the demo is going to be massive after 30 minutes of play (600 MB).

I ended up disabling the autodemo feature by default in Mark V because recording a demo in Arcane Dimensions became a performance issue ...

... Which users perceive as "this engine is choppy", hehe.

So anyway, the full deck of cards.

/The very nice thing about Arcane Dimensions is that it is open source. Sock is #1 in my book because he's always been open source.

Which also means it is possible for new optimizations to theoretically be written eventually to shift some burdens from the QuakeC to the engine (particles).

Arcane Dimensions merely exposes things that the map compile tools and the engine particle systems could handle better. 

particles - qss uses fte's particle system to support the effectinfo stuff that sock used in ad, as a result qss should have much more sane demo sizes with ad 1.5.

choppy - use a thread to perform the disk writes, then you don't get stalls from flushing happening on the main thread.
making that change reportedly solved multi-second stalls with fte on linux.

size - gzip it as you go (you don't rewind, right?...). 

damn

the demo that i recorded for ad_magna is 2gbytes

i checked with r_showtris 1 and no particles-entities, the demos should be smaller 

making that change reportedly solved multi-second stalls with fte on linux.

Interesting. 

All the FitzQuake derivatives support r_drawworld 0; fog 0 // fog 0 helps visualize distance entities.

The following screenshot demonstrates how map vis isn't helping much ...

Particles ... but as you can see there are tons of candles and monsters in the vast distance. It's a lot of unnecessary drawing.

http://quakeone.com/markv/media/r_drawworld_0.png

All those monsters that have no chance of being seen ...

1) Get sent to the client by server.
2) So they get recorded in a demo
3) So the engine tries to render them on the screen

Rendering hundreds of entities that cannot be seen is a performance hit. 

"Which also means it is possible for new optimizations to theoretically be written eventually to shift some burdens from the QuakeC to the engine (particles).

Arcane Dimensions merely exposes things that the map compile tools and the engine particle systems could handle better. "

I was tinkering around with an idea, (well mostly because I found what I did wrong with bsp2), working on some AD stuff, and particles. I started with making little flames on the tops of candles, instead of the bouncy little polygons. But I could expand this to replaces the sprite emitters from AD and use QMB particles on the engine side. I'll post some results/screenshots when I get things rollin'. 

Hey, I'm getting a weird wateralpha bug

see: http://imgur.com/a/rqoGv

the lava (or any fluid) appears milky except for when the player is clipped into a wall?

the alpha is set to 0.3

the version is version 0.92.1 (SDL 2 build)

I'm running ubuntu 16.04 LTS using opensource radeon drivers.

Is this a configuration thing or a software bug? Cheers. 

the map isn't water-vised...
(combined with gl_clear) 

I thought that the vanilla maps worked fine with wateralpha 

only if you revis them yourself, or use get vis patches.
otherwise they'll just be transparent and reveal the void below.

if you were using a value of 0.6, you might not have noticed. 

Will work but I believe it affects performance 

I thought that the vanilla maps worked fine with wateralpha

No, they don't. This is actually called out in the original GLQuake readme: https://github.com/id-Software/Quake/blob/master/WinQuake/docs/readme.glquake#L152

Unfortunately, the standard quake maps don't contain any visibility information for seeing past water surfaces, so you can't just play quake with this turned on.

Note that r_novis will just let you see surfaces through water; it will not let you see entities (monsters, doors, pickups, etc) through it. 

Mark V and DarkPlaces (rather sure) and some other engines support external .vis files.

https://quakewiki.org/wiki/External_Lit_And_Vis_Files

You put the .vis files in id1/maps and then all your Quake maps are vised.

It's pretty much the same thing as external .lit files. 

heh TIL

thanks guys :) 

I use this from BPJ wrote on an old thread on QuakeSource.org that just draws everything

[code]
byte *Mod_DecompressVis (byte *in, model_t *model)
{
static byte decompressed[MAX_MAP_LEAFS/8];
int c;
byte *out;
int row;

row = (model->numleafs + 7) >> 3;
out = decompressed;

if (!in || r_novis.value == 2)//BPJ
{ // no vis info, so make all visible
while (row)
{
*out++ = 0xff;
row--;
}
return decompressed;
}

do
{
[/code]

it simply allows me to see all ents underwater, yet im sure it's not optimal :P 

It's definitely not optimal because it will also pull in ents that would otherwise not be visible in a properly watervised map.

The other thing it will do is increase server load and protocol traffic.

The latter is something you might be surprised about. We have a tendency to base assumptions and measurements only on things we can directly see. In a scene with 400 active and moderately complex entities, the bottleneck isn't the renderer - it's PR_ExecuteProgram (QC, in other words). 

Some weirdness going on with the sky at high distances: back wall disappears when more than 8192 units away. 

 

It's at 16k as per default. With normal textures it works fine, just the sky brushes are affected. 

I bet it's a qbsp limit (BaseWindingForPlane). Someone reported this as a bug in tyrutils-ericw a while ago and I raised the limit, try the latest version of my tools. 

You really should just draw sky with glDepthRange (1, 1) - that way you can draw it as a tiny (but larger than nearclip) cube around the viewpoint and it will automatically position itself at the far clipping plane. The way Fitz & derivatives handle both the scrolling sky and skyboxes makes this very possible. 

I know most of the mods/maps have to be installed in the base Quake folder, but it really keeps that folder messy and it's hard to sort through if you have tons of maps/mods and when you want to delete a folder it's a hassle.

Is it possible to put all the mods/maps in a seperate folder and still be able to launch QuakeSpasm with enjector? I tried doing that but it won't let me because everything has to be in the basedir, is there a command i could use?

Is it possible to set a path to a different folder in quake injector?