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 _puffcloud 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 _alphatest 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 _funcplat: 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. _functrain: 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]

Yeah, I remember this working at some point in Edge because I've definitely tested bots being squished. I can add a crusher flag for doors to match Q2 and for use in Frag Pipe.

[Panjoo]

Sure, sounds good. Even though not a lot of maps have doors in them it would be nice if they matched Q2's doors.

[Paril]

So I kind of narrowed the platform issue down, but I'm not sure why it's happening yet. When the platform first does damage to you, it's moved back into the old position like normal and is set to reverse, but then when pmove runs for some reason the player is intersecting the platform by this point, so the platform just keeps crushing the player going back & forth. I don't know exactly why it says it's in a good position but is not in a good position when the player tries to move next.

[Paril]

I fixed the platform behavior; with regards to crusher, I realized, can't you just set the dmg of the doors in Frag Pipe to like 99999? That would work well enough. If you don't want it to be an instant kill and you're able to wiggle out of it still I can add CRUSHER as a flag still, but let me know if that's a good enough solution (I like the idea of the murdoors, though)

[Panjoo]

I fixed the platform behavior; with regards to crusher,

Does this mean I can now set an optional crusher flag on plats, and if I don't they won't crush? What spawnflag number do give them if I want to set them to 'crush'?

can't you just set the dmg of the doors in Frag Pipe to like 99999? That would work well enough.

The doors in the original Q2 map kill the player instantly, as they should. The dmg of the doors is already set to 1000, which should be more than enough to make it do what it needs to do. The problem I'm having is not that they don't kill the player instantly, it's that after the player dies the doors just bounce back while they should close off the pipe. Same happens if a gib is stuck between the doors.

<fragdoors.zip> Here is a test map + bsp, of just the fragpipe, literally just the pipe with the doors. I've set the doors to have a 1 sec delay before closing so you can position yourself on the door.

[Panjoo]

During the lighting compile stage, I see this:

indirect bounces 1

... I'm guessing this is not the same as the deprecated radiosity and the now also deprecated indirect_brightness?

How do I change this in worldspawn? How do I change the spread and intensity of this bounced lighting? Setting indirect_intensity to 0.1 doesn't seem to make these spots less intense.

[Paril]

I fixed the platform behavior; with regards to crusher,

Does this mean I can now set an optional crusher flag on plats, and if I don't they won't crush? What spawnflag number do give them if I want to set them to 'crush'?

can't you just set the dmg of the doors in Frag Pipe to like 99999? That would work well enough.

The doors in the original Q2 map kill the player instantly, as they should. The dmg of the doors is already set to 1000, which should be more than enough to make it do what it needs to do. The problem I'm having is not that they don't kill the player instantly, it's that after the player dies the doors just bounce back while they should close off the pipe. Same happens if a gib is stuck between the doors.

<fragdoors.zip> Here is a test map + bsp, of just the fragpipe, literally just the pipe with the doors. I've set the doors to have a 1 sec delay before closing so you can position yourself on the door.

They should be the same as the old behavior now. If you want a crusher flag I can add one, but it's really hard to get out of a platform that is crushing you so I don't know if people would enjoy it very much.

Ah, it's a bug that the door is going back then. It should be continuing without blocking after killing the player. I'll revisit that behavior as well.

[jdolan]

Pan, indirect_intensity was broken but is now fixed. I also clamped indirect light radius to be at least patch_size. This way, indirect lights will overlap and not create weird hot spots.

[Panjoo]

Paril: -They should be the same as the old behavior now. If you want a crusher flag I can add one, but it's really hard to get out of a platform that is crushing you so I don't know if people would enjoy it very much.

Good point. If you can fix it so that the doors continue after the kill-dmg then I guess I won't be needing a crusher flag at all.

jdolan: -Indirect_intensity was broken but is now fixed. I also clamped indirect light radius to be at least patch_size. This way, indirect lights will overlap and not create weird hot spots.

I see, I'll update my snapshot. Btw, I noticed in entities.def there now is a bounce key in worldspawn. What is the difference between using this vs indirect_intensity? Won't a higher bounce automatically increase the intensity?

[jdolan]

Nope, bounce will allow you to specify how many indirect passes you want. You can bounce light more than once this way. It's the same as the --bounce command line option. Some maps benefit from 2. I haven't seen a difference going higher than 2, since each pass only bounces the light from pass before it. It's kind of a diminishing returns thing. But Claustrophobopolis looks slightly nicer with 2, for example.

[jdolan]

Pan, in the latest snapshot you will notice a few changes / enhancements:

