vladislavbelov

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.

Could you press F2 (it takes screenshot from the internal renderer) and press Print Screen (it takes screenshot from the game) and post both pictures here? If I understood you correctly you say that user can't fix awareness. But actually user can for Windows 10 and iirc Windows 8.1 and it does work. You need to open executable settings and customize the DPI settings. Then you need to add the gui.scale setting to user.cfg with a value multiple of 2.

We can use kinda forward+ for GL2+, so it's not so far. And deferred rendering prevents MSAA, most everything in graphics is tradeoff. Most modern graphic systems in games don't cast shadows for dynamic lightings, might do only for few (like 4-8) nearest to a player lights. Not really, you more wanna say too much to review at once x) Profit of the instancing is pretty tricky, it highly depends on a scene. Look at Yves measurements for deep forest. For obvious reason the difference isn't so big about ~10%. It depends on how to add lights, usually the number of fragments doesn't scale with the number of lights. And there are a bunch of pretty old techniques to reduce amount of rendered fragment. In terms of the game implementation it has most needed features, but in Atlas we can't edit all its parameters yet, only a part of them. But it's possible to edit the map file or use JS to control all parameters.

Thank you very much, you've done that perfectly! Yeah, I was right, jumping bounding boxes appear on the video. It seems celt_trader commit has tweaked that behaviour.

Yeah, that's the correct picture. Now questions: a) do you see flickering from that distance? b) do the boxes flicker (their sizes are changing along the sun direction)?