stgatilov

beta210-06 is available.

It is known that AMD OpenGL driver performs texture compression very slowly. In 2.09, all normal maps were compressed to RGTC by OpenGL driver. In 2.10, they are compressed by our C++ code. I think that's the main reason why you see such a huge improvement: it is much less for NVIDIA, for instance. Also, keep in mind that when you start a mission on TDM installation for the first time, data is loaded data from disk, but when you load it for the second time, it is most likely loaded from RAM (OS disk cache). This can noticeably affect your measurements, but of course it won't cause 8x difference The difference due to caching was relatively modest in our tests.

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.