stgatilov

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.

But without material frob stages, the objects will be highlighted differently. Some objects are not highlighted at all.

Some news. There are three more outline presets in the latest beta version (mentioned e.g. in changelog in beta testing thread). I can't add them to existing poll, so hopefully someone will create another thread + poll about them. The only thing that I have to say: for me, the dark outline is not doing its thing in typical conditions. When everything is dark (fully dark room), the dark outline is completely invisible, which is not much different from having no outline at all. And it means that if you see a fully-translucent object (like flask) in dark room, you won't notice anything when you frob-highlight it. It does not solve the problem that we wanted to solve with outline.

Volumetric lights were added very close to beta, and they were changed during beta. The wiki page was written for beta210-03 (which shows #9771 in game console), you need this version (which is the latest beta yet) for them to work.

I guess it's easier to fork the old zlib recipe. To be honest, I think badly of conan maintainers who decided to do this change. Changing/deleting recipes retroactively sucks, it's a strong reason for users to store all recipes as local copies even if they don't change them.

Yes, it means that materials should still include frob stages. It is very unlikely that this problem will be resolved in 2.10. I don't like to discuss frob-highlight in generic beta testing thread, since I know it can generate a lot of text We tried the outline approach, but it seems to be wrong way in terms of visual appearance. Players did the right thing and when they voted that outline does not belong to this game, don't blame them. An alternative approach is to retain material frob stages as they are, but add some default highlighting (which should work in 99% of cases). As far as I understand, it will also remove the mapper's pain that you talk about, but without affecting visual appearance.

One thing I don't understand is why Max FPS has so many options. I'd say in such case it should better be a slider with value, like e.g. gamma slider. P.S. Meanwhile, I'm trying to write more tooltips and update existing ones...

Except that it is vice versa: with uncapped FPS physics runs with rendering and the results of modelling somewhat depends on your FPS, whereas with old-style model physics always works at 60 Hz frequency, not depending on graphics.

I think the main reason is that internally there is huge difference between the two modes (Uncapped FPS: yes or no). Up to the point that "Uncapped FPS" mode has been considered experimental for many releases. I don't remember when we last had a problem with it, but we always wanted to have a way to switch it off, and doing so on "Max FPS = 60" is almost the same as not providing any way to configure it in the main menu at all. Another thing is that "Max FPS" was not intended to exist initially, uncapped FPS should just work as fast as it can. But then we noticed that high FPS causes issues (e.g. some sounds disappearing), and we did not manage to fix it properly. We just put a "sane" limit of 166 FPS, since that felt the safest way. Then came people with high-frequency monitors, and they wanted to change this limit to a bit higher that their monitor frequency. At the end someone decided it is important enough for everyone and added it to menu settings. It seems to me that people with high-frequency monitors can live well with both Uncapped FPS and V-sync on, without the need to tweak the FPS limit which was never intended to be visible to end user. If yes, then we can remove "Max FPS" from the menu.

Applied p.1 in svn rev 9780.

It is not too late if someone is brave enough to update all corresponding missions. But it has to be done during beta phase.

I think these two lack tooltip. The tooltip for Uncap FPS should say that this mode allows FPS higher than 60.

Here is how cloudscroll works on fresh SVN (with all kinds of clamp-to-zero present in fragment shader): The volumetric light and r_showLights 4 show the light frustum. You can easily see that floor is lit outside light volume, sometimes pretty far outside, and with ugly scissoring. If we clamp texcoords before applying texture matrix, then the light will always be inside frustum. UPDATE: See it yourself on test/volumetric_light_shadows.map.