Pan's buglist of map editing issues and other errors

[Panjoo]

I will report here the issues that I come across while finalizing the DM maps. The more I actively work in the mapeditor again and test all kinds of things ingame, the more little bugs I find. (If I encounter more things I'll add to it here.)

---

Buglist:

• ~~Shadows start to flicker on medium and high setting. See videoclip. https://user-images.githubusercontent.com/10857572/149621498-8a7d45ba-abe5-4a95-b4bf-c32890f8991b.mp4~~

• ~~Footsteps sounds "are not valid". I was trying to set some footstep sounds for metal surfaces but no matter what I try it only takes 'metal' as valid sound. Even though for instance 'metal2' is in the players/common dir, it will say: "... not valid". Tried with and without the qutotes.~~

• ~~I'm not sure but I think there's a problem with the misc_sound attenuation. I want this sound to be very subtle and local so I've set it to atten 3 (cubic). Now if I move around the location of the misc_sound in spectator-mode, the pitch of the .wav seems to change up and down, depending on the distance. Because this .wav has a constant background tone it's very noticable. Here is a test boxmap with a looping .wav file. (It's all in the zipped pk3, type 'map soundtest') > soundtest.zip~~

• ~~Also, if you set the sound key to a wav that doesnt exist, eg. 'world/silentdummy' - the game crashes (see pic). A warning msg when it;s trying to play the missing sound would be nicer. Or perhaps include a silent.wav for when you dont want a sound? play.sample null.jpg~~

• ~~Something looks wrong with the puff_cloud fx. Ingame it looks tiny, almost not visible and too coloured. (Also is a 512x512 image necessary for this?)~~

• If you've set angles on a mapobject (eg. a plant model) and then later touch the mapobject to move it to another spot, the angles get deleted... (Might be Netradiant related though).

• ~~It's not possible to aim a rocket down into the lift shaft without hitting the floor. I don't know how it works but I think the origin of where the projectile shoots from needs to be made somewhat higher. cantaimdown.jpg~~

• ~~@jdolan > a reminder to change the default r_alpha_test_threshold from 0.8 to 0.5 like we discussed. I've made a new fern.obj plantmodel (mapobject) which needs a lower default value~~

• ~~Just checked https://ci.appveyor.com/project/Paril/quetoo and downloaded the latest develop snapshot from @Paril. But there seems to be a problem. Quetoo crashes after a few seconds and just look at the textures in this screenshot of a fastcompile (no light) of Edge: ohcrap~~

• ~~r_caustics suggestion On most liquids the caustics look alright, really like the way it shows up above water, but on maps that have open and clear water areas like Tokays and Pits, the default caustics look too present, almost like a leopard skin. Especially against darker textures. I typed r_caustics 0.5 and to my surprise that worked and it looked better on the maps that I mentioned. But on other maps it looks better with the default 1.0 - depending on the brightness of the background textures. @jdolan You mentioned that you are baking "proximity to translucent liquid" into the lightmap and lightgrid data. Now it got me thinking, can this perhaps also be made into a worldspawn key just like any other key that has to do with lighting, so that the mapper can set caustics to override the default value of 1 for that particular map?~~

• ~~Surface light Found these problems earlier on but I was hoping that it was something in the map, like a wrong surface flag or a misplaced light or whatever. Turns out they are real bugs that I can't fix in the map editor. In fragpipe I can't seem to get a uniform lava lighting going. Some walls get lit by a reddish glow (as expected), while others just seem unaffected by the lava surface light. Tried everything; removed fog, manually set a different light value than what is used in the material, etc. One moment they are lit correctly, then other times they aren't) lavalight1, lavalight2, lavalight3 -Also, there seems to be some light leakage going on. In the 2nd screenshot the lava from the left area was protruding under the floorbrush of the shard hallway, once I pushed the lavabrush back the reddish hue was gone.~~

• ~~Emitting surface light on bmodels is acting wacky This one is very strange. I couldn't understand where the strong orange lightglow was coming from in the middle atrium as seen here. At first I thought it had to be coming from the lava itself, but then it should never reach the floor of the quad room. The only light source close by was the little yellow lamp texture, on that moving platform. That surface light is only set to 100 in my material so that couldn't be the cause for all that light, but as it turned out, it was. Once I changed that lamp texture for something else, all the extra light was gone.~~

• ~~misc_model alpha_test no longer works on misc_models -> (miscmodel.pk3 testmap) misc_model-alpha~~

• ~~Clip holes & compiler warnings There seems to be something going on with content_clip brushes. Look at these images, it's from that little rock in the outside area in Edge but it was also happening with the terrain near the tunnel exit where I had added clipbrushes. (Although it may not be visible in the current Git version of Edge). ~~With the warnings still there, I've already gotten rid of the holes in the rocks and terrain by adjusting the clips so that they don't intersect with the other solid brushes so much.~~ Admitted, it's pretty intricate brushwork there, but either way I don't think clipbrushes should create visible holes or even split brushfaces. (Not sure about the latter though). ... clip-editor clip-wireframe-overlay clip-removed~~

• ~~Flares draw order This isn't a new bug but in some maps it's become a problem since it's clearly a visibility bug. - In the map Pits I want the water opaque again, just like the original map, but as you can see here the flares are visible from under the water and also shine through entity models. flares-prob~~

• ~~Armor respawns In Quetoo armor respawns currently after 40 seconds. In Q3 it respawns after 25 seconds and in Q2 after 20 seconds, which to me always felt a bit too fast. So 25-30 seconds would probably suit best. I don't know if anyone would mind to change this back, but game elements like this should probably be kept more or less the same as other Quakes.~~

• ~~Rocketjump height With the current rocketjump velocity it's too easy to overshoot your target spots. I can't reach heights over 384 units but anything around 256 is way too easy to each. Perhaps a middle ground like 288-320 units would be better and less noobish?~~

• ~~Crushers func_plat: these will now crush you to death if you get stuck under them and there's no key that I can set to stop them from doing it. func_train: if you get crushed by the two moving pilar-platforms in Fragpipe's slimepit, you'll see nice fireworks.~~

• ~~Slime dmg is still not set to damage per second so it kills the player way too fast. The mapper should have the option to set this.~~

• ~~Player’s boundingbox should be able to fit in 64 unit height spaces or at least 68 units, without having to duck. As of now he doesn’t even fit in 68 units. (In cg_third_person you can see the playermodel will easily fit when standing upright). Examples: Fragpipe - the area with the Megahealth. I’ve already raised the ceiling as much as possible but this guy still has to duck here to get under: tootalldude Pits - the staircase with jacket armor underneath has a opening of 68 units high but you have to duck to get under. Hallways - the cornerstairs that has the combat armor underneath. Lavatomb - the two secret doors (64 units) next to the sinking pillars. From the outside you can walk right in without having to duck, but from the inside you have to duck first.~~

• fps ? The game runs okay on my 12 yr old pc (that I mainly use for editing), but there's something that I noticed while checking the fps. I've set vertical sync off and the framelimiter to 250 since I usually don't get much more than that, and on average in most maps it's around 115-190 (with just me walking around). Setting the framelimiter to 0 seems to lock it @ 59 fps, which is not what I expected, I expected it to allow the fps to reach its true max. On the smallest test maps the fps is not even breaking 200, and I'm talking about a "map" that consists of 10 brushes and 3 simple alpha_test plants. That doesn't seem right. ... As you can see here, if I'm in spec mode and fly outside the map the fps is at its max, but I've never seen it go over 250, regardless of fps settings. As soon as I fly inside the playable map area the fps drops to 168. I would have thought that this game would easily run a box map at a much higher fps, even on this pc. I wonder what is going on here, why would running a box map give me almost the same fps as running a real map that has 1800 brushes and dozens of entity models? ... See screenshots below. When I'm tuning specific areas I usually like to just block out the rest of a map to speed up the compile. So this is only a small portion of the map dm4-hallways. In spectator mode, the soon as fly inside the map you can see the fps drop, from 250 to 110. But as it's not even a quarter of dm4 (~500 brushes) I expected better results. ... Outside the map: ~250fps / Inside the map: ~110-140 dm4portion1 / dm4inside

• Water fx = fps killer In tokays if I'm looking up from under the water I lose like 50 frames per second. Especially transparent water + the splash sprites is a real fps killer. And it almost looks like a bright white nuclear dot anyways, you can't even see all the actual splash textures. (water-fx-fpskiller) this is from the same location as shown above. The fps goes from low (110) to lower (43) when I shoot the LG in the water. And this is not even the entire map but only a small portion of it, 3/4 is blocked out. The water splash still uses waaaay too many animations and it steals too much framerate.

[new]

• Swimming [ bug returned] .1. When you're in the water and you touch the bottom, it won't let you swim upwards at all unless you press the +move_up key.

• -Lightmap unwanted lines Sometimes lightmaps get cut off and it produces an abrupt break in the lighting of the texture, for instance see these pics: If the light emitting surface (the slime) has a light.radius of < 70 it produces a break in the lightmap here. But if I increase the light.radius to 80, the lightmap doesn't break and fades out with a smooth transition. It almost seems as if there is some sort of threshold. .. Also, I sometimes like to set a different light value on liquid brushes if needed with the Surfaceflag-editor, without changing the overall value in the material. This has always worked but if I do this now, the surface won't emit light (while Light flag is checked) and the texture shows as fully opaque.

• Direct patch light on liquids oddity I was testing different light values on liquid slimebrushes and noticed that the base texture now has these weird glowing lines. Here's a screenshot of just the base textures without the scrolling stage layers. Looks like you're using some sort of tile texture as patch lightmap? .. Anyway I was trying to mask these obvious lines by setting the base slime tex as liquid (warp) but it doesn't seem to do anything. Tried both with the surfaceflag in the Editor and in the materials. In fact, more Surface flags in the Editor no longer seem to function properly. ...

• Slope bouncing While doing some work on Slimyplace I noticed that the player almost gets catapulted when running and jumping up steep slopes, like the ones shown in this pic :

[Paril]

Degenerate windings are triangles that are super thin that they get collapsed into an invalid triangle (one that has two identical points), so the entire face is just removed. It shouldn't be a problem in most cases, but there are known cases where this results in a missing triangle (edge outside has a couple). The second warning is because portals are generated from brush sides, but because of floating point inaccuracies it's possible for a portal winding to end up not being able to find the brush side it came from. It's not fatal but does indicate something that we should look into.

cg_add_entity_shadows 2 and 3 were experimental to try to make them look nicer on angles & allow shadows to be dropped down edges (for instance you'd see an overhang of a shadow if somebody was standing above you over a lip), but it's too buggy and I'll probably just remove it. It'd be better for us to spend our time later on doing proper shadow mapping.

We have a doppler effect applied to the listener, so when you move around sounds you'll hear the pitch shift. It might be a tad too strong. You can adjust the intensity with s_doppler (the default is 1.0 but it can be any value). It's a global listener effect so it can't be disabled per sound. It's possible our doppler is just too strong, but keep in mind you move pretty fast in the game so maybe it's just working as intended.. we can increase the speed of sound if need be.

This image here is puff_cloud on impact: seems fine to me, are you referring to a different effect? No, this image probably doesn't need to be 512x512 given the in-game sprite size.

[Panjoo]

"...but there are known cases where this results in a missing triangle (edge outside has a couple)" I've noticed this, it happens fast when you're manipulating the vertexes. But I managed to fix most of the offending brushes by remaking them.

As to the doppler effect, if you load the testmap and bounce on the jumppad next to the misc_sound (I added a visible cube there), you'll notice that it's as if the pitchchange can't keep up with your speed. It just sounds strange right now.

"...puff_cloud seems fine to me, are you referring to a different effect?" Yes, I'm referring to the player breath fx, visible in cg_third_person - I think this is using the same image? See pic: puffydaddy

[Paril]

Oh, breath cloud is a different image. We probably forgot to scale it when we changed over to the new size system (sizes used to be relative, like a size of 1.0 meant that the image was rendered at full res; now it's absolute, but we must have missed moving this one over to the new size)

re soundtest, it sounds correct to me, but maybe you're right in that the doppler effect is too strong by default. I just left on the default values for speed of sound (343), which is defined in meters per second. I'll play around with speed of sound.

[Paril]

Pushed a change to speed of sound to match our unit system, and breath cloud.

Regarding the rocket launcher: I think I can fix this. We have a check that ensures that the start point of a projectile is never inside of a wall, but we don't have a way for players to fire "around" objects that are immediately blocking the start position.

[Paril]

https://streamable.com/7xme2o Made some adjustments to aiming which should make it easier to aim down shafts that are blocked by the weapon position.

[Panjoo]

https://streamable.com/7xme2o Made some adjustments to aiming which should make it easier to aim down shafts that are blocked by the weapon position.

This makes me happy - much better from the looks of it.

Pushed a change to speed of sound to match our unit system, and breath cloud.

Can I re-download the snapshot from here to check the sound speed change?

[Paril]

Yeah; you can keep this bookmarked ( https://ci.appveyor.com/project/Paril/quetoo ), if it shows green and says "develop" then the snapshot .zip should be updated for you to grab.

[jdolan]

The footsteps thing is confusing.

Let me guess: you were editing the materials file and typing r_restart or even map $map and it was still complaining about a footstep you weren't even using anymore?

This is because the footsteps come from the collision material, not the renderer material. There are two copies of this data loaded within the game. The server uses the former, the client uses the latter. When you edit the footsteps and r_restart, the client sees the change, but the server does not. And even if you map $map, we don't reload the map if it is already loaded (maybe we should).

I can fix this by loading the renderer material by name, using the collision material that was returned. But, @Panjoo please confirm that if you load some other map and then reload the one with the footsteps (or simply quit and relaunch the game) you do indeed get the correct footsteps.

I tested this just now on Edge and assigned metal2 and wood3 to two floor textures and they worked just fine as long as I completely relaunched the game.

[Paril]

Alternatively, a method to reload all cm materials for editing purposes which syncs with both server & client. Not as easy as a "force map reload" option, but..

[jdolan]

I'm actually thinking it would make sense to treat footstep samples as proper material assets (since they are). Then the client doesn't have to do anything bodgey, and we'll include custom footsteps in quemap -zip too.

[Paril]

Not a bad idea. Makes sense.

[Panjoo]

jdolan: please confirm that if you load some other map and then reload the one with the footsteps (or simply quit and relaunch the game) you do indeed get the correct footsteps.

This is very odd. Now the steps sounds work again. (I did download a newer snapshot though, so... dunno) When the footsteps wouldn't change and showed up as invalid I tried everything, and first thing I did was relaunch the game. Tried it for different textures to no avail and even checked the folder for the wav files. No idea what went wrong.

jdolanI'm actually thinking it would make sense to treat footstep samples as proper material assets (since they are). Then the client doesn't have to do anything bodgey, and we'll include custom footsteps in quemap -zip too.

Yes, but as long as the mapper always has the option to change and override the chosen footsteps for any material asset.

Paril: Pushed a change to speed of sound to match our unit system, and breath cloud.

I installed the snapshot and tested the same soundtest map. I wouldn't change too much now, it sounds just about right here :)

[jdolan]

The game will no longer crash on NULL sound samples.

I also refactored the footsteps code quite a bit, and it's much easier to play with now in-game. You can simply edit the footsteps name in the materials file and r_restart. I also fixed a bug where custom footsteps did not work on upward moving entities.

[Panjoo]

Nice going, doing it via r_restart is better than having to constantly exit and relaunch the game for little edits. There's also less change to make mistakes too while testing and switching between 10 open windows.

[Paril]

Can't we just make alpha test threshold a material parameter? Makes sense that people might need/want different thresholds there. I mean ideally if you know the material is going to be alphatest the texture would just have 0 or 255 alpha values, but..

[jdolan]

Pan and I talked about that over email. We certainly could make it a material param, but we were going to first try setting the global to 0.5 and adjusting textures accordingly. If that’s proving to be a pain then we can def just add the material param.

[Panjoo]

Hmm I'd love a material parm for this and have the option to just manually adjust the stuff. It's good to have good default values but adjusting and fiddling until things look good is what mappers like to do. It's usually just for one or two textures. But my plants and other alpha_test textures look cool @ 0.5 so whatever you decide is fine right now.

[jdolan]

Hey dude! Your new issue with the messed up textures is because of the footsteps fixes I made. Thorn ran into the same problem and he and Paril nailed this down. All you need to do is pull the game data from develop. You'll notice that when you do, the footsteps files have changed (step_1.wav is now step_default_1.wav, etc). Because the game isn't finding these files, it is failing to resolve all materials. Sorry!

Also, alpha_test is now a material parameter. It behaves similarly to light: if you specify it on a material, that material will automatically add SURF_ALPHA_TEST to any faces that reference it.

So your materials might look like:

{
  material pits/chainlink
  alpha_test .3
  roughness 1
  hardness 2
  specularity 2
}

Or

{
  material edge/tallgrass
  roughness 1
  hardness .5
  specularity .5
  surface alpha_test
  alpha_test .4
}

Or, to use the default alpha test value of 0.5, just add the surface param and do not specify alpha_test:

{
  material edge/tallgrass
  roughness 1
  hardness .5
  specularity .5
  surface alpha_test
}

[Panjoo]

Nice, nice! It's getting more fun with these little extra's. I'm up to date again with latest snapshot and develop game data.

Btw, netradiant needs a quetoo.game file instead of a default_project.proj. I already edited it though.

What's cont Atmospheric do again, is that for fog/dust/etc brushes so that they don't eat decals? And surf Liquid is just warp I guess. I think I got it.

[jdolan]

That's the idea with CONTENTS_ATMOSPHERIC, yes. And the flag will automatically be applied by quemap to any brush side that has common/fog or common/dust on it. So you don't even really need to mess with it in NetRadiant, unless you're using the contents filters to show / hide them. Side note, I added a lot of handy features like that in GtkRadiant 1.6, as well as smooth camera movement, if you want to take a look. I've also been working on Trenchbroom support, which is quite usable already. But I digress...

I'm currently working out a bug with CONTENTS_ATMOSPHERIC. You may have noticed a brush error on Edge near the glass windows / crates. Don't worry. It'll be fixed soon.

[Paril]

Just out curiosity, @Panjoo did you move Edge's origin point recently? I noticed our bot navigation files are offset now.

[Panjoo]

@Paril What is 'recently'? The last version of Edge that I uploaded myself dates July 8 2020. But yes I did. If I recall correctly I think I moved the entire level to a different spot because of the blocks that slice up the map in 1024x1024 pieces, which produced some unfortunate cuts and polys.

[Paril]

Hmm. I'll look into it. JD says we don't have block slicing any more (it's an old thing that Q2/Q3 did in the past but we don't need it any more) so it shouldn't be an issue; similarly we use high precision positions, so there's no more of that weird limitation where you move differently if you're on the positive planes of the map.

Anyways, was just wondering why all of the navigation nodes were all pushed around. I remember fixing this once but was surprised to find the issue back again. I've repositioned the nodes now anyways. Moving the entire map shouldn't be necessary going forward, but, if it is for whatever reason let me know so I can think of a solution that won't completely bork our nav nodes.

[Panjoo]

I see, but at the time when I made that map adjustment the VIS was not ditched yet, at least not to my knowledge. Is it complicated to make a new bot nav file? I thought it was just running around the map while in some sort of 'record-mode' and doing some jumps so the bots will do the same.

[Paril]

It's not difficult but the in-game editor needs polish. I only really developed it to work for my needs. It can also take a while to get everything perfect, and the bots have some navigational quirks that I'm still ironing out.

[jdolan]

@Panjoo Caustics can now be specified in worldspawn, as requested. Default is 1.0.

I'll look into these other lighting issues now.

[jdolan]

Alpha test issue is also fixed. Thanks for the test map!

[jdolan]

I'll continue to look into the lighting issues. Something odd is up. It's difficult to tell with the textures, as well, but here are the problem areas you called out with just the lightmap rendered:

The lava lighting here does seem uneven. I'm not sure it's totally wrong or unnatural, but I agree it doesn't seem quite right.

Below you can see the hot-spot on the ceiling from the little light on the func_train. It shouldn't be casting any light above, since it's a downward facing light, so something is indeed off here.

And lastly, the wall you can't seem to get red light on. You can see it is actually getting some, but the corner across the hall from it has a lot more.

My hunch is that the indirect light is set too high, and so you're getting unnatural bounces where incoming light is actually amplified instead of absorbed and diffused. That would explain the lava issues.. not the func_train one. But I'll run a couple experiments and report back.

[Panjoo]

Good job so far on the caustics and alpha_test. The more things I can finetune the better it's going to look.

As for the lava, I can always add a couple extra lights in places where I want that extra red glow, so even if there is something wrong here, it's not something that I can't cover up and make look good. A bigger problem to me is the surfacelight leakage thing. I keep finding areas where surfacelight is reaching places it should never reach:

[jdolan]

I was going to look into the light issues last night but decided to play a video game for the first time in months instead, heh. Can you try something, tho? Can you bake the map without indirect (—no-indirect I think). I’m suspicious that most of these issues are related to the indirect pass but have not confirmed yet.

[Panjoo]

OK, compiled the map without --indirect. (ambient .37 .31 .25 / brightness 2 /no other worldspawn keys) Many parts become too red, while other parts still lack light.

As I mentioned earlier, something is wrong here. It took over 61 minutes (3667279 ms) which is a horrible compile time for this map. And I even blocked out a portion of the map by placing a big cube over it, so 61 minutes for 2/3 of fragpipe. Takes me back to Q2 compile times in 1999 on my Pentium 233. lol :P

[Paril]

Potentially related to the fast trace changes?

[jdolan]

Lighting maps/fragpipe.bsp

Loaded 39 materials from maps/fragpipe.mat
Building patches         [100%] 22 ms
Direct lightmaps         [100%] 16271 ms
Direct lightgrid         [100%] 552 ms
Indirect lightmaps       [100%] 31620 ms
Indirect lightgrid       [100%] 1311 ms
Caustics lightmap        [100%] 1666 ms
Caustics lightgrid       [100%] 218 ms
Fog volumes              [100%] 221 ms
Finalizing lightmaps     [100%] 181 ms
Finalizing lightgrid     [100%] 97 ms

Lit maps/fragpipe.bsp in 52811 ms

quemap finished in 54485ms

🤔

[jdolan]

Did Pan get a debug build by accident?

[jdolan]

Anyway, yea, something is clearly fucked up with the lighting and I'll look into it this weekend at the latest.

[jdolan]

Btw, Pan, is this a modified fragpipe.map or do I have this version?

[jdolan]

Here are my results with the fragpipe.{map|mat} that's in Git (in map-fragpipe.pk3) right now, using quemap -bsp -light --no-indirect maps/fragpipe.map. It compiled in 17 seconds, and I'm not seeing that crazy red light.

In fact, for direct lighting only, I think the results look very good. It does make me think that a smaller default patch_size is worth considering, as you can pretty clearly see where the patch lights are "centered" near the lava and slime.

I think you may have accidentally added some monster of a light somewhere? Or several? That could blow up your compile times, and would explain the shitty red light that's nearly global, but clearly affected by direction somehow.

There is something wrong with the little light on the func_train. I'll look at that more closely soon. We may need to ditch it, but hopefully not. And I also agree that something is not right with indirect lighting. That will take some testing and tweaking, which I can also get into this weekend.

[Panjoo]

quemap -bsp -light --no-indirect maps/fragpipe.map

I'm not familiar with the --no-indirect option, is that something new that I don't know? Doing a quemap --help gives me this, and that option is not listed;

-light             LIGHT stage options:
 --antialias - calculate extra lighting samples and average them
 --indirect - calculate indirect lighting
 --bounce <integer> - indirect lighting bounces (default 1)
 --radiosity <float> - radiosity level (default 0.125)
 --brightness <float> - brightness (default 1.0)
 --contrast <float> - contrast (default 1.0)
 --saturation <float> - saturation (default 1.0)
 --luxel-size <float> - luxel size (default 4)
 --patch-size <float> - patch size (default 16)

So I did a quemap -bsp -light (which I guess must be that --antialias or something that I'm never gonna use because it takes too long). But the --indirect compile takes like 40 seconds

Btw, Pan, is this a modified fragpipe.map or do I have this version?

You should have it, I'm certain I pushed all them latest (2020) versions to master. But I haven't seen the newer fragpipe ingame since, same with Tokays and Pits. You probably took them out because you were in the middle of big changes at that time, iirc. I remember emailing you screenshots to compare all the maps and changes and whatnot, But anyway, I'm on a roll here now and will make sure we have all the right versions and redo the lighting. Well, as soon as it works.

[Paril]

Afaik, indirect is implied now. He reversed the option so that --no-indirect turns it off, but it's on by default.

[Panjoo]

So, if I compile with: quemap -bsp -light --indirect it takes 40 seconds, but if I compile with quemap -bsp -light (which you say is the same thing: --indirect by default) it takes an hour?

[Paril]

Ya. indirect isn't an option;

This is with the repo versions (like in the develop builds). It might be different on the older builds. Make sure you're using the quemap from the develop.

[Panjoo]

Thnx, I'll check it out later.

[Paril]

That being said, JD has been talking about fixing the indirect bug you've been seeing. He's been excited about it; it should be faster and also more precise for you. Coming soon:tm:!

[jdolan]

Making some progress.. quetoo000 quetoo001 quetoo002 quetoo003

• I figured out the light bleed issue. That's fixed.
• I thought of an optimization that brought Frag Pipe's direct lighting from 17s to 8s on my machine.
• Part of this optimization made it easy to add the sun diffuse feature that you were looking for. Basically, sun _size actually works now.
• It runs so fast now, I dropped the default patch_size from 64 to 32 which produces much better looking results on large surface lights like lava and slime.

Still some work remains to dial indirect lighting in, but I think this is headed in a very good direction.

[Paril]

I do wonder if we can just have a mode that does a light per luxel rather than patches. It'd be like the "super bake" since it may take a while, but, it might give the most precise output

[jdolan]

I mean.. quemap -light --patch-size 4 maps/fragpipe.map

[Panjoo]

I can't compile this stupid map without having to wait for way too long and I'm starting to get frustrated again. I'm already using this snapshot https://ci.appveyor.com/project/Paril/quetoo The compiler seems amost stuck at the second "Indirect lightmaps" stage. First one also take like 4 minutes. You keep showing screenshots of the old version, can you try it with the files I attached?

fragpipe-newfiles.zip

[jdolan]

Here's your version of the map in my current WIP branch that addresses light bleed:

quemap -bsp -light --radiosity .5 maps/fragpipe-new.map
...
Lighting maps/fragpipe-new.bsp

Loaded 40 materials from maps/fragpipe-new.mat
WARNING: LoadMaterial: Failed to resolve fragpipe/ggrat4_2add
Building patches         [100%] 59 ms
WARNING: LightForEntity_light_spot: Entity 128, Brush 0: light_spot at (1536.00 560.00 248.00) missing target and _angle
WARNING: LightForEntity_light_spot: Entity 129, Brush 0: light_spot at (288.00 1352.00 352.00) missing target and _angle
WARNING: LightForEntity_light_spot: Entity 130, Brush 0: light_spot at (1856.00 1416.00 164.00) missing target and _angle
WARNING: LightForEntity_light_spot: Entity 131, Brush 0: light_spot at (1216.00 1416.00 164.00) missing target and _angle
WARNING: LightForEntity_light_spot: Entity 132, Brush 0: light_spot at (512.00 1352.00 352.00) missing target and _angle
WARNING: LightForEntity_light_spot: Entity 133, Brush 0: light_spot at (400.00 1352.00 352.00) missing target and _angle
WARNING: LightForEntity_light_spot: Entity 152, Brush 0: light_spot at (1536.00 752.00 248.00) missing target and _angle
WARNING: LightForEntity_light_spot: Entity 162, Brush 0: light_spot at (1536.00 1112.00 332.00) missing target and _angle
Direct lightmaps         [100%] 12907 ms
Direct lightgrid         [100%] 513 ms
Indirect lightmaps       [100%] 8444 ms
Indirect lightgrid       [100%] 374 ms
Caustics lightmap        [100%] 982 ms
Caustics lightgrid       [100%] 145 ms
Fog volumes              [100%] 141 ms
Finalizing lightmaps     [100%] 118 ms
Finalizing lightgrid     [100%] 49 ms

Lit maps/fragpipe-new.bsp in 24668 ms

quemap finished in 26556ms

...

The lighting looks a bit flat (too large a sun size, with the fixes I made, and too high an ambient value maybe?), but compiles in 25s and looks reasonable (no artifacts).

We've already identified there are issues with indirect light. I don't know why it performs so badly for you, but just don't bother with it for now :) You can rough-in the lighting with --no-indirect until I can merge this branch in.

[Paril]

I'm not sure either - I ran it on my end just to make sure that I wasn't missing something:

Direct lightmaps         [100%] 4299 ms
Direct lightgrid         [100%] 141 ms
Indirect lightmaps       [100%] 2749 ms
Indirect lightgrid       [100%] 87 ms
Caustics lightmap        [100%] 358 ms
Caustics lightgrid       [100%] 31 ms
Fog volumes              [100%] 27 ms
Finalizing lightmaps     [100%] 39 ms
Finalizing lightgrid     [100%] 22 ms

Lit maps/fragpipe-new.bsp in 8325 ms

C:\quetoo\bin\quemap.exe finished in 10036ms

I was missing a grate texture but other than that.. indirect has never taken longer than direct for me so I dunno

[Panjoo]

missing-tex.zip

This lighting is just temp and experimental, and flat, yes. When I picked the colors I had my ingame contrast setting at 1.1 Also, I don't have the light-fixing snapshot yet. So far I found that picking the right ambient is everything. You can have all else in place and totally ruin a map's atmos with the wrong amb values. In other maps I wasn't happy with the atmosphere until I made tiny changes to the ambient and it immediately looked better. It's rather tricky to get it right, dunno what it is. Compiling with just the sunlight (so no ambient) shows almost no light. So the ambient basicly decides the entire feel.

quemap -bsp -light maps/fragpipe-new.map
Building patches         [100%] 30 ms
Direct lightmaps         [100%] 86570 ms
Direct lightgrid         [100%] 2797 ms
Indirect lightmaps       [100%] 51987 ms
Indirect lightgrid       [100%] 1546 ms
Caustics lightmap        [100%] 9822 ms
Caustics lightgrid       [100%] 263 ms
Fog volumes              [100%] 160 ms
Finalizing lightmaps     [100%] 553 ms
Finalizing lightgrid     [100%] 21 ms

Lit maps/fragpipe-new.bsp in 155756 ms
quemap finished in 161173ms

And now all of a sudden it compiles as it did before. Still slow on this old PC... but not 61 minutes like yesterday. Go figure. However, I see the same uneven lava light problem in this spot, just looks weird: quetoo070

(Edit: oh yea duh, no surprise it still looks the same... lol)

[Paril]

Yeah, his fix will be merged in soon. Probably today.

[jdolan-chwy]

Yea, sorry Pan. In my update last night (zzzz) I forgot to mention that I haven't merged these changes in yet. They are just sitting on my hard drive while I continue to work on them. Sorry.

[Panjoo]

No problem.

In case you think I'm imagining things (always a possibility) now check this out. Upon compiling fragpipe again with a different and lower ambient, the light compile just seems to repeat the Indirect lightmaps stage... The 3rd time it starts with Indirect lightmaps it takes for ever and I have to cancel it.

double-lightmaps

[jdolan-chwy]

Oh what the F!? What does your command line look like? OH! You are running --bounce aren't you? Yea.... that will absolutely destroy your compile times 🤣 You're effectively building up stronger and stronger lights, and pointing them at each other 🤣. That code path needs some work...

[Panjoo]

quemap -bsp -light --bounce 3 maps/fragpipe-new.map

(!) but it also happened without adding --bounce.

Edit: Well, I knew --bounce affects compile times, but I've compiled so many times with and without it, and the way it repeats itself is not always the case.

[jdolan-chwy]

I don't think that's true. I'm quite certain that you'll only see multiple passes of Indirect lightmaps.. with --bounce. I have never seen it (I never use --bounce), and I have baked our maps hundreds of times in the last couple of months.

[Panjoo]

If you dont use --bounce you won't see it, but I mean that I've also compiled hundreds of times with bounce, and it never seemed to take so long on the 2nd and 3rd pass as with fragpipe before.

Edit: you're right about it repeating the indirect lightmaps stage due to that bounce setting. But as I said, sometimes it just seems to completely hang and other times it's "fast".

Now this is tested with and without --bounce, which obviously doesn't work and it apparently also caused the uneven lava lighting? I think this is a bit of a problem, I know it's under development but I kind of expect these lighting tools to work when I try to use them. I want my money back!

With bounce 2 - LOL: with-bounce2

Without bounce: without-bounce

[jdolan]

I might kill off --bounce. I'm not sure it really makes sense for us, and it's clearly quite broken.. Would this bother you? Assuming we have a properly working single-pass indirect lighting run, of course..

[jdolan]

Okay, here goes:

quetoo015 quetoo016 quetoo017 quetoo018 quetoo019 quetoo020 quetoo021

These are all using the unmodified fragpipe.map that is in Git. No changes to the map or materials have been made at all. Things that are fixed:

Background: since we added the _size code over a year ago, every light source is actually a collection of points, not just a single point. I refer to these as "sample points." This enables a lot of nice looking effects, but complicates the code.

1. Light bleed. This was due to the old light _size code that generated sample points around the light origin. This code checked each point for solid / not solid, but did not run a trace from the light origin to the sample point. So if a sample point got projected through a wall into a valid position, it would still be used. This is no longer the case. I trace from the light origin to each light sample point to ensure it is valid.
2. Indirect lights no longer light their neighbors. There was already a check to not self-light. But because patch lights project their sample points out a few units from the wall, they were actually lighting their neighbors. This was the cause of the "Why is the red light climbing all the way up this wall?" and also "Why is this large floor peppered in hot spots?"
3. Patch size deficiencies. The old code calculated attenuation from the light origin, not from the light sample point in question. This resulted in hot spots and cool spots near large face lights, and required you to dial patch_size down to get nice looking face lights. The new code now correctly calculates attenuation based on the actual light sample point being checked.
4. Sunlight now diffuses correctly, and does not require a massive _size to do it. The old code pushed the sun origin MAX_WORLD_DIST away, so even a _size of 512 units wasn't going to produce much variation. Sun _size now kicks in at a distance of 1024 units, and so even the default sun _size of 32 units produces nice soft edges. You can crank this up to get nice looking penumbrae.

Optimizations:

1. For point lights, spot lights, patch lights and indirect lights: rather than calculating sample points over and over for every single luxel, I calculate these up front when the light is created. For sun lights, I calculate a bouquet of directional vectors.
2. When lighting a luxel, the light sample points are first sorted by distance, and tried in order. The first sample point with a successful trace is used, giving the best possible attenuation for that luxel. If we reach a sample point for which the luxel is out of range, we can break early.
3. For patch and indirect lights, use the face plane to perform a sidedness check against the luxel origin. This allows us to skip a ton of traces.
4. Kind of covered in fixes above, but, by not lighting coplanar neighbors, indirect lighting got a nice boost.
5. Don't bother antialiasing indirect lighting. It's just not necessary.

The bake you're looking at is a full compile (quemap -light --antialias maps/fragpipe.map) and took 129s on a 5 year old laptop.

[jdolan]

These fixes and a few more are now in develop @Panjoo, so you can update your snapshot. A couple notes:

1. You've probably already figured this out, but when I added CONTENT_ATMOSPHERIC for fog, so that fog would not eat mist (decals), some maps had fog volumes on them that were explicitly set to CONTENTS_MIST. Hallways, Slimy Place, Rage and Lava Tomb all have this issue. Those fog volumes should just be cleared of all contents so that quemap can auto-set them to atmospheric based on the texture name common/fog.
2. You may find that radiosity levels need adjusting (likely down). This is because, despite my efforts to not change the actual lighting model while addressing these bugs, some changes were a consequence of fixing these bugs. I would recommend trying different -light --radiosity .666 type values until you find what looks good, and then you can just tuck that radiosity value into worldspawn.
3. With the latest batch of changes, the default patch_size is now 128. This speeds up direct lighting (if you're using face lights) and dramatically speeds up indirect lighting. I'm able to compile Edge in 20 seconds. Hopefully you see a nice performance bump here, and recompiling these maps to tune lighting isn't as tedious as before.

[jdolan]

Also, @Panjoo, I just became aware of an issue compiling Lost Hallways, Gehenna, Slimy Place, etc.. a lot of these were crashing due to some of the contents and visibility changes made a couple weeks ago. With @Paril 's help, I got those fixed as well. So.. apologies if those were giving you a hard time. I didn't realize there was a regression until this morning. But you should be able to cleanly compile all of our map files with the latest snapshot.

[jdolan]

Oh! One more thing. I fixed face lights on inline models. Lights on brush models will not light the world (or the light grid), so you can put that little light back on the func_train if you want to. It will only light the train itself.

However, the func_waterin the Frag Pipe is an example of where we were benefiting inline models lighting the world. You'll notice that, now, the inside of the pipe is not glowing red as it was before. You can just add some red point lights inside the pipe to achieve that effect again.

Lmk if this works for you, or if you feel it should be reverted. Either way, I think light-emitting-brush-models are kind of a rare thing. I can't think of another map besides Frag Pipe that has one, nevermind two!

[Panjoo]

Excellent, I'm glad you guys are able to fix and improve these things. Thanks for the info and tips, will save it all in a document with the rest. I will be experimenting with lighting (values) until things feel just right again. I'm sure I can get these maps looking better, including some texture upgrades. Some already do but no spoilers yet.

(Note that in that old fragpipe it still has global fog, which makes things look brighter and more colored than it really is. For some reason the newer global fog looks different than the old global fog, which seemed to adjust to distance. Can't really put my finger on it, but it doesn't look like it's adjusting, the thickness only decreases when you move closer to solid objects. You really need super low values and even then it just looks like a hazy layer on every surface. I don't think I'll be using it in many maps, at least not in the smaller ones, the local fog volumes on the other hand look great and are a real asset.)

One last question for now. In the entdef it says: radiosity : Global indirect light scale, a single positive scalar value (e.g. 1.675) But what does it do to the lighting, in lay terms?

Do you mind if at some point I clean this thread up a bit, and hide some of the screenshots?

[jdolan]

Yea we should probably reimplement basic global fog instead of the global volumetric stuff. It would look and perform better. I’ll open a ticket. It shouldn’t be much work.

Radiosity, in layman’s terms, is one method for scattering light to make it look more natural. What our implementation does is turn every single face in the map that received direct light, into an indirect light source. It’s literally the equivalent of setting SURF_LIGHT on every single face, but with a small value. The light color is a 50/50 mix of the incoming light color and the face material color. So a green face receiving white light will emit green light. A blue face receiving red light will emit purple, etc. The radius of the indirect light is based on the intensity of the incoming direct light. The global radiosity scalar is just a multiplier for indirect light radius. That’s how it works. Pretty simple really.

The default radiosity scalar is 1.0, which means that the light received is reflected in equal intensity. That’s not very realistic, and looks artificially bright in my opinion. So that’s why I suggested the 0.666 as a good starting point for some subtle but pleasant and natural looking indirect light.

[Paril]

The main benefit to the global volumetric one is being able to take advantage of noise. Tokays for instance looks really good with the hazy fog spots. Unfortunately it also doesn't look great at distance since it only samples so far ahead of your view, so it's better for short range fogging.

Both can co-exist, which I think is the better solution.

[jdolan]

@Panjoo Are you tackling more than just q2dm* right now? Are you updating Grunt, OMF, Aerowalk, Chastity, etc as well? Just looking to coordinate and not duplicate effort.

[Panjoo]

Yes, basicly I'm switching between multiple maps back and forth, comparing things and making sure the materials of shared textures are using the same surfacelight numbers. I'm making good progress but I'm also trying to get some sort of uniformity going in the maps in terms of light values. Like for instance setting brightness 2 in the worldspawn for all maps. Also in a couple maps I found textures that really needed attention or even complete redoing like this, and some of the skyboxes and water textures needed work. Usually it is this texture finetuning that is the hold-up, but this is almost done and I can begin packing some pk3's.

[jdolan]

Would you find it helpful if we had the ability to provide common texture material files and then include them by name in map-specific material files? In other words, have e1u2.mat and then edge.mat has an

#include “e1u2.mat”

At the top? Just something I have considered over the years but never built. It would allow us to reuse common texture sets more easily (q4power, Rygel, ..). We could bundle the shared mat file up with the textures themselves in textures-q4power.pk3.

We don’t have to do any of this. It’s just something that has crossed my mind.

[Panjoo]

It could be helpful to have common texture material files as long as the sets have good _normals and are tuned right.

I personally prefer to be able to tune anything if desired, instead of working with presets. Not sure if that would still be possible when it's bundled with a pk3. But if the map's own .mat file is going to override anything from a shared .mat file, then I'd say do it.

[jdolan]

@Panjoo Just a heads-up that I pushed a change in our fog shader that attempts to address just how volatile our fog volumes are. The way the shader works now, is it scans a the lightgrid for fog every 32 units, and takes the most dense sample that it finds as that pixel's fog value. Previously, the shader added up all samples for each pixel and averaged them. The problem with that approach is that fog will almost disappear at a distance, and will be nearly opaque up close. I'm sure you noticed this.

Now that we have old-school global fog, our volumes are mostly for smaller areas, and are meant to limit visibility or add ambience. I think this technique accomplishes that much better. However, you may find that existing fog volumes need tweaking to look good. Dropping the density of the fog volume is probably all that is required.

Here's the difference. Before, with averaged samples:

And after, with max sample:

Clearly, the 2nd shot shows the fog more visibly. But what you can't really see from a static screenshot is that the fog looks exactly like that at all angles and distances, inside the volume as well as outside of it. It's a very nice effect, imo, and suits are needs better.

[Panjoo]

...fog will almost disappear at a distance, and will be nearly opaque up close. I'm sure you noticed this.

I did, it just looked unnatural before, that's why I rather had old-school global fog back.

...what you can't really see from a static screenshot is that the fog looks exactly like that at all angles and distances, inside the volume as well as outside of it.

It sounds like a very good change. I haven't had the chance to actually test and study this yet, but I will. I think I've mentioned this before but these local fog volumes are a real asset in a mapdesigner's toolkit.

[Panjoo]

Found something else but I don't know if this is from this change. I noticed that my light_sun values need adjusting again, the _size and light values appear to have been affected. Overall my sun light spots look somewhat dimmer and softer than before, so something definitely changed.

[jdolan]

Yes sunlight was basically not attenuated correctly in some of the recent snapshots. It was basically all or nothing. You may have noticed that even small sunlight values like 10 produced full bright results. So I fixed that I think Tuesday or Thursday. Sorry!

[Panjoo]

Okay, next problem...

In Edge I'm trying to use my fern model that I made as mapobject, but after some of the changes the lighting on this mapobject is different now and not for the better. Looks kind of fake and out of place now. Almost as if the bottom sides of the leaves are not receiving light. Not even if I shove a light-entity underneath, and not with a higher worldspawn radiosity setting. See the difference in these old and new screens:

older light compile: miscmodel-light recent light compile: miscmodel-light2

[jdolan]

Well, I did fix sunlight being full-bright the other day, so it would make sense that these are darker now. But I agree that the 2nd shot looks a little too dark. The leaves seem darker than the ground behind them.

Can you r_draw_bsp_lightgrid 1 and attach those screenshots? I wonder if the sun light direction is to blame.

[Panjoo]

I've tested other sun angles, without much improvement. But here is that previous testmap again; miscmodel.pk3. This still has _size 384 in worldspawn, so you might want to change the settings.

[jdolan]

Hm. I dunno. This actually looks 👌 to me. I deleted the _size key from the sun and baked the map locally to check.

[Panjoo]

Suddenly I see what is up... I am still compiling with-light --no-indirect - mainly because of the lava light errors that I was fighting in fragpipe. (My bad, this is probably not a bug so I'll delete this from the comments later on to keep it clean.)

Although, compiling with default indirect light does have strange behaviour in some spots as seen in this image from a newer version of fragpipe, that only uses one sun with a straight down angle;

[jdolan]

Makes perfect sense. The sunlight is being reflected off of the tops of those beams. It looks a bit unnatural just because it’s too bright. This is why I suggested a radiosity value of ~.666 as a reasonable starting point.

[SpineyPete]

We do have angular attenuation (spotlight falloff) on patches, right?

[jdolan]

We do not, actually. Think we should?

[SpineyPete]

Yeah, spotlight style dot product where the surface normal is the direction. That's probably going to change the look of the maps a bit. Can't imagine it being worse though.

[SpineyPete]

Fwiw iirc it was set up that way on Void's prototype.

[Panjoo]

This is why I suggested a radiosity value of ~.666 as a reasonable starting point.

That screenshot with the beams is from a compile with a lowered radiosity of .07 as suggested. Perfect sense or not, at first glance it looks like a lighting error to me. I didn't realize the radiosity effect would still be this strong at 0.7

But... I've now set it to 0.3 ( 0.4 also works) and it looks a lot more natural, and it also removed some of the unwanted red spots as seen in this screenshot below. The red light is perfectly horizontal and above the walkway, and I didn't expect it having to do with the radiosity, I mean the lava light is coming from below, why would it be reflected there?

[jdolan]

I added spotlight-style angular attenuation to indirect patch lights, per @SpineyPete 's suggestion, and those artifacts are gone. This is with radiosity 1. I added the code path for angular attenuation for direct patch lights as well, but did not enable it, as I think it changes the lighting model too much and would frustrate you 😁

[Panjoo]

Nice one, another improvement.

I added the code path for angular attenuation for direct patch lights as well, but did not enable it,

Ehm, by direct you mean no-indirect? It's starting to confuse me.

-light = indirect lighting (the default) -light --no-indirect = direct lighting

Other than shortening compile times and bypassing these sort of artifacts, would there be any reason for a mapper to use --no-indirect?

[Paril]

It'd be used for "fast" compiles - sort of like how you'd omit -bounce in Q1/Q2 tools.

He means "direct patch lights" as in non-bounced surface lights. Any direct light comes directly from the source; indirect comes from bounces.

[jdolan]

That's true, skipping indirect lighting has historically been a "fast bake" option. But now, --no-indirect is really meant for debugging purposes. Our compile times are so damn fast, that I'm hard-pressed to recommend --no-indirect as a "fast bake." Maps look so much better with it indirect lighting, and the indirect lighting pass always takes less time than the direct lighting pass anyway (unless you crank radiosity up to 2 or something).

Basically, at this point, I use --no-indirect to see which pass is creating problems 😁

But to @Paril 's point, he's correct. We have two kinds of patch lights:

1. Direct patch lights (SURF_LIGHT) set by the mapper via surface inspector or materials.
2. Indirect patch lights; every face that received light in the direct pass becomes a SURF_LIGHT for the indirect pass.

I enabled spotlight attenuation on indirect patch lights only. The code is also there to turn it on for direct patch lights, but it makes the maps a good bit darker, because we are mostly using patch lights, and with this change, they cast less light! So I think it's best to leave direct patch light behavior unchanged.

[Panjoo]

Thnx, it's all clear to me now.

[jdolan]

Btw @Panjoo, I'm not sure if you follow the commit logs, but yesterday I added a debugging tool you might find helpful: r_draw_bsp_lightmap. Setting it to 1 will show you diffuse + ambient + radiosity, setting it to 2 will show you light direction. On mesh models, it will show you the same values, but from the lightgrid.

If you use it in conjunction with r_texture_mode GL_NEAREST you can see exactly how each luxel was lit.

[jdolan]

@Panjoo FYI, I'm going to add in "auto-Phong" functionality in quemap that will automatically apply smooth shading with a per-material tolerance value. This will eliminate the need for painstakingly setting SURF_PHONG on most rounded objects. The threshold will be a simple scalar (0.0-1.0) and configurable per material, so if you want to disable it, or force it to always on, you can do that. The actual brush side surface flags will override, so you can disable auto-Phong in the .mat file but still enable it per-face if that's desired.

Basically, I was looking at Jester's gothic map and thinking.. there's no way I'm going to correctly Phong this in Radiant 😝

Let me know if you have any concerns about this feature. I should be able to knock it out in the next evening or two.

[Panjoo]

At this point I don't know about extra features when maps are almost done. But as long as it can be disabled I'm fine with anything that can help simplify the process. Right now I have more concerns about the playabilty the game, again, ie. the fps performance. (see the buglist at the top).

[jdolan]

Flares are drawn without the depth test. This works mostly well on solid, opaque geometry. But clearly has issues when the player can occupy opaque geometry. We'd see the same issue with CONTENTS_MIST. We should probably re-enable the depth test for flares. I don't think this is a big deal and will get to it soon.

The sprite effects on water are expensive, and they could still use some optimization for sure. They are white nuclear blobs because there are too many ripples being spawned there. And that's also why they are tanking your framerate. No need to panic 😁

cl_max_fps 0 (the default) matches the soft framerate cap with your vertical refresh rate. This is the most desirable configuration for most systems. It provides a soft cap that reduces tearing, without incurring the input latency penalty of vsync. You can set cl_max_fps -1 to disable all capping and see what your max framerate actually is.

Your other FPS observations are interesting. Do any of the following dramatically affect your performance?

r_fog_density 0 r_bloom 0 r_draw_material_stages 0 r_blend_depth_sorting 0

Do any of these move the needle for you?

[jdolan]

Side note, I think translucent water with fog and material stages looks so much nicer than opaque water. You end up with some really nice light interactions between the lightmapped water surface and light-absorbing volumetric fog. Just my $0.02.

Also, my new favorite trick is adding misc_dust underwater to emit bubbles rising from the deep. I'm doing this on my Cistern remake, but it would look good on Edge, Tokays, Pits, and Hallways, too..

// entity 58
{
"lighting" ".666"
"_end_color" "0 0 1 0"
"_color" "0 0 1 1"
"density" "6"
"_size" ".5"
"acceleration" "0 0 -.2"
"lifetime" "3.2"
"velocity" "0 0 28"
"sprite" "bubble"
"classname" "misc_dust"
// .. brushes
}

You can tweak acceleration and lifetime so that the bubbles expire as they reach the surface.

[Panjoo]

I agree it may look nicer but on certain maps it negatively affects the gameplay. I know this because I still play the Q2 versions of these maps on a regular basis and I want to deliver truthful remakes. If all water is translucent it's going to take away the element of surprise. Combined with the too slow player movement in water (it barely lets you move side to side) I don't think it's a good choice to make it so that you won't be able to hide in the water or pop out of it by surprise. Especially in Edge, Pits and Hallways. Perhaps thick fog might work, but then it should not be too expensive.

If normal water without any extra fx is already making things run slow I don't think I want to play around with more fx stuff like fog and bubbles at this point.

Your other FPS observations are interesting. Do any of the following dramatically affect your performance? r_fog_density 0 / r_bloom 0 / r_draw_material_stages 0 / r_blend_depth_sorting 0

Hmm, none of them seem to make a noticeble difference. It's too late now but I'll do some more testing tomorrow.

Been getting some other errors that I've never seen before, probably due to mangled brushes;

R_Debug_Callback: OpenGL (API; Medium) Performance [id 131218]: Program/shader state performance warning:
Vertex shader in program 11 is being recompiled based on GL state. 
 source: > R_DrawSprites (r_sprite.c:501)

[jdolan]

Fog is a constant cost. Whether there are 0 volumes on a map, or 1000, the same exact calculations are performed. You can see what impact fog has by setting r_fog_density 0 to entirely disable the feature, or by playing with r_fog_samples, where higher values will slightly improve quality but reduce frame rate. But again, individual fog volumes do not affect performance at all. Material stages are more efficient than they were in all previous iterations of the engine, too, so I wouldn’t shy away from those.

I’ll spend some time digging into performance issues this weekend. What resolution do you run at, btw, and are you on a 4K display?

[SpineyPete]

Yeah the water ripples are a bit of an FPS killer, I'll have to redo them and see if I can reduce the overdraw and limit the rate at which they spawn. Like MG for instance probably spawns too much and too large ones, LG is even worse. Just limiting the spawn rate and size might be sufficient, alternatively I could just try to make the effect look different and take less surface area (always open to suggestions / inspiration from other games). The hyperblaster impacts were another one that were a bit of a hog before, but for me at least this seems to have been resolved.

[Panjoo]

Yes, for a while now I've been using bind "f" "toggle r_fog_density" to check how the density looks compared to no fog at all. Same with bind "c" "toggle r_caustics"

As far as I can tell it's not the fog that has the most impact, but it's translucent liquid volumes and things like (blended) window textures that are eating a big chunk out of my overall fps. I don't have all that much to spare so yeah, every significant drop makes me frown. I'm just surprised that even one body of translucent water has this much impact.

What resolution do you run at, btw, and are you on a 4K display?

Hah! Wouldn't that be enormously newbish? Reporting about bad fps in "great panic" while using a 4K display on a PC with 2GB vidcard that's already struggling to get a constant 200 fps in boxmaps in Quetoo? I'm running at 1680x1050 resolution on a 22", but I was already thinking about switching to 1440x900, that should make some difference I'm sure, but still.

Is there a way to add borders? That's how I usually like to play anyway, since I prefer smaller views for fast games. cl_view_size_down and cl_view_size_up stopped working long ago.

[Panjoo]

... see if I can reduce the overdraw and limit the rate at which they spawn. Like MG for instance probably spawns too much and too large ones, LG is even worse. Just limiting the spawn rate and size might be sufficient,

The textures are quite good actually, there's no need to edit them I think. But I doubt we need so many images in sequence to make a convincing splash. I'm counting 75 splash images... I'm thinking a combination of limiting the spawn rate and less 'animations' will be sufficient.

[SpineyPete]

It's good you reminded me about the amount of frames. Actually those textures were originally made for a railgun impact, which had a much longer animation and I tried to keep all animations around 20-30 fps to make them look smooth, but that's obviously too much for this one, so I can probably cut those considerably.