Ground decals wishlist

[lhog]

1. Ability to reference the ground scar textures (one or many) from weapondefs
2. Control minmax alpha and alpha decay (determines how long the texture decays) from weapondefs
3. Control the grade of glow (maybe how long such glow should stay).
4. Add support for glow colormaps
5. Add a parameter controlling the color elimination determined by dot product of normal and projection vector.
6. Check if LOS shading is something worth doing.
7. Allow forced direction of scar projection (in weapondefs)

[sprunk]

~~ZK doesn't seem to have ground decals anymore in new engine. 5a. Make it work off existing scars (with no normals etc defined), OR 5b. Provide some sort of guide on how to migrate old decals to new style~~

GoogleFrog has them, maybe it's my setup? Worrisome anyway, I'll see if I can find some more info tomorrow.

[GoogleFrog]

Make the ground decal system able to do everything the old one did.

[lhog]

GoogleFrog has them, maybe it's my setup? Worrisome anyway, I'll see if I can find some more info tomorrow.

New decals worked for me in ZK. Check your setup doesn't have negative or zero GroundDecals value in ss.cfg

Make the ground decal system able to do everything the old one did.

What does the new system can't do what old one could?

[lhog]

Revisit the underwater rendering code:

[springraaar]

There should be a way to set the color of the base texture, even without glow, like multiplying color values : the lighter the pixels the more they change towards the new color, black remains black.

[sprunk]

Add a unit (feature, weapon) def array with strings that will get added into the decal atlas. Like this

barracks = {
  metalCost = 123,
  buildingGroundDecal = "barracks_floor.tga", -- used as decal by default
  sfxtypes = {
    groundDecals = {
      "barracks_wires.tga", -- parsed by engine and added to decals atlas as if it was in resources.lua
      "barracks_blabla.tga", -- ditto
    },
  },
}

Essentially, the same as the existing sfxtypes.explosiongenerators for CEGs: https://github.com/ZeroK-RTS/Zero-K/blob/9cfeaa7e5db7757da2dcb4a7b01ef5666626e718/units/commstrike1.lua#L54-L58

Modders adding/tweaking individual units won't know about some obscure resources.lua sitting in some other file. If they do know and get access (e.g. it's a larger mutator) then it's still bad though because Recoil support for reading the underlying file when overridden by a mod is quite bad (= you just can't) so an overridden resources.lua would start bitrotting immediately.

Further remarks:

• defs can't change so this doesn't break the "done once at start" assumption
• in theory resources.lua can call defs.lua to parse unit defs and then append these on its own to the upcoming decals section, but it would be terrible design to parse defs twice
• expose in UnitDefs

[lhog]

So in https://github.com/beyond-all-reason/spring/pull/1371/files I've implemented most of the wishlist's items: 1) Initial and time-to-live values for alpha & glow 2) Ability to specify the list of scar IDs for a weapon 3) Support for the decal tint color (currently not wired on the CPU side), I plan to expose it only to Lua. Tint color of vec4(0.5) is no tint effectively. 4) Glow colormaps 5) Dot product elimination exponent 6) Forced direction of scar projection 7) Extra decal textures in the resources.lua (sorry @sprunk unitdef/featuredef didn't look appropriate to me)

Now I've never tested that code. I guess I'm looking for a volunteer.

[sprunk]

Scar specification interface seems bad

- scarIndices = "2 3 7",
+ scarIndices = {2, 3, 7},

[lhog]

Scar specification interface seems bad

- scarIndices = "2 3 7",
+ scarIndices = {2, 3, 7},

I'm unsure if we have the proposed convention for any weapon tag. If so, can you provide an example tag that is handled like that?

[lhog]

https://github.com/beyond-all-reason/spring/releases/tag/spring_bar_%7BBAR105%7D105.1.1-2419-gd489451 https://github.com/beyond-all-reason/spring/releases/tag/spring_bar_%7BBAR105%7D105.1.1-2420-g2c9b693 https://github.com/beyond-all-reason/spring/releases/tag/spring_bar_%7BBAR105%7D105.1.1-2423-g06a2622 to conduct the testing.

[GoogleFrog]

