Fixing the skybox for maps

[vladislavbelov]

36 minutes ago, aeonios said:

That depends on a lot of things. Since the clouds are moving every frame you probably couldn't cache them meaningfully without it looking wrong. That also heavily depends on what optimizations are used for rendering the shadow map, ie whether any sort of shadow map focusing is used.

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.

[aeonios]

35 minutes ago, vladislavbelov said:

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.

I doubt it'd be an issue if we used unit cube clipping. Most of the particles would be frustum culled by the GPU automatically so the cost of texture reads would be minimal.

[vladislavbelov]

1 minute ago, aeonios said:

I doubt it'd be an issue if we used unit cube clipping. Most of the particles would be frustum culled by the GPU automatically so the cost of texture reads would be minimal.

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.

[aeonios]

10 hours ago, vladislavbelov said:

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.

For particle clouds we're talking a few KB of vertex data at most. For procedural volumetric clouds it's more like 14MB worth of 3D textures and things, and probably a lot more expensive to render. Rendering cost depends a lot on how realistic you want the clouds to look. Extra-realistic looking clouds would also be considerably expensive to render for water reflections, which require rendering and lighting them a second time from a different angle. Personally I prefer to lean towards the side of cheapness.

[vladislavbelov]

20 minutes ago, aeonios said:

For particle clouds we're talking a few KB of vertex data at most.

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.

