stgatilov

I have no idea if this is fixable, since TDM does not make any difference between the two modes. "Borderless" fullscreen only makes the TDM window 1 pixel wider in vertical direction, which supposedly forces most drivers to not do anything fancy but go through regular windows compositing. Also the two modes differ in how they work if you set non-native resolution: proper fullscreen will ask your OS to change resolution globally, while borderless does not support this case at all (not sure what would happen). You can try to play with "Uncap FPS" and "V-Sync", I'm sure some of these settings will remove FPS oscilations.

I wrote to the mirror owner. Meanwhile, I think you can choose mirror manually (not Kowmad's) to avoid the issue.

beta210-05 is available. This one includes 32-bit executables. If you can run them without much trouble and play moderate-sized levels, please give them a try.

That's one reason why there is no menu setting for this On default settings, volumetric lights should not cause much more trouble if you can play with shadow maps well (especially if you can play with maxed soft shadows quality). But in some cases (especially with sharp shadows) the effect might look "noisy" due to dithering. We hope to fix it for 2.11 without harming performance.

I'm sorry, but we decided to not release it yet... Using it will generate a warning. We have bumped into an issue that fog boundary becomes pretty apparent when you are close to it and look along it. Since I guess this is one of the major issues with the old fog, I think releasing something new with the same problem won't be very helpful. Note that unlike the old fog, the new "volumetric" fog makes the boundary plane apparent because that's how it should be, i.e. this effect is an correct modelling of a box-shaped fog with constant density. That's what makes it hard to avoid (I don't even say "fix", because it is not a "bug").

I think we have fixed it on SVN, but not yet released as beta. I have said several times that downloading all FMs is good only for stressing our mirrors. I'm sure you will not even start most of these missions before you have to download them all again for some reason. This button should not exist Speaking of the crash, we can try the "fun" of crash dumps on Linux... The reference wiki page contains no useful information. I don't think anyone (except for the author) will ever run command line profiler and get any useful information out of it. I thought about writing a wiki article about Tracy profiler with TDM, and main parts (like GPU, backend, frontend, game modeling, various cvars/options affecting them, bottleneck, etc.), but have not done it yet. I profile with frontend acceleration most of the time, and Tracy shows stuff properly. Here is one such example.

It means that most likely you can use this "volumetric fog" in the next 2.10 beta. Unless we decide to block this feature entirely. It is quite late in the beta phase to add any features.

I will not put OpenAL recipe from trunk into 2.09 branch and tag. They differ by two minor versions. OpenAL 1.19.1 was in pure C, and OpenAL 1.21.1 is implemented in C++ and was refactored like hell. 2.09b was built with version 1.19.1, and overwriting it with version so different would be a big lie. Perhaps one can release 2.09c just to update OpenAL to new version, I don't think 1.19.1 was so bad that i made TDM unplayable for many people. Moreover, 2.10 is already in beta, and it is counterproductive to waste effort on 2.09 now.

The coefficient was tweaked for "outdoors light getting into dark room" situation. I don't think the location in your video would have any noticeable volumetrics in the real life, no wonder that default setting is too strong for it. The image is heavily dithered, I suppose compressors have problems with it.

I applied all these changes in svn rev 9804. The alpha equation is a bit different (5.0 coeff under exponent), also added a hack to force opaque fog. On top of that, I applied a bit of dithering to reduce color banding.

This word makes me laugh

Defining cvar as a static local variable is bad practice. Because a static variable does not exist until the function which contains it gets executed. So if you have this function executed at least once, you should have this cvar. If the function was never executed in the current run, then cvar does not exist.

I suggest the following: In shader, return: fragColor.rgb = u_lightColor.rgb * avgColor; and fragColor.a = litDistance * u_dust; In C++ code, always bind _white textures instead of projection and falloff for a fog light. In C++ code, use (GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA) blending for fogging and (GL_SRC_ALPHA, GL_ONE) for volumetric light. This covers the projection/falloff textures and blending behavior. Now add uniform flag "u_exponential", which is enabled for fog light, but disabled for exponential light. Under this flag, return "1.0 - exp(- litDistance * u_dust)" instead of "litDistance * u_dist" into fragColor.a. This should switch from linear to exponential.

I think there is one problem with using current volumetrics for fog. The volumetric lights is some dust/moisture in the air, which should have two effects: emittance: the dust emits light towards viewer (in fact, reemits the light coming from a strong light source) fogging: the dust makes objects behind it less visible For a volumetric light, "fogging" effect is much weaker than "emittance" effect, up to the point that it is negligible. At least that's how it works on small light volumes, and we designed volumetric light for small light volumes only. A volumetric light generated by bright sun/moon inside a room adds some intensity, approximately proportional to the width of light volume seen in considered direction. The objects behind light volume are not toned down. If you there are dark and lit areas behind volumetric light, both will become brighter. Our volumetric light works via additive blending, and color is proportional to distance covered by light volume (double the distance, and the amount of light is doubled). Fog is not generated by light source, thus "emittance" effect makes no sense for it. It covers large distances (often just everywhere), thus the "fogging" effect happens. But fogging effect works differently: it does not light up the picture, it makes the color of background object weaker, replacing it with its own. If you see dark and light area behind fog, dark area should become brighter (closer to gray), and lit area should become darker (closer to gray). Fog should be implemented as alpha translucency (DST * (1 - src_alpha) + SRC * src_alpha), with alpha value computed as exponent of the distance covered by light volume (if fog/background colors are used in 50:50 ratio, double the distance, and it will become 75:25 ratio). Also note that additive blending (as used in volumetrics) is order-independent, but alpha blending (as should be used in fogging) is not. It means that translucent objects inside fog inevitably look wrong: either they are fogged as if they were near the closest solid object behind them, or they are not fogged at all. I don't think there is a way around it, just saying that this problem will return compared to the "light everything up" additive behavior.

The main point which can be seen there: projection and falloff textures from material have no effect. They bind hardcoded textures in their place, which probably contains some math baked in. It means that we should do the same.

I guess you already realized that translucent objects with volumetric shader doesn't really work. You need depth buffer to detect distance, and after you draw a new layer of translucent surfaces, you need to update this depth buffer. Some technique of order-independent translucency (depth peeling or alpha lists) can do this, but it is too expensive to be used in a game engine.

Yes, the one you used (and I used) is the old one. It is mentioned in official conan docs (for old versions). The docs for new versions don't mention anything it seems I found some blog article from bincrafters which contains the new address. Conan made a major change in infrastructure, so both the official repo and bincrafters moved.

Yes, adding tooltip broke it. Fixed it in svn rev 16442.

I had this error too, but don't remember exactly how I fixed it. Most likely you have old address of bincrafters in your workspace, which stopped working. You should do something like: conan remote remove bincrafters conan remote add bincrafters https://bincrafters.jfrog.io/artifactory/api/conan/public-conan

Yes, logically, it could control fog color, which is the same as density in some sense. But @duzenko disabled sampling (because it's expensive), so fog color/density is constant for every fog light. Why is it not ideal? What changes do you think about? Copy-pasting is not a good idea, I'm going to remove all code duplication in shader code after 2.10 is out. I simply wanted to understand: how does projection and falloff texture influence the old fog lights, and what is the desired behavior (if it is different) ? But nobody has answered any of these questions yet. Currently I have no idea how the new volumetric-based fog relates to old fog lights in terms of textures Let's first decide where we are and what we want, and then discuss how to achieve that

Mmm... I imagine "fog light" is a special kind of light, which does not light any surfaces, but instead applies some "fogging" on everything. With the recent change, one can switch implementation of "fog light" to exactly the same code as in volumetric lights but setting "volumetric_*" spawnargs. It is clear that shadows are ignored in this case because they are never generated for a fog light anyway. What is no clear however: what about projection and falloff textures? What is the meaning of these textures for a fog light? Is this meaning correctly handled by the volumetric implementation? With the way @duzenko did it, shader just takes average texel color of each texture, and multiplies output color on both of the averages.

As far as I remember, the wording was changed because "install" usually means downloading something, or doing some nontrivial os-dependent work. Nothing like that is done, you just select the mission, and restart engine in order to e.g. update main menu GUI.

Try again on the latest trunk. I changed a few bits, but it still does not build on my Windows machine. Stuck on msys package not building You need to enable revisions: conan config set general.revisions_enabled=True and to add proper bincrafters in case you did not yet: conan add remote bincrafters https://bincrafters.jfrog.io/artifactory/api/conan/public-conan

That would be a good approach if package manager does not alter existing packages. But as we just found out, it does. That's what throws me to the opposite approach: fork packages and use local copies. Local copies don't change by themselves

beta210-04 is available.