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 :

[jdolan]

@Panjoo Just curious, how does this edge.bsp perform for you? If you take a look with r_draw_wireframe 1 you'll see I'm experimenting with some different techniques to reduce the number of triangles in the map (at the expense of some overdraw). This makes a difference on my system, but our systems are very different...

edge.bsp.zip

[jdolan]

@Panjoo I pushed a commit that will reduce triangle counts on our maps, but it is a breaking change and so all maps will need to be recompiled. I figured, it doesn't make sense for me to do this, since you're close to done with a bunch of them. Just wanted to let you know, tho -- don't be surprised when you grab the next snapshot and your current compiled maps don't load :) Simply rebake them.

[Panjoo]

how does this edge.bsp perform for you? If you take a look with r_draw_wireframe 1...

As you can see in these screens it makes a difference with r_draw_wireframe 1, but with r_draw_wireframe 0 the difference is minimal and hard to notice, probably around 5 -10 fps higher with that edge.bsp Which is improvement nonetheless, and I'll take a cleaner traingle soup any day over a messy one, since that should in theory reduce the change at lighting glitches.

(As for your breaking change commit, when the time is ripe I'll go over the maps again anyway and recompile everything in one session so they will be fresh out of the oven.)

[jdolan]

Yea, I had similar findings, actually. It seems we are fill-rate (pixel shader) limited, not vertex / geometry limited, which makes sense. Some of the changes I tried actually brought triangle counts on Jester's big jgothic.map from 66K down to 22K, but made no discernible difference in framerate.

In doing a little bit of profiling (having my computer add up all of the time spent in various functions), I found that drawing the world takes just about the same amount of time as adding and culling all of the sprites in a given frame. In other words, our world drawing is stupid fast, but some of our sprite code and assets are probably a good place to make some gains.

Please don't limit the visuals on the maps preemptively for performance considerations. I'd rather we aim as high as we can on the visuals, and then work to optimize, or scale back if we absolutely have to. I'll continue to chew on this and see if we can't come up with something. In the meantime, I simplified the flares code so that they no longer disable the depth test. So flares should correctly be occluded by solid geometry like opaque water and mesh models.

I don't have plans to re-introduce the view-size / letterbox feature. You're the first / only person to ask about it, heh. If you really miss it, I'll put it on the list.

[Panjoo]

our world drawing is stupid fast, but some of our sprite code and assets are probably a good place to make some gains.

That is what I have been suspecting. Quetoo's performance always felt pretty robust, regardless of what map I was running. So it doesn't make much sense that I wouldn't even get more impressive fps in a boxmap (literally a hollow cube) where I'm just standing still.

Please don't limit the visuals on the maps preemptively for performance considerations. I'd rather we aim as high as we can on the visuals, and then work to optimize, or scale back if we absolutely have to.

I had already decided to do just that:). At one point after trying some cool stuff and seeing a dip in frames, I was thinking, "Ya okay f*ck this, I'll make 'em pretty and let the codemonkeys figure it out. Bye!" So I'm now mainly focussing on visuals.

Oh BTW, try using opaque water and you'll see that something goes wrong during the bsp build: oopswater:) (I probably won't be using much opaque water after all but it's nice to at least have the option and that it works correctly.)

If you really miss view-size, I'll put it on the list.

Yes plz, I mean if it's not too much trouble. why not. I prefer smaller views for fast-paced games and as I'm usually running in windowed mode my cluttered desktop makes it feel rather busy and distracting. That's why I like the view-size thingie, it lets me run fullscreen while having a smaller and more centralized view area. Also, having that feature adds to that feeling of a game that lets you customize your setup as much as possible.

[jdolan]

I'll try to fix opaque water this weekend. You may also notice some rogue Z-fighting faces if you rebake with the current tools. This is an edge case regression with the new face merging code. You can compile with -bsp --no-merge if you see these and they bother you; but I'll be working on a fix for them, too.

I've also made significant improvements to our Phong shading this week:

