tweak(drawable): Decouple material opacity of detected stealth models from render update #1963

Caball009 · 2025-12-08T23:26:24Z

~~Fixes issue: #1953~~

Fixes issue: Enemy stealthed units/buildings reveal animation flicker or animate too quickly at higher render FPS #1719

This PR makes two visual changes relating to the opacity step of detected stealth models.

There are 2 commits, with 2 slightly different implementations. The first was an attempt to make the code more optimized. It has a downside: if the render frame rate is fluctuating a lot, the opacity step can be slightly irregular sometimes but nothing crazy. The second calculates the opacity step scalar when rendering. This gives the best results but is more costly.

Before

Stealth detected models were flickering when the render frame rate exceeds 30:

stealth_detected_model_flickering_before.mp4

Stealth detected models were pulsating too quickly when units / buildings were detected by multiple units / special powers:

stealth_detected_model_pulsating_before.mp4

After

Opacity step should now look the same for (almost) all render frame rates:

stealth_detected_model_flickering_after.mp4

Multiple detections make (almost) no difference to the pulsating models.

stealth_detected_model_pulsating_after.mp4

TODO

Decide on implementation
Replicate in Generals

MrS-ibra · 2025-12-09T09:02:00Z

This also fixes #1719 , they are the same issue

xezon

I am confused by the 2 commits. Perhaps open 2 Pulls with each proposal?

Overall, I do not understand why the m_secondMaterialPassOpacity evolution is made so complicated.

xezon · 2025-12-09T08:50:35Z

GeneralsMD/Code/GameEngine/Source/GameClient/Drawable.cpp

+			// TheSuperHackers @tweak The opacity step is now decoupled from the render update.
+			// minOpacity = (X ^ (framerate / updatesPerSec)) -> e.g. [ 0.05 = X ^ (100 / 2) ] -> [ X = 0.941845 ] -> [ 0.941845 ^ 50 = 0.05 ]
+			constexpr const Real minOpacity = 0.05f;
+			constexpr const Real updatesPerSec = 2.0f; // (LOGICFRAMES_PER_MSEC_REAL / data->m_updateRate (15))


Why is the value code commented? Edit: This needs to be fixed

Another question: Does this still work correctly when pausing the game?

Good point, the opacity keeps decreasing and at some point it gets below the minimum of 0.001 and so it gets set to 0. At that point the regular model is shown instead. This'll need fixing.

GeneralsMD/Code/GameEngine/Source/GameClient/Drawable.cpp

xezon · 2025-12-09T08:52:52Z

GeneralsMD/Code/GameEngine/Source/GameLogic/Object/Update/StealthDetectorUpdate.cpp

