vladislavbelov

Preliminary results for our statistics: 800x600: 0.31% 1024x768: 0.88% 1280x720: 2.28% 1280x800: 2.11% 1280x1024: 1.80% 1360x768: 1.49% 1366x768: 21.68% 1440x900: 4.52% 1536x864: 4.43% 1600x900: 5.05% 1680x1050: 2.68% 1792x1120: 0.39% 1920x1080: 37.87% 1920x1200: 1.67% 2048x1152: 0.44% 2560x1080: 0.79% 2560x1440: 5.70% 3440x1440: 0.92% 3840x2160: 1.40% Other: 2.15%

It's better to draw:

That texture doesn't have mipmaps, because it's generated each frame.

You mean refraction/reflection maps?

It'd be good if you'd upload it on the phab.

Actually Shlick approximation de facto is a standard in the graphics and games industry. And even more it's imperfect for some cases on modern hardware. People try to find more accurate approximations: https://belcour.github.io/blog/research/publication/2020/08/26/brdf-fresnel-decompo.html It's true life. But I'm working on water refactoring. And I've already removed a bunch of in-place hacks.

You can always check your frame by capturing it with RenderDoc or something similiar.

Yay! Down with workarounds!

The same as skies, they both are reflection, refraction and absorption. I don't see much difference in terms of math and energy conservation, ambient color or cubemap is another hack to make things look more realistic. And on modern hardware you can find pretty cheap techniques to get the second reflection (beside ray-tracing).

It happens in our code, and usually it's just a workaround to make it look better. You haven't seen the water one before I've done a cleanup for it.

I suppose it contradicts to your patch for the current game. Because you decrease ambient from skies for vertical surfaces. But AO is used for any kind of indirect light, including sun direct light reflected from some surfaces, which is more powerful than skies ambient.

Per draw call constant. But some constant might be per frame. It's not interpolated by vertex shader, because vertex shader knows nothing about fragments. It will be interpolated on or or after rasterization step. Usually it's called per-pixel in both modes. Only some driver implementations allow you to force per-sample executing. Mostly, but not in that case. vnormal isn't normalized, so it'd be near but not always cosine.

I suppose it's not because they don't want to, but because they can't. Since checking BRDF for every combination of pixels of different textures is a very complex task. I believe there's no fast solution in the whole production world of renderers. So by your measurements there is no production software with real PBR. I suppose you mean 1.0 by white. Since it's not a color, a ratio of reflected/scattered and absorbed. You're just looking on them at very high angle I believe it's not hard to meet a 90%-95% mirror, especially with a metal back I think it's important to note for those who is unfamiliar with PBR, that the reflection is colored, because each collision of light with a surface absorbs a part of the light energy and absorbs differently for different wavelengths.

On old hardware - yes, on modern we might render it into HDR render target and apply tone mapper afterwards, or just apply tone mapper directly. The problem appears not only for white but for any color that has a component near to 1.0 (255), like red, green or blue.

Interesting theme In theory there are no colors at all, everything is a subjective perception. So there is no computer color/finite value that might represent any of real color. I suppose he means that your formula gets an overflow as you get a color value more than 1.0 (255) for some components.

On phab - yes.

Any video? Might be a hotkey issue, Idk.

Haha, yes I've just removed ability to use GL1 with fixed function pipeline where you can't write shaders at all. And we have about 100 players which support at most GL1.5. Also people (especially from open-source) sometimes are asking do we support low-end hardware. That's cool! Though I don't know it can be achieved in our case on old hardware with all our limitations . You might add your code under conditions as well

It doesn't use normal texture if it doesn't have one. Just uses primitive normal.

I'm talking about how many textures an artist should create. You're talking about technical implementation on the engine. And indeed it might be packed. As a normal map might store only 2 bytes per pixel. And another 2 bytes are for something else. I don't mean something special, just a general approach. We can define it as we want. The main thing to make it work for us and for artists. And another problem for adding PBR is that we still have old hardware, which has a pretty limited amount of resources. And we need a plan what to do with that too.

Yeah. Usually you'd have (normal map + ao) + (diffuse + (glossiness + specular) | (metallic + roughness)) = 5 textures. Sure, you don't have to use it in a general game. In our case using these textures allows to describe real world material. Which means relatively predictable results for different map settings and physically correct lighting.

Actually I'm all for reducing such freedom which breaks introducing general algorithms like you suggested. But AFAIK there is the only one way is to move to PBR. I've already removed separated ambient colors for units and terrain, for what I was kind of "blamed". Every modification of a general algorithm is applied to the custom map settings can significantly change a visual style of a map. So it's not our goal or wish to make a resistance, it's just a pretty old project that have own workaround and not ideal solutions. Nobody wants to make resistance and hostility. For sure it might be incorrect. But the problem is that there is a map that uses an incorrect color and which is compensated by other settings and it looks kind of "nice". After changing the algorithm it might become look different. And that "different" might be much less nice. And for that cases you need to find all maps with the incorrect lighting, change algorithm and test that it looks ok, and artists should say that it looks ok.

In games a single ambient light doesn't mean only skies. It's just an old tool to set color of objects without sun. So it's not guaranteed that the value of ambient color will be bluish on all our maps, it might be yellowish or whatever an artist want. Yes, that's a way to make a light looks more realistic. Usually it's called radiance environment map, and indeed it might use cubemaps, but in some cases harmonics. And as @Stan` pointed, it requires a lot of artist work. And checking that everything works fine. Also without using physically correct lighting it won't give a lot better results.

That might happen only in case you have no directional light (but even in that case there are cases when the up light isn't so bright as horizontal ones). But a usual scene has a sun (or something like that), which light is pretty well scattered and lightens different areas. To check that it works correctly you need to check many maps with different ambient color values. v_normal is declared only if (USE_SPECULAR || USE_NORMAL_MAP || USE_SPECULAR_MAP || USE_PARALLAX). It's a reducing number of shaders by combining them. These conditions are set by a material and model settings which were set by an artist/modder. It should be Y, Y axis looks up. As I said above different models have different materials, different materials mean different conditions.

No, because of a lot of OpenGL function calls (including draw calls).