1. Phong is supposed to work by finding common edges between faces, and then "weighting" the face normals by their surface area to blend the two normal vectors together. This is what our algorithm does, but there was a catch. In working with the final face geometry, you're dealing with all of the BSP splits. So a brush side that should contribute a large area to Phong shading might be split into 2 or more faces, and it's Phong contribution diminishes. So our Phong might look good in some parts of a map, but would quickly fall apart in busy, complex sections. The fix is to instead use the original brush side winding areas to weight vertex normals, and ensure that we only count each brush side once.

2. I found some bugs in my barycentric coordinate calculation. This is the calculation that determines the position of each lightmap pixel (luxel) in a given triangle, which in turn determines its normal vector for Phong shading. The old code was returning valid barycentric coordinates for points not inside of a given triangle. This is no longer the case, so we'll only accept and use barycentric coordinates from triangles that a point actually resides inside.

3. I added support for auto-Phong, but not via materials as I originally suggested. Instead, it is set per-entity. You can add the phong key to any brush entity. The value is the angle, in degrees, when Phong should kick in. Values like 45 and 60 are good starting points. With this key set, any faces that meet at angles less than the threshold will be automatically Phong shaded together. This encourages more use of func_group, btw, which is a good idea in general. Arches, curved hallways, terrain, etc.. can all be auto-Phong'ed without using the surface inspector at all -- just make them a func_group. The nice thing about this, too, is that the Phong sticks even if you change textures. And yes, this key even works on worldspawn.

Here are some screenshots of the Phong-interpolated luxel normal vectors on Jester's Gothic map, with phong 60 set in worldspawn:

And on Torn Glory, still using explicit Phong via SURF_PHONG:

[SpineyPete]

@Panjoo just a heads up but I'm currently tweaking some of the rendering of the specular in develop. There's now also a specular reflection from the bounced lighting, which I think helps with the look, but it might make some surfaces seem a little bit washed out. I'm working on fixing that, but for the moment maps might look a tad different.

[Panjoo]

@SpineyPete Hmmm, ever since we ditched parallax, things already started to look more blend and washed out. Without parallax the textures really need at least some direct light to even make the _normals visible. But you know what you're doing so hopfully it'll help with the overall look. If not I will find you:).

@jdolan Very nice going man. Yeah phong was a bit of a uncertainty, it sometimes looked good and other times it just didn't do much.

So our Phong might look good in some parts of a map, but would quickly fall apart in busy, complex sections.

That's kind of funny, because I more or less had noticed the opposite. It didn't work at all on the simplest 45 degree corner brushes, like on the corners of the tall elevator shaft in Edge, and like in this example: Then if I make the corner more round it suddenly works.

The nice thing about this, too, is that the Phong sticks even if you change textures

In Netradiant it already keeps the phong flag if I change textures. In fact it keeps all flags if I change textures, which might be sort of a bug, hehe. Oh well, as long as phong itself works better now and thnx for the info. Most DM maps are already "phonged" though, but I might still use the new func_group method in the maps that have portions of terrain (Edge, Hallways, Lavatomb).

[Panjoo]

@SpineyPete

...but it might make some surfaces seem a little bit washed out. I'm working on fixing that, but for the moment maps might look a tad different.

I've updated my snapshot today and did some compile tests and I know you said you're working on it but the washed out look made me shudder a little. I already played with the cl_editor sliders but I can't seem to find that "sweet spot" where it looks good. Would you say that by lowering the radiosity in worldspawn I can potentially minimize the specular reflection from the bounced lighting?

As long as this can all still change and has this much effect on the visual appearance of the maps, I will be holding them back until you get this sorted, because I still would like to do some final material tuning. It's also harder now to judge the lighting in the maps wih these kind of specular changes, so for me it's probably smarter to not use the latest develop snapshot.

[jdolan]

I just committed a change to revert back to the old specular code for now. We have @SpineyPete 's work in a branch, and when we're able to bring it in without negatively affecting the look of the game, we'll do that.

[SpineyPete]

Yeah, I think we can consider this a failed experiment, didn't pan out like I was expecting. (To give some context, I added it after running through the games with only specular output, and the vast majority of the screen was black, I thought adding some more specular might look more natural, but yeah, it looks washed out when applied to the textures.)

[jdolan-chwy]

I actually think it looks pretty good in the branch, with the separate lightmap channel for indirect light direction. It significantly reduces the specular "worm" artifacts.

[SpineyPete]