+			if (theirDraw && !them->isKindOf(KINDOF_MINE))
 			{
-				theirDraw->setSecondMaterialPassOpacity( 1.0f );
+				constexpr const Real minOpacity = 0.05f;


Maybe this value should be part of drawable data? It now exists at 2 places and it needs to be in sync?

Yeah, having it in two places is unfortunate. I think making it a part of the drawable date should work.

Caball009 · 2025-12-09T19:21:28Z

I am confused by the 2 commits.

The second commit is a less optimized but simpler implementation of the first commit, that's all.

Perhaps open 2 Pulls with each proposal?

I think we can forget about the first commit if we decide that calculating the scalar value on the fly is acceptable.

Overall, I do not understand why the m_secondMaterialPassOpacity evolution is made so complicated.

Right, I'll add an explanation. This was the original behavior assuming 30 logic frames and 30 render frames per second.

StealthDetectorUpdate::update tends to be called every 15 logic frames (dependent on StealthDetectorUpdateModuleData::m_updateRate) for every stealth detector and sets the opacity value back to 1.0.
Drawable::draw multiplies the opacity by MATERIAL_PASS_OPACITY_FADE_SCALAR (0.8).
For a single stealth detector, the lowest opacity value is equal to 0.8 ^ 15 = 0.035184.
With 70 render frames, this becomes 0.8 ^ 35 = 0.000405, which is below the minimum threshold VERY_TRANSPARENT_MATERIAL_PASS_OPACITY (0.001) and so the original model starts to become visible.

It's not overly complicated, but since the opacity decreases logarithmically, we need to calculate the right scalar value.

Where does this number come from?

See point 3. I've increased it slightly to a more sensible number.

xezon

Ok I understand the logic now and it looks correct. We need to improve this change a bit.

xezon · 2025-12-13T11:21:50Z

GeneralsMD/Code/GameEngine/Source/GameLogic/Object/Update/StealthDetectorUpdate.cpp

+				constexpr const Real minOpacity = 0.05f;
+				constexpr const Real resetThreshold = 2 * minOpacity;
+
+				// TheSuperHackers @tweak Reset opacity only below threshold to prevent models flickering from multiple detections or special powers.


Does this mean multiple detectors will reduce the m_secondMaterialPassOpacity faster?

It's the opposite. Multiple detectors (and also increased logic frame rate) would set the opacity back to 1.0f faster / more often without this check.

Ok I understand. Would it perhaps be possible to couple the reset at exactly 15 frames (aka updateRate), instead of testing for reaching this min limit? Maybe build a logic frame counter for it?

Then we also do not need MinOpacity at 2 places.

That'd mean the pulsating effect increases as the logic frame rate increases; e.g. at 60 logic frames the effect goes through 4 cycles per second instead of 2.
Does that make sense for things that are purely visual? I'm aware that some other visual effects currently behave this way (such as the clouds, water, trees, and the lights around the supply dock), but I'm not sure if that's desirable.

You are right that makes no sense. We do not want it to be bound to plain logic frames. But you can scale the updateRate by LOGICFRAMES_PER_SECOND/BaseFps, which will be 15*2 at 60 logic fps. I think it would be interesting to know if there are issues with pausing.

I think StealthDetectorUpdate::update can simply set a boolean in the drawable that signals that the opacity may be reset back to 1.0, and then the draw code can handle that. I've just tested this and it appears to work well. It means that multiple stealth detectors and increased logic frame rate make no visual difference.

Performance wise, are you ok with calling pow on every call to Drawable::draw for every detected stealth unit?

Maybe we could store the scalar value in global data and update once per render frame, but I could use some suggestions which of the singletons would be most appropriate for that. That logic would also need access to the updates per second value and minimum opacity, so I'm not sure how to do it efficiently and cleanly.

You can also put static variables in any related class and use that.

I assume currently all objects blink independent of each other. If a static variable would control the evolution, then all objects would blink at the same time. Is that ok or desirable?

I think StealthDetectorUpdate::update can simply set a boolean in the drawable that signals that the opacity may be reset back to 1.0

Wouldn't the theirDraw->setSecondMaterialPassOpacity(1.0f) in the logic update already implicitly signal the reset?

You can also put static variables in any related class and use that.

The idea is to put the scalar value inside Drawable as static inline variable, and create an update function that recalculates it on every frame and is called from somewhere high up in the engine loop.

If a static variable would control the evolution, then all objects would blink at the same time. Is that ok or desirable?

They would still be updated at different times, so they would only blink at the same time if they were detected by the same stealth detector (or at a similar 15 frame interval).

Wouldn't the theirDraw->setSecondMaterialPassOpacity(1.0f) in the logic update already implicitly signal the reset?

That's not implicit but explicit as the logic code would set the value back to 1.0f. What I'm proposing is not setting the value directly, but setting a boolean, so that the render code can check that to set the value back when needed.

Updated commits to show new implementation. I got to figure out how C++98 handles static inline class member variables, though...

… from render update Scalar value is calculated ahead of rendering.

… from render update Scalar value is NOT calculated ahead of rendering.

Caball009 · 2025-12-21T20:05:07Z

I'd suggest to make a small change to the blinking / pulsating behavior: lower the update rate to once per second and increase the minimum opacity to 0.1. It looks like this:

stealth_detected_model_change.mp4

Caball009 added Minor Severity: Minor < Major < Critical < Blocker Rendering Is Rendering related labels Dec 8, 2025

Caball009 linked an issue Dec 8, 2025 that may be closed by this pull request

Stealth detected models flicker too fast in fast FPS #1953

Closed

xezon reviewed Dec 9, 2025

View reviewed changes

Caball009 removed a link to an issue Dec 9, 2025

Stealth detected models flicker too fast in fast FPS #1953

Closed

Caball009 linked an issue Dec 9, 2025 that may be closed by this pull request

Enemy stealthed units/buildings reveal animation flicker or animate too quickly at higher render FPS #1719

Open

4 tasks

xezon reviewed Dec 13, 2025

View reviewed changes

Caball009 added 4 commits December 18, 2025 20:40

tweak(drawable): Decouple material opacity of detected stealth models…

3cd3f42

… from render update Scalar value is calculated ahead of rendering.

tweak(drawable): Decouple material opacity of detected stealth models…

79ca8b7

… from render update Scalar value is NOT calculated ahead of rendering.

Changed scalar calculation logic.

a56e83a

Added call to updateSecondMaterialPassOpacityScalar from engine loop.

21dd3e3

Caball009 force-pushed the rendering_stealth_detected_update branch from 8e09433 to 21dd3e3 Compare December 19, 2025 23:00

Fix for 'static inline' class member for VC6.

45d821e

Caball009 force-pushed the rendering_stealth_detected_update branch from 546c2d9 to 45d821e Compare December 21, 2025 19:48

tweak(drawable): Decouple material opacity of detected stealth models from render update #1963

Are you sure you want to change the base?

tweak(drawable): Decouple material opacity of detected stealth models from render update #1963

Conversation

Caball009 commented Dec 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Before

After

TODO

Uh oh!

MrS-ibra commented Dec 9, 2025

Uh oh!

xezon left a comment

Choose a reason for hiding this comment

Uh oh!

xezon Dec 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Caball009 Dec 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Caball009 commented Dec 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

xezon left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

xezon Dec 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Caball009 Dec 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Caball009 Dec 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Caball009 Dec 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Caball009 commented Dec 21, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Caball009 commented Dec 8, 2025 •

edited

Loading

xezon Dec 9, 2025 •

edited

Loading

Caball009 Dec 13, 2025 •

edited

Loading

Caball009 commented Dec 9, 2025 •

edited

Loading

xezon Dec 13, 2025 •

edited

Loading

Caball009 Dec 13, 2025 •

edited

Loading

Caball009 Dec 17, 2025 •

edited

Loading

Caball009 Dec 19, 2025 •

edited

Loading