It seems to work reasonably well. There are some bugs though. I exploded a bunch of singu spread out all over the place, and something really weird happened in the top left here.

Exploding all of these at once seems to just leave a scar in the top left, with blurriness elsewhere.

2423: 2399: 2314: This situation is working better than 2399.

[GoogleFrog]

The blur problem and the "single scar" problem are quite visible here, exploding 20 shieldbombs.

2423: 2399: 2314:

[GoogleFrog]

The blurring of the terrain happens even with small explosions, where the file size for the decal should be sufficient. You can see the detail in the explosion in the mostly opaque bit, and how it becomes blurry above. So the gameside solution to this is beyond me. It could be an engine issue, or I need to know how to set up these assets.

[GoogleFrog]

2423: 2314:

Structure ground decals are suppose to fade in with build progress. In 2423 they appear instantly.

[GoogleFrog]

I have not been able to reproduce the weird explosion, but it reproduces in the replay.

It also does a weird thing when I wiggle the camera.

2024-03-24_08-40-50-997_FolsomDamDeluxeV4_105.1.1-2423-g06a2622 BAR105.sdfz.txt

https://github.com/ZeroK-RTS/Zero-K/commit/865be529c5657d7f2108bdb8d4d10a985f7a54d2

[GoogleFrog]

2314 has the same sort of overlapping explosion issue, but not quite as bad. Possibly because it is hidden under the grey-brown bits on the edges.

It works a bit better because the faded edges have detailed terrain underneath, rather than blurry terrain. Which is to do with how old decals are a thing drawn over the terrain, while the new ones are some sort of texture blending.

[GoogleFrog]

This is what 100 shieldbomb looks like in 2123:

All the decals have disappeared except possible two in the top left. The rest is blurry terrain.

To sum up, here are the issues as I see them.

• The texture stretching and cutoff bug shown in my replay.
• Structure decals not fading in over the course of construction.
• Most of the decals "disappearing" when many happen at once in a small-ish area.
• The terrain being passed through a blur filter underneath such stacked decals.

The old system did not do much better on the bottom two issues, but I think it made better compromises. At least, with the decal images that I am using. But I don't know what the new system wants from the images, so would need guidance there.

[lhog]

So a few things I've checked so far:

1) "Blur" is actually mostly an issue with the decal asset itself (at least with the implementation as is). See the screenie when the scar is mixed with the map color (low res) and not mixed with anything (just blended) in the order of application. As you can see the modulation with the map color makes issues somewhat more visible, but mostly it's seen without any modulation too. I think if you remove that thick whiteout edge of the texture it should perform better visually.

2) Structure decals is an implementation oversight, I probably missed they were appearing gradually in the original implementation, should be not hard to fix.

3) Disappearing decals can be seen even with 4 explosions: Every next explosion washes out the previous one. I suggest you try Anarchid's scars as well.

4) Invalid projection / stretching was caused by invalid normal vector obtained on the CPU side at the time of explosion. This was probably a temporal phenomena caused by the ongoing terrain deformations. The shader can sample terrain normals by itself, I've switched to that implementation for now, but since that is dynamic it can produce funny artifacts in case terrain is rapidly changing (read mahlazer and alike). Pick your poison. Nowadays you can specify the forced projection vector in weapondefs, but I don't think you can yet for "just" explosions, maybe it's the way to go.

Now my plan is to fix: 1) Structure plate decals fade in. 2) Try to batch / cluster explosions happening in one frame, so one giant scar is produced instead of many small ones. 3) Look if forced projection vector can be added to explosions unrelated to projectile hits. 4) See if I can solve the teleporting footsteps easily.

[lhog]

https://github.com/beyond-all-reason/spring/commit/fb3eeba2a00a603a8f6ba13f3dd2f2cbad1e9c16

I've also had a look and concluded that making the decals batched is too troubled nowadays as there are different fine tuned parameter available per an explosion event: forced projection vector, different valid scars, different glow maps, tint, etc. It's nearly impossible to bin and batch them properly.

[lhog]

have a look at this one https://github.com/beyond-all-reason/spring/releases/tag/spring_bar_%7BBAR105%7D105.1.1-2438-g6d74e91