Lets keep the branch around till next week and I'll see if I can improve upon it. I'll try the vector-scaling trick and see if that's enough to make it look decent.

[Panjoo]

Sounds good Pete.

(I agree that it reduces the specular "worm" artifacts but that's mainly noticable around the textures that use surfacelight, ie. the small ceiling lights. What I already found was that I can minimize that artifact by using lower light values of around 100 in the material. That way I can still get a subtle light coming from the texture and then add a light that sits somewhat farther away from that texture. This also gives me more control over the light color and _size.)

[jdolan]

@Panjoo Which maps are / aren't you fixing up? I'd like to divide and conquer if possible. We're potentially only a few weeks away from being able to release this game!

Maps I figured I'd own:

• Torn Glory
• Gehenna
• Claustrophobopolis
• Dark Zone

Maps I assume you're on top of:

• Q2DM*
• One Must Fall
• Grunt No More

• Gymnastium

  Maps I'm not sure about:

• The Rage
• Stress Fractures
• Aerowalk
• Chastity Belt Duel

Are there others, too?

[Panjoo]

Basicly the maps that I did the remakes of are the maps I'm working on, that includes Rage, Aero, Chastity and Turbo. Some of them don't need that much editing besides the worldspawn settings and extra light-entities where they're needed, and maybe a couple of texture enhancements here and there. Most time goes into finding the right amb and fog colors and strenght, since these values really define the overall look and feel. I was thinking of sending you a bunch of maps this weekend so you can see what I've done so far and if you dig the changes.

(btw I added a 'swim' bug to my buglist above, don't know if you've seen it yet) Oh and worldspawn phong rocks. N1.

[jdolan]

Sweet! That sounds great and thank you for taking all of these on. Can’t wait to see them.

I’ll tackle Stress Fractures then. I might retexture it with Rygel if i can keep the winter theme in tact (even tho the original was gothic, we need a map with snow falling 😁)

[jdolan]

Hi Pan, some updates on the issues you opened above:

1. Rocket jump. I changed the calculation to not be linear based on mass, but exponential instead. And I've made it configurable so that you can tune it and let me know if you'd like any further adjustment. g_self_knockback to scale self-knockback gloablly, or you can also scale individual weapon knockback with g_balance_rocketlauncher_knockback, g_balance_hyperblaster_knockback, etc..
2. Armor timings are adjusted as follows: a. Shard 15s b. Jacket 20s c. Combat 25s d. Body 30s These are all configurable with new cvars, g_balance_armor_*_respawn. Again, let me know of any defaults you'd like to change. I did the same for healths. See g_balance_health_*_respawn btw.
3. I increased underwater speed (118 -> 120) and acceleration (2.8 -> 3.0) slightly. Let me know if this was enough.
4. I fixed the bug of being stuck on the ground when underwater. Simply face slightly upward now and you'll swim.

[Panjoo]

Alright, noice!

1) Will let you know about the rocket knockback tuning. 2) I'd probably keep the Jacket & Combat armor the same, both 25s. Shards at 15s and Body armor at 30s are spot-on. 3) I noticed little to no speed change underwater. Accel is still annoyingly slow: from 3.0 to 3.4 perhaps? 4) Sweet.

[jdolan]

I just fixed the face merging issue that was causing visible errors with blended faces (like the water on Edge), so you can go back to omitting the --no-merge option, if you were including it.

[Panjoo]

Another error down, cool.

I found something else although it's not a new one. If you load a map and disconnect and then load it again the game crashes.

Also, I think bmodels become too dark now, things like lifts, moving platforms, etc. It looks different than before.

Will let you know about the rocket knockback tuning.

g_balance_rocketlauncher_knockback 75 ...feels just right /This lets you perform the most common rj's and makes it a little easier and less frustrating than in Q2.

[jdolan]

@Paril Can you reproduce map edge; disconnect; map edge; -> crash? I do not see this behavior on any of the maps I've tested.

As for inline model lighting.. I changed the shader to use only the lightgrid for them, not the lightmaps. The previous code attempted to blend the lightmaps with the lightgrid, so that you had some contribution from each. I can try to put that code back in..

I'll make the RL knockback adjustment now :)

[Paril]

