vladislavbelov

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).

Overdraw is important. Though modern cards have things like early-z which reduces cost of opaque objects. Anyway our current problem is that we're CPU bound on most platforms (beside some potato GPU). Planned for A25.

Shadows have offset, it's called bias. But it won't help here, since offset/bias removes flickering on surfaces that cast and recieve own shadows. But the issue above is about flickering on edges when camera is rotating.

I suppose the mentioned problem is more about the light space moving. So each next camera position (particularly rotating, it's not so visible during camera translating) a shadow map texel has a different position in the real world space. We already have a some kind of solution for that. It's not the production ready, but it works. I plan it for A25.

It doesn't solve the problem with drivers, when the max number is 16 but it doesn't work like expected. We're in FF

For our case we need to reorder high-level operations first to make it significantly faster. It works mostly for relatively simple operations, any non-intuitive logic might break compiler's optimization. We have code local threads, but we want to have a task manager (thread pool) to remove such local management.

It doesn't use alpha planes, it roughly approximates light scattering. And it doesn't require new GL version. It doesn't work in that case, because fog hides details. Different maps have different heights and you have to be sure that you're able to see details on each map.

Any solution with a gradient on skyboxes will have such artifacts (just for different angles), because fog calculated by distance, the sky is at a far fixed distance. So fog should be calculated by distance and height. I have a solution for that but it requires to adjust fog settings for all maps.

Could you attach svn version, full graphics settings and logs?

It doesn't matter how many cives you haves, the number of different meshes (their variants) per frame matters.

Draw call is a single command to draw a mesh (usually) - a part of some object. If it's not rendered then it costs only memory. But if you see all these knife types, then it might have an impact. Yes, 3 or 5 knifes won't make the performance noticeably worse. But when you have a whole map of different variations it might become noticeable. How it speedups you might check with bb (entityvariants) and wraitii (instancing) patches.

Expand can be added by someone (it's just JS GUI changes). About flares, @Imarok has a patch about ping on map.

I remember there was a discussion about round minimaps here. D2216 was just committed, so it's possible to have round minimaps now (at least visually).

I think no. Maybe something with driver. Could he try to just disable shadows (and re-enable again to compare results) with enables GLSL? The terrain has something like Moiré pattern. Also it seems GUI doesn't have such problem.

Yes, but people use not the only one unit. There might be 2 or more. Unfortunately (especially on modern HW) in our game just a number of drawcalls matters (doesn't matter how big a drawcall is, "big" in reasonable bounds), the number of drawcalls and related state changes is the bottleneck now.

If they're not used during all game - yes, they shouldn't affect performance. But if they were placed (or even drawn) then they might. Because you need to load all needed resources (cost memory). You need to draw at least one frame then you need to make some state changes that also affects performance of the frame.

I'd prefer to have low number of knifes for all civs The problem is that you can't notice the difference by eye on modern hardware like 1050/1660+, but we have a lot of meshes each of them increases number of GL state changes which decreases performance (so in total they affect performance significantly). Also more different meshes makes instancing less applicable.

Unfortunately variation affects performance. And I'd prefer to have at most 3-4 different knifes that are significantly different.

How many polys? Which materials are used? And why do we need so many small and so similar elements? For example #2, #4 and #8 look mostly the same with a usual camera distance.

I see different shadows qualities, that might affect render performance as well. Also you have different simulation speeds.