vladislavbelov

Not necessary to use ray-* techniques for volumetric, but other techniques like direct volume rendering or volumetric particles have an own cost. Btw, we use a parallax mapping, and it's a kind of the ray marching. Yeah, that what I'm talking about.

If we're using volumetric particles it should be ok. But for flat/smooth particles it I'm not sure that the number will be enough for all cases. There is a question, how much different types of clouds we want to support.

But how big will be the attribute buffer if they all are moving not in the same direction? To produce natural clouds it requires a lot of particles. There is a good way with volumetric clouds, but it's pretty new to support not new videocards. The simplest way is use a flat height texture (i.e. an analytic modification of the Perlin noise) with a parallax like shader. But it looks simple too.

Yeah, in case we're rendering clouds and their shadows. But, usually in game player shouldn't see clouds, because they may block a view. Only for a far zoom. But for usual zoom we can do simpler and cheaper things.

Where the 800 value is from? Number of attributes may be limited by VBO size, texture size or whatever you use for the instancing. I.e. you can get attributes from a texture in the fragment/vertex shader, so the maximum number of particles would be MAX_TEXTURE_SIZE / ATTR_STRUCT_SIZE. I think that too. Also we don't have to render particles for the shadow map every frame, if all clouds are generated procedurally and moving in the same direction.

Why only 800? You can draw 1e3, 1e4 even 1e5 particles (if it's a simple quad), and it works good. You may not cache the rendered sky, only prerender the atmospheric scattering of the sky and subsurface scattering of the clouds. And then render them in the real time.

I think, there should be a version/about menu item.

It can be done by few (1 for sky, 1 for particles) draw calls, but yes, it noticeable costs more than the current solution.

2.6.0 is version of the TortoiseGit. What's an input for the "git --version" command?

The last version is 2.16.2 for Windows.

It's the pretty new error as I remember (mid 2017). So you could try to update your Git. What's your current Git version (use the "git --version" command)?

Ah, you meant cheats. The user was a server, so he controls his state, but any player, that will try connect to him during his memory changes, will get an OOS error. Also Cheat Engine is real overhead in this case, since a user can modify JS files, particularly simulation things. So the game isn't actually hacked.

Text overflow or what?

Only if you can't use it. Most of all modern games use it (i.e. GTA V, 16bit float per component, the pretty fast game). No, we don't have a "full" control yet in the pyrogenesis. Because in the first pass we render a scene into a simple RGBA buffer (8bit per component) and the "HDR" shaders works on the next pass with already clamped values. So the precision is low. I like changes, but there is a problem, we have many maps. And artists/modders may want to use different settings. So it'd be ideal to fully customise the shader.

You understood me incorrectly. I didn't said that my implementation is the correct Reinhard one, I only mentioned that the Reinhard is simple and can be used easily here too. Lets return to the HDR. I said, that I prefer HDR > LDR than LDR > LDR for not one-pass pipeline. Because a loosing of high color values, that stops artists/modders to change exposure/gamma freely. Please, look at the example that send above: http://marcinignac.com/blog/pragmatic-pbr-hdr/305-exposure-basic/. For disabled gamma (doesn't make sense what it means in this context) and some exposure values all dark or light areas are losing details. So my point is to use float textures for g-buffer like data when possible.

Yes. And I think we're talking from different sides and we don't understand each other. What I mean: Rendering scene into a float (i.e. RGB32F) buffer with original brightness (vec3 color) > selecting a gamma (by a pregame setting or on the fly) (float gamma) > a simple tone mapping (like the Reinhard one) (color = color / (color + vec3(1.0)); > a gamma correction (color = pow(color, vec3(1.0 / gamma)).

It's not correct. Just do a simple math: in case you have a very light color: (R:1e6, G:1e3, B:1e3), then with LDR it will be (R:255, G:255, B:255), but with HDR it will have a different distribution depended on the gamma. So you're missing a color itself with only LDR. (If you are using HDR/tone mapping as a separate step, not all things (model lighting, hdr, color correction, etc) together in a one shader).

I didn't mean the lighting from bloom, I mean a visual effect for players. HDR allows you to store a true brightness of each pixel, so on the HDR>LDR step you will get a more correct lightning.

Bloom simulates a very light things, but you still can see all details in shadows. It's wrong and looks weird. Obviously that a pixel color usually can't exceed the 255 limit. So HDR shouldn't be just rendered as is, it should be converted to LDR with a color correction. FYI: http://marcinignac.com/blog/pragmatic-pbr-hdr/

It's not art, it's a alight. We need to use PBR, AO and correct HDR to solve the problem. A shadow ref:

If you would look at these white roofs, you may notice, that you still see not black shadows. Our HDR doesn't work as HDR

Currenlty FXAA doesn't work perfect for the 0 A.D., but TXAA or MSAA may solve the problem. FXAA:

I agree, that the code isn't the best for CSM, but performance looks better in a comparison with the current one. Some AAA games like it (i.e. JS3). Also CSM has square/rectangle pixels, so it's more nice shape of the pixel. I like PSM, but it has a worse shape, and sometimes there are glitches. @stanislas69 already noticed visual errors with a rotating camera for the current algorithm. About performance, I suggest do not say much words without tests. I agree about errors. But, it's cheaper, and with clever packing it works good. I.e. JS3 mentioned above (I need to find a ref). I trust your results, but there're AAA examples. So, again, tests and tests. Some modders and artists wanted to have many lights (i.e. arrows, torchs). Deffered rendering allows you to use MSAA too, but with a different cost.

Shaders don't, but a video driver does. I.e. we still support Intel video cards, which can have a version 3.0 or lower, that doesn't have many nice features. I wanna change the current shadow mapping way, because for low angles we have a low resolution per terrain unit. I'd like to use PSM or CSM, and I'm more near to CSM, i.e. 2 cascades. I agree about HDR. Also we don't have deferred rendering yet. About formats RGB16F or RGB32F has enough precision, but it's expensive. So if R11G11B10F will be enough, then we have to use it. Because it's 4 times cheaper. FPS meter isn't enough, we need to use more strict tests. Because the FPS meter has a noticeable error.

It's not possible yet, because we don't drop GL2 yet. But it'd be good to have a switchable renderer in the future. What's broken? It doesn't run? You can make screenshots from the game. https://code.wildfiregames.com/D1402 The current postprocess isn't completed. I.e. we can't select multiple effects. Also HDR isn't actually HDR, it's usual LDR, but with color corrections. We need to use R10G10B10F or RGB32F for true HDR. Any filtering is noticeable under a low hardware. It'd be good to know you hardware and some charts to compare results. I'd like to see MSM.