1. With last week's lighting model improvements, I felt like it was the right time to enable angular attenuation (spotlights) for direct patch lights. By default, they have a rather wide cone that looks believable for most surface lights, and also eliminates the weird artifacts on their immediate neighbors, or when they are recessed. I arrived at this cone size by testing several of our maps, and I think the results look pretty awesome.
2. The spotlight cone can be specified in the material definition if you do want to tune it (or disable it) for certain textures. The material key is light.cone and it's specified in degrees, just like light_spot. The default is 75, and 90 will effectively disable the effect (previous behavior).
3. I'm now baking two separate "channels" of diffuse light, as opposed to one. Previously, I mixed incoming light color and direction for each luxel into a single value. This is why, when light sources overlapped, you would see "specular worms" and other odd artifacts. It's because you were seeing two different directions averaged together. It made no sense, in terms of physics. With the new implementation, I store the strongest light source in the first channel, and the second strongest in the other channel. All other light sources are then mixed into the one they are most directionally aligned with. If they are not directionally aligned, they are simply merged into the ambient color for that luxel. The result is that you can now have overlapping light sources that produce two separate, visually correct specular highlights and bumpmapping effects. It's pretty cool to see in action. Screenshots don't really do it justice.
4. I found a rather big optimization in my light hashing code that greatly reduces the number of light sources each luxel must consider. It brought Torn Glory down from 11s to 6s on my machine. The biggest gains are in the indirect lighting stage.

None of these changes should require you to tune maps much or at all -- they should just magically look better the next time you bake them :)

[SpineyPete]

Was curious to see how it looks. Got a memory allocation failure on Edge.

C:\Users\Eigenaar\Documents\GitHub\quetoo-build\bat>C:\Users\Eigenaar\Documents\GitHub\quetoo-build\bin\Quemap.exe -p "C:\Users\Eigenaar\Documents\GitHub\quetoo-data\src\default" -bsp -light -mat edge
Quemap 0.1.0 i686-pc-windows unversioned
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-build\lib..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-build\share..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-build\lib\default..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-build\share\default..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-build\share\default\map-claustrophobopolis.pk3..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-build\share\default\map-darkzone.pk3..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-build\share\default\map-edge.pk3..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-build\share\default\map-fractures.pk3..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-build\share\default\map-fragpipe.pk3..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-build\share\default\map-gehenna.pk3..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-build\share\default\map-hallways.pk3..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-build\share\default\map-lavatomb.pk3..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-build\share\default\map-pits.pk3..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-build\share\default\map-rage.pk3..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-build\share\default\map-sandbox.pk3..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-build\share\default\map-slimyplace.pk3..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-build\share\default\map-tokays.pk3..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-build\share\default\map-torn.pk3..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-build\share\default\map-warehouse.pk3..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-build\share\default\player-bunker.pk3..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-build\share\default\player-dragoon.pk3..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-build\share\default\player-gork.pk3..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-build\share\default\player-guard.pk3..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-build\share\default\player-qforcer.pk3..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-build\share\default\textures-common.pk3..
Adding path C:\Users\Eigenaar\Documents\My Games\Quetoo\default..
Using C:\Users\Eigenaar\Documents\My Games\Quetoo\default for writing.
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-data\src\default..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-data\src\default\map-2deaths.pk3..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-data\src\default\map-aerowalk.pk3..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-data\src\default\map-aggressor.pk3..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-data\src\default\map-aghast.pk3..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-data\src\default\map-backup.pk3..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-data\src\default\map-catfight.pk3..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-data\src\default\map-chastity.pk3..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-data\src\default\map-cistern.pk3..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-data\src\default\map-construct.pk3..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-data\src\default\map-darkzone.pk3..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-data\src\default\map-devolver.pk3..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-data\src\default\map-diesirae.pk3..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-data\src\default\map-dimpact.pk3..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-data\src\default\map-fractures.pk3..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-data\src\default\map-gehenna.pk3..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-data\src\default\map-grunt.pk3..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-data\src\default\map-gym.pk3..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-data\src\default\map-impact.pk3..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-data\src\default\map-lilith.pk3..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-data\src\default\map-necropolis.pk3..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-data\src\default\map-omf.pk3..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-data\src\default\map-place2deaths.pk3..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-data\src\default\map-rage.pk3..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-data\src\default\map-spacectf.pk3..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-data\src\default\map-trial.pk3..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-data\src\default\map-turbo.pk3..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-data\src\default\map-wake.pk3..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-data\src\default\map-darkzone.pk3..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-data\src\default\map-fractures.pk3..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-data\src\default\map-gehenna.pk3..
Adding path C:\Users\Eigenaar\Documents\GitHub\quetoo-data\src\default\map-rage.pk3..
Quemap 0.1.0 i686-pc-windows unversioned initialized
Using 12 threads

