stgatilov

I don't mind commenting out bumpmap line. At least this is not a hack.

The main thing i that function user_addon_init is called by every FM at start, and you can override this whole file. So you can include other script files and call their functions. However, you cannot change the time when this function is called.

I don't like it. What about hundreds of other materials which have a stage of the same kind? Why are you sure it actually helps universally, and it is not plain luck that it worked for you this time? In fact, the C++ code already binds _black texture if specularmap is not specified.

I'm pretty sure that opengl32.dll does not contain GPU driver. Imagine you have two monitors, with AMD GPU connected to the first one, and NVIDIA GPU connected to the second one. When you start game, OS chooses the driver depending on which monitor it was started at. If there is only one opengl32.dll in C:\Windows\System32 and application loads it statically (that's the usual case), then how can OS choose between drivers? With OpenCL, you can explicitly choose vendor and device to use, which is yet another reason why the DLL which application uses cannot contains the actual driver. Then typical thing is to have single opencl.dll which redirects API calls to whatever vendor driver being used right now (vendor drivers are called "Installable Client Driver"-s). I even built such a redirecting OpenCL library myself, and it was deployed locally with an application, in order to make sure it can boot even if there is no GPU driver installed in OS. GPU driver is usually located in entirely different file, like nvoglv32.dll for NVIDIA. Moreover, you cannot be sure that this is the only file. Recently one guy here tried to replace the Intel GPU driver manually, and got some error like "failed integrity check", meaning that the vendor or the OS itself probably checks if the driver code was not messed with. Better stop messing with drivers!

And which file do you think contains OpenGL driver?

I wonder what does it mean "copied driver" ? I hope you don't just copy some files of the driver around your OS? Also, using drivers which came out before Windows 11 is probably a bad idea for you.

I think tdm_user_addons.script was added specifically for this, although the problem of having several mods at once is sort-of unsolved...

It is all messing with symptoms. It is much better to find the exact place where NaN or Inf appears and put a fix just before that. That's guaranteed to work, since it does not allow NaN to appear.

If X = Nan, then IEEE-compliant implementation should produce: (x > 0 ? x : 0) => 0 (x >= 0 ? x : 0) => 0 (x < 0 ? 0 : x) => NaN (x <= 0 ? 0 : x) => NaN We don't know how exactly max/min is implemented in GLSL, same for clamp. Even worse, OpenGL does not force any particular behavior of NaN onto implementations: they can are free to have NaN or e.g. immediately reset NaN result to zero. I believe using NaN in any builtin function including clamp and min/max is undefined behavior according to the spec. The worst thing is that compiler optimizations can change the way comparisons work. On C++ side, this is usually controlled by "fast math" flag. Since we don't enable it, we can be certain that we can work with NaNs properly in C++. But I think GPU code is optimized more aggressively, so who knows what compiler can or can't do.

Floating point arithmetic has no wrap-around unlike integer arithmetic. You cannot add large positive numbers to get a negative one, you can only get positive infinity. If you multiply it by zero, you get a NaN. And if you have a NaN, it will always remain NaN, having no sign at all. It does not matter whether the image becomes brighter or darker, just some pixels become NaN.

Maybe something is bad with your driver or GPU? The menu has nothing to do with interaction shader, in fact its shader is very simple. Maybe texture compression is broken? Maybe try some of the new cvars like image_mipmapMode and image_useTexStorage. Why do you think there is some problem with negative values?

Then you should selectively disable parts of the math in advancedInteraction until you find the root of the issue. Just remember that special values have some quirks. For instance, if you compare NaN with anything, comparison always returns false. Although I'm not sure optimizer won't break that rule... Since adding specularmap helped you, I think "specularColor" value should be a good start. If you reset it to zero after it gets computed, does the issue go away? If yes, then try various subterms it is composed from... Also, don't believe clamps. It is undefined what clamp returns for NaN, and I won't be surprised if it remains NaN even though it is stupid.

@AluminumHaste, does the problem go away if you replace "return totalColor;" with "return vec3(0);" in interaction.common.fs.glsl and do reloadGlslPrograms? Assuming you use "r_useNewBackend 1", of course. If yes, then the problem comes from this shader.

Nope, they just change texture coordinates. The colors are still added.

The problem may be caused by bump stage? In the debugger, I see that this material (soft one) has three ambient stages and one bump stage. Three ambient stages is the main one plus two from frob-highlight, and the bump stage is probably caused by bumpmap line. To be honest, I don't know what's the purpose of bumpmap line in this material...

I don't see any subtractions in this code, only additions.

Without something like "blend add", this becomes ambient stage, which is probably processed by ambient interaction shader.

Ehm... and what is the fix exactly?

That's because the issue in bloom implementation was fixed by added clears. My hypothesis was true: that's the special floats (Inf or Nan) with unprotected blending that caused it to stick. Now that we got rid of the sticking, the core problem of getting special values still persists. And it can be generated by absolutely anything in our shader park.

Interesting... Thinking about it again, special floats can stick to any floating-point FBO after bloom just as easily, if blending is still enabled. @AluminumHaste, try svn rev 9842, please.

@AluminumHaste, do you have Visual Studio installed? I have committed the possible fix in svn rev 9841. UPDATE: Here is executable build from fresh SVN.

How can you explain that the problematic spots stick forever? You can disable bloom and it disappears, but then you enable it back and have exactly the same black/red/whatever spots, even though you look in the opposite direction already. Where is this magic memory?

Are you sure you can? I tried adding sqrt(-1.0 - color.x) under some circumstances in interaction shader, and I could not reproduce the issue of sticky quads. For me, no information from the previous frame gets into the next frame.

Do you use up-to-date Chrome? I heard that youtube sends video in different codec to Firefox, for instance

Ok, here is one hypothesis (ping @cabalistic). Our bloom implementation does not disable blending. In only sets blending function to (dst * 1 + src * 0). It looks like src * 0 is always zero and this equation is equivalent to disabled blending. Except that in 64-bit mode we have floating point values in framebuffers, and floating points numbers have special values like inf-s and nan-s, which don't become zero if you multiply them by zero. This effect disappears if we clear framebuffer every time before rendering into it, since any special value will disappear the next frame. However, I see that upsampling FBOs are not cleared (see BloomStage::Upsample) unlike the others. So I suppose that a special float value is born somewhere in upsampling framebuffer and it sticks there forever because we don't clear this buffer and blend new frames onto the old image. Getting special value in rendering is not nice, but I think we will won't be able to get rid of them completely. However, if these values stick forever, then that's a big problem So I guess I'd not try to find where the first special value comes from, and just fix bloom code. In order to check if this hypothesis is true, I need a help from someone who can 99% reliably reproduce the problem (I can't reproduce it on my GTX1050ti). And if this person can compile TDM, it would be even better I think about adding "qglClear(GL_COLOR_BUFFER_BIT);" just before "RB_DrawFullScreenTri();" in BloomStage::Upsample.