[Stan`]

Huh guys what about commiting the current fix ?

[aeonios]

23 minutes ago, stanislas69 said:

Huh guys what about commiting the current fix ?

see: 

 

1 hour ago, vladislavbelov said:

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.

I doubt it would matter much anyway. Volumetric clouds require ray marching and ray marching is expensive. I'm not really sure if we can get good cloud lighting for cheap though.

[vladislavbelov]

22 minutes ago, aeonios said:

I doubt it would matter much anyway. Volumetric clouds require ray marching and ray marching is expensive.

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.

22 minutes ago, aeonios said:

I'm not really sure if we can get good cloud lighting for cheap though.

Yeah, that what I'm talking about.

[aeonios]

3 hours ago, vladislavbelov said:

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.

Horrible hacks are possible. We don't necessarily need super-realistic clouds, just a reasonable approximation. For example we could just have all cloud particles below a certain height be considered shadowed.

[Imarok]

36 minutes ago, aeonios said:

Horrible hacks are possible. We don't necessarily need super-realistic clouds, just a reasonable approximation. For example we could just have all cloud particles below a certain height be considered shadowed.

Do I assume correctly, all this only works with a newer OpenGL version? If so shouldn't we/you first make 0ad ready for the newer version and then discuss about how to use the new possibilities?

[aeonios]

4 minutes ago, Imarok said:

Do I assume correctly, all this only works with a newer OpenGL version? If so shouldn't we/you first make 0ad ready for the newer version and then discuss about how to use the new possibilities?

Sort of. It would probably work under the current renderer, but wouldn't necessarily perform well.

[vladislavbelov]

50 minutes ago, aeonios said:

We don't necessarily need super-realistic clouds, just a reasonable approximation.

So it needs to test how it works and looks and then discuss with artists.

12 minutes ago, Imarok said:

Do I assume correctly, all this only works with a newer OpenGL version? If so shouldn't we/you first make 0ad ready for the newer version and then discuss about how to use the new possibilities?

There is a complicated task to add a new OpenGL support (btw one of reasons why we need the actual feedback statistics) without dropping not real old cards. Also we have a GLES "support", so probably we need to count it too.

[aeonios]

21 minutes ago, vladislavbelov said:

So it needs to test how it works and looks and then discuss with artists.

Something like that.

22 minutes ago, vladislavbelov said:

There is a complicated task to add a new OpenGL support (btw one of reasons why we need the actual feedback statistics) without dropping not real old cards. Also we have a GLES "support", so probably we need to count it too.

Not really. Adding support for updated openGL is indeed a monumentous task, but retaining support for old openGL just requires forking the renderer and keeping the old one. Allowing the renderer to be switched in-game might be a pain, but it'd be easier just to force it to be one of those "must restart to take effect" options. The new render could even be simpler since it doesn't require any of the old FFP/arb shader hacks that the existing renderer uses for compatibility.

[vladislavbelov]

9 minutes ago, aeonios said:

Allowing the renderer to be switched in-game might be a pain, but it'd be easier just to force it to be one of those "must restart to take effect" options.

Nobody was talking about it. I'm talking on a higher level, about a choice between multiple renderers (modern and legacy) and single renderer (that supports most of popular videocards), about the renderer architecture at all. With good architecture we can support multiple renderer very easily. But we don't have one (probably yet). But do we really need it? I.e. OpenGL 3.3 was released in 2010 (8 years ago) and is widely available these days, so why not drop OpenGL2 and go to OpenGL3.3 (why 3.3 and not 3.0, because it's nearest to 4.0 for old videocards).

10 minutes ago, aeonios said:

The new render could even be simpler since it doesn't require any of the old FFP/arb shader hacks that the existing renderer uses for compatibility.

There is a problem, that we will always have a modern things and legacy things. Probably not so hacky but still (i.e. GL3.3 vs GL4.0 for tessellation).

[aeonios]

8 minutes ago, vladislavbelov said:

Nobody was talking about it. I'm talking on a higher level, about a choice between multiple renderers (modern and legacy) and single renderer (that supports most of popular videocards), about the renderer architecture at all. With good architecture we can support multiple renderer very easily. But we don't have one (probably yet). But do we really need it? I.e. OpenGL 3.3 was released in 2010 (8 years ago) and is widely available these days, so why not drop OpenGL2 and go to OpenGL3.3 (why 3.3 and not 3.0, because it's nearest to 4.0 for old videocards).

Eh, the real reason for 3.3 is the features that it supports, like drawinstanced for animated models, RGB10A2 textures and so on. Yes 3.3 is ancient now, but I don't think the dev committee would be too keen on dropping support for old video cards or people who don't have real video cards. There was a discussion a year or two ago and that was the general consensus. I remember there being a poll and quite a few people were still using openGL2.x video cards or only supported 3.0.

12 minutes ago, vladislavbelov said:

There is a problem, that we will always have a modern things and legacy things. Probably not so hacky but still (i.e. GL3.3 vs GL4.0 for tessellation).

Do we really have a need for tessellation? AFAIK tessellation has horrible performance and isn't terribly practical for real games, and less so for 0ad where the models that could make use of it still have really low res textures with not-so-great materials. Also you'd need to be zoomed in really-really-really far for it to even be relevant. I'm not really aware of very many things that would actually be practical that require openGL4.x and there's no real point in pushing forward farther than there's an actual use-case for.

[vladislavbelov]

45 minutes ago, aeonios said:

Yes 3.3 is ancient now, but I don't think the dev committee would be too keen on dropping support for old video cards or people who don't have real video cards.

Yeah, go to 4.0+ is too fast for us, because we want to support usual players too.

46 minutes ago, aeonios said:

Do we really have a need for tessellation?

Not sure, it'd be useful for the terrain, but it's not necessary.

47 minutes ago, aeonios said:

tessellation has horrible performance and isn't terribly practical for real games

For old cards - yes, for new cards - it works. At least some AAA games/engines support the tessellation.

[aeonios]

12 minutes ago, vladislavbelov said:

Not sure, it'd be useful for the terrain, but it's not necessary.

There's actually a better solution to that- namely geomips. We could support higher resolution terrain for art but use lower res terrain for pathing and building construction so that the passability checks remain cheap, and use geomips for LOD. We could generate geomips statically a la http://reports-archive.adm.cs.cmu.edu/anon/1999/CMU-CS-99-105.pdf or we could use a dynamic method like ROAM. Neither of those options require tessellation, and both allow more artist control over what the high-res terrain looks like. You can get some really amazing effects by printing height textures to add details, things like sand dunes, rough rock surfaces, etc.

[vladislavbelov]

2 minutes ago, aeonios said:

There's actually a better solution to that- namely geomips. We could support higher resolution terrain for art but use lower res terrain for pathing and building construction so that the passability checks remain cheap, and use geomips for LOD. We could generate geomips statically a la http://reports-archive.adm.cs.cmu.edu/anon/1999/CMU-CS-99-105.pdf or we could use a dynamic method like ROAM. Neither of those options require tessellation, and both allow more artist control over what the high-res terrain looks like. You can get some really amazing effects by printing height textures to add details, things like sand dunes, rough rock surfaces, etc.

Yeah, and it works good, but it costs the bandwidth. But I like it, it's simple and pretty effective (as most of tree-based optimizations).

As a just possibility example we can pass the only one quad and the heightmap texture, the rest of work will be completed by GPU on the tessellation step (don't know how much it's expensive, but for something like GTX 1080 it should work good ).

[aeonios]

43 minutes ago, vladislavbelov said:

Yeah, and it works good, but it costs the bandwidth. But I like it, it's simple and pretty effective (as most of tree-based optimizations).

As a just possibility example we can pass the only one quad and the heightmap texture, the rest of work will be completed by GPU on the tessellation step (don't know how much it's expensive, but for something like GTX 1080 it should work good ).

Tessellation can't make art, it can only smooth existing polygons.

[vladislavbelov]

14 minutes ago, aeonios said:

Tessellation can't make art, it can only smooth existing polygons.

Geomipmaping or ROAM itself can't make art too, but it provides an easy possibility to do it. Tessellation not only smooth, but it can make sharper or whatever the original model was (yes, it's hard to make the same sharpness as for geomip, but it's possible for the geometry shader). It's expensive, yes, but it's possible to add some art things in the tessellation too. Just add a texture with a variable density. More complicated things are possible in the geometry shader. So GPU can do the same things, but with a different cost.

[elexis]