------------------------------------------

Generating maps/edge.mat for maps/edge.map

Loaded 57 materials from maps/edge.mat
Wrote 57 materials to maps/edge.mat

Generated 71 materials in 533 ms

------------------------------------------

Compiling maps/edge.bsp from maps/edge.map

Loaded 57 materials from maps/edge.mat
Emitting entities        [100%] 4 ms

worldspawn @ (0.00 0.00 0.00)
Creating brushes         [100%] 10 ms
Subtracting brushes      [100%] 181 ms
Building tree            [100%] 1856 ms
WARNING: FindPortalBrushSide: Winding with center (2743.96 904.50 815.00): Brush side not found for portal
WARNING: FindPortalBrushSide: Winding with center (2743.96 904.50 879.00): Brush side not found for portal
WARNING: FindPortalBrushSide: Winding with center (2743.96 904.50 879.00): Brush side not found for portal
WARNING: FindPortalBrushSide: Winding with center (2743.96 904.50 815.00): Brush side not found for portal
Fixing t-junctions       [100%] 223 ms
Emitting nodes           [\]WARNING: Cm_ElementsForWinding: Invalid winding: 2 corners found in 3 points
WARNING: EmitFaceElements: Winding with center (1435.39 886.78 710.11): Face has degenerate winding
Emitting nodes           [100%] 344 ms

func_plat @ (0.00 0.00 0.00)
Creating brushes         [100%] 0 ms
Subtracting brushes      [100%] 1 ms
Building tree            [100%] 2 ms
Fixing t-junctions       [ 96%] 2 ms
Emitting nodes           [100%] 4 ms

func_plat @ (0.00 0.00 0.00)
Creating brushes         [100%] 1 ms
Subtracting brushes      [100%] 1 ms
Building tree            [100%] 7 ms
Fixing t-junctions       [ 99%] 6 ms
Emitting nodes           [100%] 4 ms

Phong shading            [100%] 401 ms

Compiled maps/edge.bsp in 3907 ms

------------------------------------------

Lighting maps/edge.bsp

Loaded 57 materials from maps/edge.mat

Lighting parameters
  Brightness: 2.5
  Saturation: 1
  Contrast: 1
  Ambient intensity: 1
  Sun intensity: 1
  Light intensity: 1
  Patch intensity: 1
  Indirect intensity: 1
  Caustics intensity: 1
  Luxel size: 4
  Patch size: 128
  Indirect bounces: 1

Building patches         [100%] 14 ms
WARNING: LightForEntity_light_sun: Entity 114, Brush 0: light_sun key light is deprecated. Use _intensity.
Direct lightmaps         [100%] 3084 ms
Direct lightgrid         [100%] 613 ms
Indirect lightmaps       [ 91%]
(process:21796): GLib-ERROR **: 10:46:38.883: ../glib/gmem.c:177: failed to allocate 512 bytes

[SpineyPete]