I have had the crash happen once randomly, but I don't know if it's the exact same crash he is seeing. If it crashes again, Pan, can you send us the dump files? (make sure you're using the latest snapshot build too so I can match the executable files)

[Panjoo]

I'll get a dumpfile if it happens again. Of course I'm not just playing the game like you normally would, I'm map-testing and Alt+Tab-ing in and out of game while sometimes replacing textures and sounds and whatnot.

Also, for testing I've set sv_max_clients "1" in my autoexec.cfg so I can do give all Then if I want to add some bots I need to change the max_clients number, but as soon as I try to restart the map to make the change happen it usually crashes.

The previous code attempted to blend the lightmaps with the lightgrid, so that you had some contribution from each. I can try to put that code back in..

Before you go and try this, I think I will add a very soft light above the lift so that it at least receives some light, since the lifts get lit in the up position. You'd think it woud be one of the easiest maps but Tokays has been the biggest bitch to light because the many tall and undressed walls depend on the skylight and I couldn't just stick a bunch of little lamps in those walls to break up the dull look. I managed to make it look a bit more pleasing by using a second sun and by making the water a different color.

I also got a couple suggestions on things like 'weather' and some other Menu Options, but I'll open another Issue for that later on.

[Paril]

You can just use g_cheats 1 to enable cheats during a game; it doesn't need a map restart, either. Forcing it in config (set g_cheats 1) should allow it to stay enabled as well.

I have a feeling the issue is related to you changing textures or maybe cl_editor usage or something during gameplay. Try to remember steps you're taking before it crashes; if it's consistent it's probably media-related.

[jdolan-chwy]

@Panjoo Looking at that screenshot, it's pretty clear to me there's actually a bug in the lightgrid sampling code in the BSP shader. The grid should be very close to the lightmaps, and clearly it's wrong here. It probably has to do with how I'm interpreting the light direction. Go ahead and add a light for now, since that's a quick and easy fix. But I'll look at this exact area in the map and see if I can figure out what's wrong with my code.

[Panjoo]

jdolan: "Go ahead and add a light for now, since that's a quick and easy fix. But I'll look at this exact area in the map and see if I can figure out what's wrong with my code."

Okay, I'll add some light.

Paril: "You can just use g_cheats 1 to enable cheats during a game; it doesn't need a map restart, either. I have a feeling the issue is related to you changing textures or maybe cl_editor usage or something during gameplay. Try to remember steps you're taking before it crashes; if it's consistent it's probably media-related."

Yeah I'll just use g_cheats in the config from now on. Now that you mention it, _cleditor usage does still have its quirks. After usage, the whole Menu is gone. Doing _cleditor 0 doesn't help either. I can do most things from console anyway but this should not kill the Menu. In fact, after using cl_editor, the Esc function changes to hide/unhide the HUD, intead of Opening the Menu. (Unrelated: it's kind of silly to have the editor window block your view and to not be able to move it away from the center...)

It's hard to say how consistent these crashes are, but you have to do it in steps, so don't do map edge; disconnect; map edge. The following steps make it crash rather consistent for me;

1. Load a map and wait for it to load, 2. type disconnect and it sends you to the Menu. 3. Then open console (~) and load the same map again. .dmp -> quetoo_2022-03-29_13-39-17.zip

Also I know that at one time I was changing a few footsteps sounds and adding extra ones and the game wouldn't even start, unless I had only the number of steps that was there originally. (Only happened one time I think). And updating .tga's while the game is running and then r_restarting does feel like hit & miss. That said, most people won't be swapping textures while the game is running so perhaps the media-related r_restart crashes should be considered a developer bug?

[Paril]

I can't seem to find matching binaries for this dump - is it the latest Quetoo-BETA-x86_64-develop-pc-windows.zip? They don't seem to match the hashes that the dmp expects

[Panjoo]

Here's a new one, with the latest: quetoo_2022-03-29_14-56-42.zip

At first it seemed like the crashes were gone, I did multiple disconnects and map loads but no crashing. Then finally after switching to another map it crashed.

[jdolan]

Thanks Pan. Yea, cl_editor does have a few bugs (busted menus after using it, crashing when r_restarting after using it, etc). I can try to look into it soon. But given that you and I are the only two people on the planet it is affecting, it might not be top priority.

As for the lightgrid issue, I think what's happening is that many of the grid points (which are placed on an absolutely positioned grid) happen to be inside of solids near that func_plat on Tokay's Towers. You can see them with r_draw_bsp_lightgrid 1. Because they are inside solids, they are not getting any light. And so even tho your model is in a valid position, because it is influenced by the neighboring points (the way that GL samples textures), it ends up very dark.

I'll see if there's a way to address this. But we might have to crutch up areas like this with lights...

[Paril]

Thanks for the report @Panjoo - I fixed it in a new commit. New build should be available soonish.

[Panjoo]

Ok np Paril, glad you were able to fix it.

I see what you mean about the grid points Jay, makes sense why they are dark now. I'll get it done with my beloved point lights like I'm used to,

[jdolan]

@Panjoo I found (and fixed) a bug that essentially disabled indirect lighting. It's been in develop for about 2 weeks. Sorry man. I don't know how I didn't notice it or catch it sooner.

I can also confirm that something is off with moving inline models and the lightgrid, so don't fret if their lighting looks off (Tokays plat). There's definitely a bug in the shader that I hope to figure out this week.

[jdolan]

@Panjoo Please don't kill me 😬 I know you are working to finalize the maps, and spending a lot of time on lighting. I pushed a week's worth of work today that includes some changes to the lighting model, in order to fix two major issues with it.

1. Our bump maps from static light have always looked lackluster. A massive discrepancy between bump maps from dynamic lights vs static lights previously existed. You may have noticed this: firing a blaster at a wall would bring out tremendous detail, for a split second. It always bothered me, but I didn't know the cause. This week, I determined this was due to the lightmap directional vectors being nerfed; they mostly pointed straight out of the face. I did this because, back when I implemented this years ago, I didn't understand the math required to smoothly blend them into the face normal as the light attenuates and fades out. But in taking the expedient path, I had hobbled our bump mapping effects. This is now fixed, and it some ways, it looks like a different game. It looks how bump mapping really should look.
2. Our light system made it difficult to control light intensity. Most patch lights produced hot spots near the light, and then very quickly faded out. Their radius was also difficult to predict and use. Point lights were not consistently radius'ed either. This is because the previous code used any brightness parameters to scale the light radius, not the light color. I have fixed this, and I think its way easier to adjust light levels now, and also produce better looking results. I did this by introducing an _intensity key on all lights. It is basically a multiplier for the color, but it is not clamped (meaning you can make overbright lights). You may find this useful in creating large, faint lights (big radius, _intensity .333, etc). You can use this to "cool down" lights that leave hot spots where you don't want them, too. You can specify this on entity lights with the _intensity key, and you can also set it on surface lights via light.intensity in the material file. Values from 0.1-2.0 make the most sense. The light radius is still supported in the material file with the light key, but light.radius will also work if you prefer. And I'm happy to tell you that all light radius values are WYSIWYG now. The radius shown to you in Radiant is where that light will actually attenuate.

Some other nice changes:

1. For surface lights, you can set light radius and light intensity in cl_editor now. Obviously, you have to recompile to see the changes. But this is quicker and easier, since you can look at the light in-game and estimate what your adjustments need to be right on the spot.
2. I fixed an "unintended feature" where surface light values specified in materials files were actually written to the brush sides in the BSP file. This meant that, in order to see a change in light values in your material file, you had to re-compile the BSP stage (-bsp). This was very unintuitive and unnecessary. There's no reason for the light values to persist in the BSP. So that's fixed now. Edit the materials file, re-light the map, and tada 🎉
3. The light grid direction for inline and mesh models is fixed. Light looks directionally correct everywhere now. Inline models are no longer unnaturally dark.
4. I fixed a light grid bleed bug.
5. I fixed fog on mesh entities.

Worldspawn keys:

The following keys apply color correction as a post-processing step; that is, they are applied after the lighting pass, and just before the lightmaps are saved to the BSP file:

• brightness (CLI --brightness)
• saturation (CLI --saturation)
• contrast (CLI --contrast)

The following keys apply color correction before lighting the world; that is, they scale the light colors defined in your .map, before those lights are referenced for light calculations:

• ambient_intensity (CLI --ambient-intensity)
• sun_intensity (CLI --sun-intensity)
• light_intensity (CLI --light-intensity)
• patch_intensity (CLI --patch-intensity)
• indirect_intensity (CLI --indirect-intensity)

What we don't have yet, but I'm happy to add if you think it would be helpful, is light radius scalars. If you think these would be helpful, let me know:

• light_scale
• patch_scale
• indirect_scale

I don't think the map changes required to fit with these code changes are major, but if you feel they are, let's talk about it and how we can minimize rework through offering more levers in quemap. I was able to tune Torn Glory in just a few minutes.

Lastly, obligatory screenshots. Not the most exciting parts of Torn Glory, but they show off the new bump mapping about as well as you can with a still image.

[SpineyPete]

👌

[Panjoo]

Okay, this sounds promising, I'll be checking this stuff out this week. The metal plate non-slip floor looks sharp but the rest of the bumpmaps are still in need of redoing. (Note to self: improve the floor2 & floor2_nm textures for Torn (the hexagon tile), current one looks shabby without parallax.)

So far the extra lighting options seem to offer better tuning, but please don't make it more confusing than it's already become for me. Even at this point I'm having trouble making heads or tails of updated worldspawn keys and ent-definitions that I usually have to edit myself for netradiant.

jdolan: I did this by introducing an _intensity key on all lights. It is basically a multiplier for the color, but it is not clamped (meaning you can make overbright lights). You may find this useful in creating large, faint lights (big radius, _intensity .333, etc).

So now I have both _size and _intensity to soften lights?

And --ambient-brightness is now deprecated too? That's --ambient-intensity now?

Yesterday I downloaded version 0b6faa03e, and got this: -WARNING: LightForEntity_light_sun: Entity 88, Brush 0: light_sun key light is deprecated. Use _intensity.

... if I change light to _intensity on my _lightsun this warning goes away but entire lighting goes disco and overbright?

[jdolan]

That screenshot of Frag Pipe is perfection. I have no idea why you'd want to change it 🤣

So the _intensity key is a multiplier of the sun's color. The old light key on suns doesn't really make any sense. On all other light entities, the light key is the radius. But suns don't attenuate; they are purely a directional light source with an infinite radius. So what the old code actually did, was apply (light / 255.0) * color to luxels that received sun. It was kind of stupid, but that behavior still exists if you ignore the quemap warning and continue to use light. But if you switch to _intensity, and want the same exact results, you should set _intensity to your old light value divided by 255. In other words, a light of 64 is equivalent to an _intensity of 64/255 or .25.

And you are correct! You have both _size (to add penumbrae) and _intensity (to scale color) to soften (or strengthen) lights. If you want, I can add a light.size material parameter, if you want to experiment with tweaking light sizes on patch lights. Currently, patch light _size is actually calculated from the size of the face itself. But I could imagine a scenario where you wouldn't want that (a big texture with a small light in the center of it, for example). Let me know if you'd like me to add that..

I'll get right on updating entities.def and the Trenchbroom files to reflect all of these changes today. Thank you for understanding and being patient with this! You are the best.

[Panjoo]

Right, ok I think this is going to work. I've got my sunlight back to normal:)

However there's that phong problem I mentioned to you and that is the diagonal artifacts, introduced by the auto-phong thingie. They do kind of ruin otherwise spotless maps, and I can find a few in all of them;

(quote from email) jdolan: "As for the triangle lines on faces, I think these issues are related to tangent vectors, and I have seen them too. However, I've noticed that with higher hardness and specularity, they basically disappear. I've debugged the code, and will continue to look into this, but let me know if you're able to "tune these out" ;) with the material editor."

Tweaking the material till they becomes less visible isn't an option because then in most cases the textures get ugly.

Also, and less urgent as I can workaround this, on 45 degree "inner corners" it just won't phong properly and the middle brush stays dark, like I had mentioned earlier. I think you can also see this in the tall liftshaft in Edge.

[jdolan-chwy]

Right! Can you upload your tokays.{map,mat} so that I can reproduce this? I see these from time to time, but you've found some real obvious ones.

[Panjoo]

Ok here's a pk3, I still need to finetune the materials though: map-tokays-wip

(BTW have you merged my new gibskins and metal/grass footsteps into master yet? Especially the metal ones make a difference.)

[jdolan]

Thanks Pan. Super helpful. So with a little shader hackery I was able to determine that this is a Phong shading issue. If you compile the map without Phong (-bsp --no-phong), the issue goes away.

Phong:

No Phong:

What I think is happening, is that the Phong grouping is having a hard time with the skinny triangles that slice through the middle of these faces. If you r_draw_wireframe you can see that there's a sliver triangle precisely where this artifact shows up:

When this happens, the normal vector of those pixels changes abruptly (because there's just not a lot of pixels in that triangle to interpolate over), and so you see this sudden change in lighting.

I don't know if there's an easy solution here. I'll have to think on this a bit.

[Paril]

The lightmap gets a better normal for this doesn't it? I thought you had solved this for lightmaps, is it possible to just bring over that normal for use in the per-pixel shaders too?

[jdolan]

The luxel normals are derived (in quemap) using barycentric coords during the -light stage, yes. But they are, of course, derived from the Phong shaded vertex normals, which happens at the end of the -bsp stage. Here are the interpolated luxel normals. The issue is actually even more obvious:

I think one potential fix here is to only apply Phong on the "superverts" -- that is, the verts that belong to original brush sides. We should not calculate Phong on verts that are a result of BSP splits or T-junctions cleanup. This will require creating separate triangle / element sets just for the Phong shading calculation, but I think it would work..

.

[jdolan]

Hi @Panjoo, this is now fixed in the latest snapshot. I think there is still a corner case where these artifacts could appear, but I'm not seeing them on Tokays anymore. I may take another crack at a more robust solution, but this should unblock you :)

[jdolan]

You also may have noticed that, if you saved your materials via cl_editor recently, your map started leaking during -bsp 🥴 It's because of an alpha_test regression I introduced but just fixed this morning. Kill off all unwanted references to alpha_test in your materials file to fix the leaks. Sorry dude.

[Panjoo]

Rofl, I was just about to get another headache after getting inexplicable leaks: WARNING: ProcessWorldModel: Map leaked...

...this is now fixed in the latest snapshot. I think there is still a corner case where these artifacts could appear, but I'm not seeing them on Tokays anymore.

THX, nice work man, I'll be inspecting it soon with a magnifying glass.

I keep finding bugs though. Func_plats 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.

I'll update the above list because I found some more. I think I already mentioned some of them to you but they're still there and are easy to forget.

[jdolan]

What's happening with the plat is that it's running it's "Blocked" routine every single server frame. So it's applying 2 damage (for example), but 40 times per second 😂 What's the correct behavior, here? Is the plat supposed to go back up when it's blocked? Or does it remain blocked but only damage once per second or something? Been a while since I've played Quake2!

[Panjoo]

Yes, it should inflict damage once and then go back up. But if some other entity like a weapon or dropped ammo blocks it, it should crush the item and keep moving to its end position.

On the other hand, at this moment the func_door (eg. the fragpipe doors) go back down after they get blocked, which is obviously not desired in this particular case. You can give the trigger_relay that targets the doors a delay key to test this. (Btw I've already edited the lavapipe in a way that you won't see the boundaries of the lava volume when you're trapped inside.)

In Q2, func_doors let you set a "crusher" spawnflag: "_the funcdoor will not bounce back open when blocked, instead it will keep pressing and apply its dmg value". So basicly what the quetoo plats are doing right now is exactly what we need as an optional spawnflag on the doors. :P

[Paril]

Is our crusher flag inverted atm or something? Or are doors working but platforms aren't maybe? If I get free time I can look into this.

[Panjoo]

Lol I don't know what's working or not anymore. I've not yet seen a crusher flag for doors in quetoo.

Hard to test this on normal doors since they open if you apprach, but all I know is that if a func_door is triggered it will keep applying its dmg. Then right after the player dies, it bounces back instead of moving to its destination.

Both plats and doors should always bounce back by default, and inflict the given dmg. Unless you set a crusher flag, which I've not yet seen available (netradiant). But if there is a crusher spawnflag number I'd like to know so I can at least set it for fragpipe.