Alright, it actually seems to be a genuine OOM afaict. 32-bit consistently runs out of memory, 64-bit is fine. According to task manager seems to allocate over 2.5GB before exiting (polling is slow, so it's hard to tell). This has to be some kind of record :)

[SpineyPete]

So this is totally shipable quality wise imo. It looks great. Everything has specular without those "worming" artifacts. I don't think any deluxemapped game actually solved this before?

That said, it does make me wonder if you could just store like two RGBA texture and save the 8 most important lights into every leaf/face, and then apply them as pointlights while using each of the channels as a visibility factor. bool visibility = ray_from_luxel_hits_light && luxel_is_within_light_radius;, but with 8 bits for antialiasing. So no attenuation from angle and distance.

• No potential clustering issues when aggregating lights. No directional encoding issues.
• Only two textures for all direct lighting, or even 1 of you want to limit it to 4 lights.
• Eight specular lobes instead of two. Even more pronounced diffuse bump mapping.
• Zips really nicely since most of it is pure white or black.
• Static lightmaps and dynamic shadowmaps can both be interpretted as this visibility factor, so you can unify that codepath. There's only light entities for direct lighting.
• Shadowmaps can merge with lightmaps quasi perfectly, no "double shading" like you saw a lot in previous Id games.
• You get lightstyles for free.

If you think back to the early 2000's when deluxemapping was invented, they were short on lightmap storage space and realtime lights, but those are just non issues nowadays, so it might be better to just store a bunch of visibility factors and not having to deal with all this averaging of light colors and directions crap. Since Quetoo is already storing a lot of lightmap data maybe it might as well just do that?

I know you just solved this long standing issue beautifully and I'm suggesting trying something else for an experiment, so feel free to tell me to fuck off, lol, that would be fair.

[jdolan]

@SpineyPete! So good to hear from you 😍

I'm glad you like the look! I'll have to take a look at memory usage. I'm a bit embarrassed that I hadn't noticed how badly it bloated with my last changes.

So, I did run a few experiments recently, in finalizing the changes you see now. The first thing I tried was to, instead of storing a full RGB deluxemap, attempt to slam an approximate lighting direction into the alpha channel of the lightmap. I figured, this would be a nice way to allow us to have multiple diffuse light channels without incurring two textures per channel. This is why I hit you up for your dome point generator, actually. So the idea was, calculate lighting exactly how we are, but to write the direction, compare it to the 255 approximate normals, pick the best one, and stick it in the alpha channel. Then sample the alpha as an integer, and index into the same array of normals in the shader. It worked but had lots of banding and weird artifacts because of texture sampling, and the fact that in any spherical coordinate mapping, numerically close values are not necessarily directionally close:

It's too bad, because this really cleaned up a lot of the code, actually. No directional encoding issues, only have to sample a single texture per lightmap channel, and supporting N light sources per luxel would only require N textures. But, for the reasons you see above, I had to scrap the idea..

The second experiment I briefly explored is more like what you are describing. I thought to bake an ambient color RGB lightmap, just like today, but then for diffuse, bake an RG16I texture, so each luxel would have indexes to its two strongest light sources. The thought was that I would save all of the direct light sources in the map to a BSP lump, and upload them as a uniform block at level load. Then, just like you're describing, use essentially the dynamic_light path for them, so that static lights and dynamic lights are literally the same darn thing.

A point to clarify with how you're describing the approach: I don't think that storing lights per leaf or face will work, if you consider that we are batching all faces of a given material into a single draw call. The only way to pass this information in would be as vertex attributes, and I'm not sure there's enough precision there (with large faces) to include all of the light sources that might affect a face. We could explore vertex attributes for this, tho.. But this is why I was considering an RG16I texture, so that we would have adequate head room to reference 65K lights per map (heh). I think two light sources is enough, as well. From what I saw in experimenting with the current implementation and 4 lightmap channels, by the time you get to the third channel, the light contributions are very small. I think it's acceptable to merge lights 3, 4, 5.. into the ambient color.

Anyway, the reason I stopped short of fully implementing this experiment is that I thought it would require a lot of shader work for directional and sized lights, and I was tired / lazy 🤣 Patch lights, by far our most common light type, are all sized by the face itself, and that definitely affects their model. But maybe it's worth a quick proof of concept without explicit support for those things, just to see how the bump and specular look with this approach. Maybe a hybrid of our ideas, with vertex attributes for light source indexes, would work as well, and allow us to support more lights per luxel.

Really good to hear from you, bud. Made my morning 😊

[jdolan]

Btw, this one's for @Panjoo since he's not on Discord. I'm playing around with per-material cubemap reflections. Not sure if I'll land this one, but.. it's kind of interesting:

It looks neat on shiny metals, but it could also be useful as a natural-looking visibility limiter for water.. More to come!

[jdolan]

I top out at 1.9GB lighting Edge, which is still pretty high.. I'll see if I can shave it down. But the culprit is lumen_t which is each luxel's reference to each contributing light source. It's kind of the lynchpin in this new approach. 🤔

[Panjoo]

That old Edge lighting color is so ugly compared to what I have now:P. And those compiler warnings for Edge are also fixed in the new version.

Cubemap reflections sound nice but I'm not sure if I'm gonna be using them, well, on some glass windows perhaps. Just so you know I've made most water opaque except for tokays. Because there still is a gameplay/cheat issue with having blended or alphablended water in certain maps. Once compiled with alpha blending the water tex can be easily replaced with one that has a pure black alpha channel. And then you have your own invisible water, making it almost like a wallhack. Anyway most water still looks cool enough with the volumetric fog and caustics.

The spotlight cone can be specified in the material definition if you do want to tune it (or disable it) for certain textures. The material key is light.cone and it's specified in degrees, just like light_spot. The default is 75, and 90 will effectively disable the effect (previous behavior).

The lightcones from the surface light look rather nice, but don't forget that I already made most surface-lights (lamps) have low light values, around 100, and combined them with pointlights. Clearly this is a visual enhancement (good job btw), but hopefully as you said, it will look better without having to tune again. I will probably have to ditch the extra lights and just make use of the now better direct patchlight. If all goes to plan I'll be getting a lot of work done this weekend so I will let you know how it looks.

Sidenote: I have a whole list of suggestions (on gameplay, items and settings) and I'll Open a new issue for this soon.

[jdolan]

Can't wait to see some updated maps! And that's a valid concern wrt blended water. Makes sense.

@SpineyPete I did a little refactoring tonight and brought memory usage down from 2GB to 560MB baking Edge, heh. I also managed to squeak some more performance out. Torn Glory bakes in 6s on my MBP. 💪🏻😎

I think we're getting some rain this weekend, so I'll probably be pretty active on Quetoo as well.

[Panjoo]

So what would be the latest greenlight snapshot that "enables the angular attenuation for direct patch lights"?

https://ci.appveyor.com/project/Paril/quetoo/history

this one? -> https://ci.appveyor.com/project/Paril/quetoo/builds/43244311 the rest are listed as "Failed" or "Cancelled".

[jdolan]

Oh, that sucks. It looks like some random instability with AppVeyor downloading our dependencies or something. Anyhow, yes. That snapshot will work just fine. The only one after it (failed) is a super minor change.

[jdolan]

@Panjoo I've made what I think will be the last adjustments to the lighting model as of last night. You may have noticed that, in the last two weeks or so, maps became darker overall. This was a side effect of my trying to improve our bump mapping effects by increasing the intensity of light directional vectors. To cover up some artifacts near the edges of light boundaries, I was applying Lambertian dot product once in quemap, and then a second time in the shader. While it removed the artifacts, this basically just made everything darker. On Friday, I figured out the math magic to correctly blend light boundaries without the dot product calculation in quemap. The result is that maps are much closer to their previous brightness levels (brightness 2.0 in worldspawn will look good most of the time), and our bump map effects from static lights actually look as good as those from dynamic lights. Finally.

With r_draw_bsp_lightmaps 2 you can see the directional vectors. The variation and intensity of the colors is night and day compared to our previous deluxemapping from a month ago. This is what enables really sharp, crisp bumpmapping effects.

And if you remember how flat the bumpmapping was on Dark Zone previously...

So this should be it, as far as lighting goes, for our major release. I'll of course address any bugs you find with it, but I'm really satisfied with this. It's simple, fast, mathematically correct, and looks pretty darn good, for the dated technique that it is. My priority for this week will be to button up the maps that are on my plate (Torn, Dark Zone, Claustrophobopolis, Gehenna, Stress Fractures).

[Panjoo]

I've made what I think will be the last adjustments to the lighting model as of last night.

Yeah man, at some point you will have to force yourself to say "this is good enough" and even though the technique might be somewhat dated, I think you guys have made it all look pretty professional.

To cover up some artifacts near the edges of light boundaries

I'm not sure if this is what you're referring to, but I've noticed that if I have pointlights that get overpowered by the sunlight, it makes bright circles, sort of like an outline of the light, or a halo. It only happens in places where the directional sunlight hits. In this screenshot Ive already made these three lights very soft with _intensity, but it was very noticable before. In some places I just took them out because the sun provides enough light.

One other thing, that I hope you can fix, is the bloom effect on the sky itself. It just doesn't look right and kinda ruins most of the sunny skyboxes.

A while back Paril explained to me that: "Any pixels that end up "over-exposed" are written out to a separate buffer, blurred and then pasted back over top. I don't know if there's now a default bloom setting that is affecting skyboxes or what, but I think JD might have set that one on purpose since it's a sun and he wants it to appear bright.. no idea."

[jdolan]

Yes, to your first question, that's exactly the artifact the old dot product code was fixing (poorly). The new code addresses that issue the correct way. Let me know if you are still seeing this, but it's completely gone in Edge, Pits, and Torn for me.

The bloom shader.. I can spend a little time on this. Right now, it does a super basic blur. Something more sophisticated and selective is probably worth attempting. Maybe the blur size, as well as the overbright intensity, can be specified per material..

[Panjoo]

I think my question wasn't entirely clear, but I was hoping that you coud just exclude the skyboxes from the bloom shader?

[jdolan]

Ah. Well, I think I hard-code the sky bloom level to 1.5 or 2.0 or something. I can try just not doing that and see if it's tolerable :)

[jdolan]

@Panjoo Last week, I made changes that allow the sky to cast light bloom into the world, but the sky itself does not get bloomed. You can also tune this effect by just changing the bloom parameter on common/sky (or whatever material you used for your sky faces) in your materials file. Higher values will increase how much the sky blooms onto the world.

Lastly, there will be one final shader adjustment to use the Blinn-Phong model for all of our specular highlights. It provides a noticeable improvement over the standard Phong model (what we have now). There's a great explanation of the rationale and differences between the two here:

https://learnopengl.com/Advanced-Lighting/Advanced-Lighting

As the article calls out, we may want to increase some specularity values in our materials files once this change is in. I'm going to try to compensate for the differences with a magic number, but fine tuning might still be worthwhile. I'll try to get this change in over the weekend.

Love the updated Edge, btw!

[Panjoo]

Oops missed this. Thanks for the link to that article, interesting stuff.

And now that I'm looking at your latest bloom/spec changes.... woah! Dunno what you guys have been doing but it's looking awesome, now I'm actually liking the bloom! It's got that "rtx" feel to it. Super sexy.

The only thing I was disliking was the way it painted the skyboxes. So, I think I will leave the specularity values and further material tuning to you.

The maps are keeping me rather busy (in a good way) but I'm on a roll and I just uploaded Hallways and Pits.

(BTW some of the bugs listed are not yet addressed, eg. the fast slime dmg, the crush-fireworks and player bbox height. You're gonna forget :P)

[jdolan]

Slime damage, crusher fireworks, instant crush death are all fixed.

@Paril I'm confused with the player bounding box issue. I noticed this months ago on Slimy Place, but figured it was just a ground_dist issue. Having looked at this for a half hour today, I don't think that's actually the case. I turned on bounds drawing, and noticed that the player should easily fit under the ceiling here. The player is 60 units high, and this gap is 64 units. Yet, the player still can't enter.

quetoo011

And what's even crazier, is that the player can't enter when ducked! quetoo012

At 56 units tall, the player could enter this area when ducked. But now, at 60 units height, I have to jump and duck at the same time and then I can enter the area. Something is very fishy with this collision..

Here is the area in Radiant. There are no clips or anything weird going on here, brush-wise. PrintScreen

I tried modifying the trace routine to test brush sides in-order (bevels last) just for kicks, but it didn't affect this. I've logged out the player bounds in a few places to ensure they are correct. Got any ideas?

[Paril]

Bevel ordering won't change anything, those brushes don't have bevels (they're entirely axial). On my end with 56 height, I can crouch under it but I can't run under it. I can walk under it if I hold forward for long enough, which is even weirder.

[Paril]

I think it's probably Pm_StepSlideMove. There's a piece that we stripped out of this at some point that Q2/Q3 does, which takes the movement that goes farther - it solves an edge case where an attempted step up move was valid, but didn't actually cover any distance, and I think that's what's happening here. We always take the up+forward move, even if the forward move went farther.

[Panjoo]

^^ [buglist updated]

[jdolan-chwy]

Thanks @Panjoo. So a couple of thoughts:

1. The FPS issue, with higher framerates outside of the map.. I think this is actually pretty straightforward. Quetoo is now GPU-limited, meaning your pixel fill rate will dictate your frame rate. When you venture outside of the map, a bunch of the pixels in your framebuffer (all of the black ones) are skipped over because there's no geometry to draw there. This means those frames will run faster. When you are inside of the world, which is a "sealed" volume, every pixel in your framebuffer must be processed. That's all that's happening here.
2. The lightmap boundary lines must be due to an incorrect light hashing function on my part. To optimize light compile times, I pre-calculate which light sources can "see" certain parts of the map. If I don't get the size of the light correct during this optimization, you end up with artifacts just like that -- where a light should have been eligible for a face, but was not, leading to a visible cutoff. I'll look into it soon.
3. The weird patterned lightmap on the slime looks to me like maybe specular issue. Does that slime have a normalmap? Maybe it should / shouldn't?

The pmove bugs are likely related to @Paril 's recent changes to try to improve stair climbing. I pointed out another bug to him, where you now immediately "stick" to any object that you jump on to, instead of jumping up and then landing down on that object. I think those last rounds of pmove changes (not the fix for 64u ceilings, but the later ones) should be reverted for now, honestly. That code is extremely sensitive.

[Panjoo]

When you venture outside of the map, a bunch of the pixels in your framebuffer (all of the black ones) are skipped over because there's no geometry to draw there. This means those frames will run faster. When you are inside of the world, which is a "sealed" volume, every pixel in your framebuffer must be processed. That's all that's happening here.

1. Ok I understand this. However, to me it's not a good sign that in quetoo my framerate tops at 168 in that simple boxmap (which is as basic as it can get).

2. That makes sense, I'll put DM7 back on the shelve for now as it's kinda frustrating to work on lighting with artifacts like this popping up.

Does that slime have a normalmap? Maybe it should / shouldn't?

3. Nope, no normalmap. That slime, the base layer is just a solid green color. In the material I use two moving stage layers that I turned off to give you a better view. As a quick test I've renamed the normalmap from another texture to slime0_nm and as you can see it makes no difference, this is also with specularity at 0.

slime-with-normalmap

[jdolan]

Can you actually send me your dm7.map and .mat so that I can reproduce the lighting bug? I don't have a .map that does this. It must be some sort of edge case.. that'll help me look at the slime lighting issue, too.

[Panjoo]

I've not been at the desktop this weekend but will send you some files soon. The slime issue also happens in other maps with the same slime textures, like Pits and Fragpipe.

[Panjoo]

Right, here are the files: dm7-wip.zip

If you decrease the slime's light.radius in the material to let's say 45, in most places the lighting errors will be gone But you'll get different results if you play with the light.radius value and the errors just pop up in other places.

-- And, also not unimportant, it seems that Surface flags in the Editor like Light and Liquid and Opacity are now borked and no longer work in combination with liquid volumes like slime.

The slime texture has a surface light value in the material, but this is what happens if I set a different Light value on a slime brush, I left it in the .map file for you to inspect;

---

Some screenshots from DM8 that illustrate the problem:

[jdolan-chwy]

Hi Pan,

I have not yet delved into the files (thank you for attaching them); the weather has been amazing here and I've been outdoors a lot :) I think I'll have some time to look at this tonight, tho.

What was the change you made to the wall angle in dm8? Is this maybe an auto-Phong bug? Auto-Phong is enabled by default with a threshold of 60º. I think it's possible that this particular issue is different from the dm7 one. Just a theory..

[Edit: I see the angle change now; I hadn't finished my coffee yet..]

So surface and contents flags that are defined both in materials and on the brush sides are a little tricky. The way it works is, the material definition becomes the "default." However, if the brush side specifies any flags at all, then the material flags are discarded, and the brush side must specify ALL relevant flags. It works this way so that you can fully override material-defined flags on individual brush sides should you ever need to.

I'll confirm that this is still working as designed, and I'll take a look at your .map file as well. If literally all you changed was the "value" field on the brush side, and no surface flags, then you may indeed have found a bug. But hopefully that helps clarify the expected behavior.

[Panjoo]

[Edit: I see the angle change now; I hadn't finished my coffee yet..]

Yep, the red lines I drew represent two different angles of the wall brush, which was exactly 45º

The usual phong artifacts I encountered looked different, more like diagonal shadows. Here it also looked like it gets cut off.

It seems to also have something to do with 45º angles. I know I've mentioned this before somewhere, that any brushes angled at 45º don't get phong'd.

-- As far as the DM8 artifacts, I've fixed them myself by adjusting the brushwork, and it also looks better this way.

There still is some light leakage though, as you can see in this pic, but that seems to have to do with using higher light _sizevalues.

I wanted those yellow and blue lights to not look like obvious circles so I used a _size of 56 and lower _intensity. Especially on the catwalks that caused leakage but in most cases lowering the _size value fixed it.

In other cases I had to make some minor brushwork changes to get rid of it:

[jdolan-chwy]

Hi @Panjoo, I fixed the hard light cutoff on brush bounds, as well as the weird pattern on light-emitting blended faces (slime) this weekend. I think @Paril got our snapshots building again, so you should be able to grab a new build whenever you like.

I think I had fixed the light bleeding issues back in May, too? I did not reproduce those yesterday during my testing.

[Panjoo]

Yo yo @jdolan, I'm not sure if had you already fixed it in May. I think not though, or the snapshots weren't updated. That's why I decided to skip dm7/slimyplace and work on other maps. But I tested another compile just now and it looks like the hard light cutoff has disappeared.

Cool. Now I can also finish that map too.

I did find some other bugs while working on Chastity, eg. misc_flame wasn't visible against skybox and there was something awkward with the doublejumps. But... this latest build seems to get rid of most of them. Also, the sky bloom shader looks even better now too.

---

trigger_push bug For example in the new Chastity map. Walk up toward a jumppad and immediately after it pushes you up, press the jumpkey and keep it pressed. It will push you up way too high.

func_door The func_door also has a bit of a flaw but it's hard to describe. I was using _funcdoors as invisible jumppad "blockers" (just like in the original Q2 chastity map). The problem is that no matter what speed I give them, they don't return fast enough, like there is a delay, which was messing with the timing of the "blocker". The _funcdoor opens correctly, but seems to slow down at the end of the move. Anyway, I now used _funcbuttons as "blockers" with a high health key so that you can land on them without activating them.

[jdolan]

Hi Pan,

Glad the newest build is looking better to you! Yea, the sprites not showing up against the sky was a regression due to my attempt at making the sky shader cast bloom, but not appear bloomed itself. Turns out, that wasn't going to be easy. So we're actually just back to having the sky bloomed like everything else. Glad you like it now 😂

The trigger_push mega-jump is a newer regression from a feature that @Paril added, this thing called the "jump buffer" which allows players to jump for a short time after falling off of a ledge. I guess many games have this these days? Honestly, I have not played enough with it to have an opinion. But I can fix it so that trigger_push's clear this buffer and disable the jump.

Our doors (and all movers) do have slightly different physics from Quake2, and a more pronounced deceleration near their final position. This wasn't for appearance sake, it was actually to fix another issue where they wouldn't fully move to their destination, once I increased the server tick rate. Something to do with shorter frame times.. Anyway, if you want to attach a .map that exhibits the bug with visible doors, I can take a crack at it.

[Panjoo]

..this thing called the "jump buffer" which allows players to jump for a short time after falling off of a ledge. (...) But I can fix it so that trigger_push's clear this buffer and disable the jump.

Yes plz, that would be best for the jumppads.

it was actually to fix another issue where doors wouldn't fully move to their destination, once I increased the server tick rate. Something to do with shorter frame times.. Anyway, if you want to attach a .map that exhibits the bug with visible doors, I can take a crack at it.

It was only an issue when I was using doors as precisly timed jumppad blockers, but now that I replaced those with func_buttons I don't think there's a problem with the doors as long as they are used as normal doors:)

---

Something else I found: The blaster's muzzleflash is offcenter.

[Paril]

This is intentional. The game tries to pick a firing angle that will be more beneficial to the attacker; if the shot comes from the side and would impact a wall before hitting the crosshair, it will prefer to shoot from the center. This is mainly to help rockets and grenades go down corridors and not blast yourself in the face. There might be something we can do to fake the path of the projectile so it still comes from the left visually but then it may intersect walls and look off.

The algorithm is very simple though and can be tricked if you're aiming at weird angles (it prefers to take whichever goes farther or impacts an entity).

[Panjoo]

elevator bugs: -Ride an elevator while squatted and you'll hit an invisible ceiling, then lose health and the elevator goes back down. Awkwarrrrd!

-If you have a low_trigger/spawnflags 1 elevator and use a lip key of 16 or up, the entire func_plat is dead. To make the func_plat work, you have to either remove the lip key or set a lip value of anything under 16 units, which seems to make no visible difference anyway.

draw order blending: In the updated map Onemustfall, I've used a texture (sewer_bars.tga) and its textureface is partly above and partly under transparent water. The part that is supposed to be under water is not being drawn at all. Used flags: blend_100 / decal / mist

mouse input: Feels like there is mouse delay that I can't get rid of. I played with sensitivity, pitch/yaw and m_interpolate settings but it's still not that direct snappy mouse movement I'm so used to.

[SpineyPete]

Some things that might influence input latency:

• using vsync, especially using triple buffering
• using fullscreen windowed instead of exclusive fullscreen
• I’ve heard some “fancy” mouse drivers might mess with the input, and some protocols like bluetooth add additional latency, but I’m not sure.

Additionally maybe com_maxfps is set to vsync rate, that might add a little bit of latency, but I’m not sure.

You might try messing with those settings and see if they make a difference, if you have a smartphone with good slow motion recording of video you can check the latency with it.

[Panjoo]

Well I'm using custom r_width and r_height with r_fullscreen "0" So I guess I'm in windowed mode. Also r_finish "0" (I believe this is vsync?) Don't know how to check tripple buffering...

And it's just an old but decent logitech mouse (MX518) with no additional drivers. I dunno, for me the mouse in quetoo only felt right in much earlier versions and just recently I was trying to finally configure the settings to my liking but it's just not snappy and precise. I'll try some more things like exclusive fullscreen.

[jdolan]

Hi Pan! Thanks for the bug reports. Not sure what to say about the mouse latency. I've not experienced that one.

The draw order issue, there might be a workaround that will help here. The renderer is determining the distance to each blended plane and sorting them back-to-front. So it's actually doing the right thing there, but it'll never work correctly with intersecting blended objects. We would need to be doing depth sorting per pixel, and, well, that's RTX territory ;)

-But- you can try setting SURF_DECAL on the grate (surf decal in the material) and that might fix the issue. SURF_DECAL basically says "Yes, this face is alpha blended, but no, do not include it in blend depth sorting." This is the desired behavior for true decals, which nothing can really appear behind anyway (since they are 1u away from a solid wall). Excluding decals from depth sorting is a nice performance bump on maps with lots of decals.

No guarantees, tho. Turning this on could just cause the water to always appear in front of the grate..

Another option would be to make the grate SURF_ALPHA_TEST instead of blended.

[Paril]

As far as I know nothing has changed on the input side of things in years - it's all just SDL. Maybe updated SDL changed something? I did update SDL a few times.