Fixing the skybox for maps

[Stan`]

@elexis @wowgetoffyourcellphone @wraitii @Itms
So I found a way to fix the skybox, it's actually pretty easy. What do you guys think ?
Also noticed a bug. Sky folder do not cache anything, so you can only dds files there.
 

Index: source/renderer/SkyManager.cpp
===================================================================
--- source/renderer/SkyManager.cpp	(revision 21115)
+++ source/renderer/SkyManager.cpp	(working copy)
@@ -251,8 +251,8 @@
 
 	// Distance to draw the faces at
 	const float D = 1500.0f; // distance from map center
-	const float H = 500.0f; // height of the ceiling
-	const float FH = -100.0f; // height of the "floor"
+	const float H = 1700.0f; // height of the ceiling
+	const float FH = -1000.0f; // height of the "floor"
 
 	CShaderProgramPtr shader;
 	CShaderTechniquePtr skytech;

 

 

[Sundiata]

Does this also remove the black bands you see on the horizon?

[Stan`]

13 minutes ago, Sundiata said:

Does this also remove the black bands you see on the horizon?

Do you have an example ?

Might be time to add new skyboxes as well http://www.custommapmakers.org/skyboxes.php (Careful those license are not all compatible)
Those are though : https://forum.unity.com/threads/18-free-skyboxes-unitypackage.27513/

[Sundiata]

 

This ticket discusses it:

https://trac.wildfiregames.com/ticket/3458

 

There is concern that extending the skybox below it's current height would look weird, but I don't really agree with that. Extending the skybox to come below the map would just make it seem like you're looking at the horizon... Either way, it would look better in 95% of the cases (yes I made that percentage up), and is far better option to solve the ugly black-band-screenshot issue, which is important for promotional stuff. The black band is not good...  

[Stan`]

I can lower the skybox.

I adjusted the height to new default height in atlas, but all old maps are actually lower.

[Lion.Kanzen]

Very impressive. congrats...

[wowgetoffyourcellphone]

Probably beyond the scope of this ticket, but I think it would be great to be able to pick a horizon texture as well regardless of the Skybox chosen. So, a mountainous horizon or oceanic horizon or whatever. 

[Skhorn]

Is there any tutorial on making a Skybox? 
 

Edited February 6, 2018 by Skhorn

[Stan`]

4 hours ago, Skhorn said:

Is there any tutorial on making a Skybox? 
 

You mean from existing files or from scratch ?

 

4 hours ago, wowgetoffyourcellphone said:

Probably beyond the scope of this ticket, but I think it would be great to be able to pick a horizon texture as well regardless of the Skybox chosen. So, a mountainous horizon or oceanic horizon or whatever. 

Yeah that would need two skyboxes one with alpha transparency and slightly smaller and the current on.

Doing it should be okay like you just basically have to call the function twice but I don't know how to handle the transparency.

 

[Skhorn]

34 minutes ago, stanislas69 said:

You mean from existing files or from scratch ?

Now that you said it, what about both?

[Stan`]

@Skhorn

From scratch I guess you could take panorama photos. And one picture of the sky above.

Else paint it yourself. For that you could either 

A) Paint everything.

B ) Make a gradient background and 

1) Handpaint clouds and horizon and sun 

2) Find cc0 cloud pictures and incrust them in the sky you just made same for horizon and sun.

From existing you'll have to create five power of two textures (e.g. 256x256) top back front left right from whatever pictures.

Put them in the folder named whatever you want it to be to find their location just look for a folder called cirrus

Note 1 : there is no bottom texture. It's black.

Note 2 : This could probably become a part of a a wiki page

Note 3 : Textures have to be DDS. Either DXT1 or DXT5 if you need alpha. The game doesn't convert them see first post.

Note 4 : You have to make sure the roof of the box somewhat transition without seams

 

[Sundiata]

Oh my, I feel so silly now... So the black bands are created by the black edges of the square map, that's pretending to be round?? Ooooh, of course, duh...

as @mimesot said:

Quote

 there is the equally beautiful circular map shape with its smooth transition into blackness, which you usually look upon from above. What if the transition wasn't into blackness but into transparency and the skybox had a much lower lower boundary. As the botton of the skybox is black, you wouldn't see any difference at the transition zone when looking down at a steep angle. At a flat angle the transition zone would look much slimmer (except the terrain was inclined steep upwards) and transition from terrain texture to sky texture. If the terrain at the map boundary was sloped downwards you would even get a hard horizon line. Is this possible? Does the engine support alpha values for terrain surfaces?

This problem really needs to be solved because it's a real thorn in the eye for screenshots... It's been brought up by many people for years.. 0AD looks gorgeous at low angles, and the low angle stuff puts 0AD in a different league than most RTS games. The black bands at the horizon just kind of ruin it... I don't want to have to photoshop my screenshots just to have something presentable, you know... It feels wrong... But black bands at the horizon are even more wrong... 

So the map should indeed transition into transparency, not blackness.

Who can do this? @elexis? 

[Stan`]

Dépends on what black bands you are referring too. If you refer to the horizon when having the camera at the ground level it's the skybox.

If you refer to a corner appearing on the screen to the skybox then yes that's because it's not transparent. Alpha transparency for this could have disastrous performance though. 

 

 

[Sundiata]

44 minutes ago, stanislas69 said:

Dépends on what black bands you are referring too. If you refer to the horizon when having the camera at the ground level it's the skybox.

If you refer to a corner appearing on the screen to the skybox then yes that's because it's not transparent. Alpha transparency for this could have disastrous performance though. 

It depends on both... There should never be any black band stretching across any horizon. I don't know anything about alpha transparency and performance, but I do know that those black bands (whether they're caused by the skybox or by the map, it's the same black), are very distracting from an aesthetic point of view, and ruin otherwise majestic screenshots.

This probably isn't an easy fix, or else it would have been fixed before, but it should be one of the (many) priorities. It would make for a much more professional looking game. Black band screenshots are terrible for marketing, is basically what I'm saying. 

[mimesot]

2 hours ago, stanislas69 said:

Alpha transparency for this could have disastrous performance though.

What makes transparency in this  context so much worse than the semi-transparence of water or clouds?

OK, if you alter the terrain surface to include alpha, (knowing this is not accurate)

• you add 8bit (one third) to each terrain pixel you have to render
• the engine has to ask each pixel whether it it is transparent or not and decide if it should bother with another pixel behind it
• in the few cases this happens, it has to render one more pixel and mix them.

This is already happening with the actor textures, but not with the terrain textures. Is the rendering of actors or terrain more intensive regarding rendering time? Anyway I would not call it disastrous if it was just the points I mentioned, so I assume the problem lies much deeper. Can somebody please satisfy my curiosity.

Something I noticed with the reeds (and probably some grass patches): Some seem to have oriented faces and backface culling appears to be enabled. This creates an odd effect. If you look at them from one side, they are present and from a different point of view they disappear.

There could be another approach to solving the black horizon problem. What if the map was actually much bigger  than the playable area. What if you created a large ring around the playable area, which still has just terrain texture but no entities. That wouldn't hurt your graphics card much. I guess the path-finder is the most processing-intensive part and if it does not cover the ring area it might be ok. Now create a beautiful landscape surrounding for the playable map and bend it downwards. It would act like earth curvature (sorry flat-earthers). This curvature would create a natural horizon and the actual borders of the map would not be seen except for very high camera positions. (Yes, you would have to curve the seas as well). The downside is, that you would loose the smooth transition into darkness.

Edited February 11, 2018 by mimesot

[wowgetoffyourcellphone]

It's partially the map but it's mostly the Skybox textures themselves. (the black bands)

Edited February 11, 2018 by wowgetoffyourcellphone

[aeonios]

I like this. It should also be possible to make custom horizons that are independent from the skybox, but that would require basically a 4 sided alpha-blended "collar" that would be drawn over an existing skybox horizon to add in mountains or whatever. You can't just replace the side panels because then they wouldn't properly match the existing sky.

[aeonios]

On 2/5/2018 at 5:31 PM, stanislas69 said:

I can lower the skybox.

I adjusted the height to new default height in atlas, but all old maps are actually lower.

I noticed that in this image the skybox looks severely stretched at the horizon. That's not really good. I've been thinking of using a dynamic sky, but that'd require dynamic clouds and particles are expensive due to draw calls. It can still be done but it'd be a lot of work producing an openGL3.x rendering pipeline to make it affordable.

[vladislavbelov]

4 minutes ago, aeonios said:

I noticed that in this image the skybox looks severely stretched at the horizon. That's not really good. I've been thinking of using a dynamic sky, but that'd require dynamic clouds and particles are expensive due to draw calls. It can still be done but it'd be a lot of work producing an openGL3.x rendering pipeline to make it affordable.

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

[aeonios]

1 minute ago, vladislavbelov said:

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

Well you could always draw the sky with one draw call. You can technically draw up to 800 particles at once with drawinstanced, but that's openGL3. Also lots of maps use the existing cloud particle effects anyway so it wouldn't be that much more expensive (if at all) as long as you didn't use a super sophisticated lighting system or use millions of clouds. It'd certainly be nice to have more variety in cloud textures and more particle effects for making random-ish cloud-looking blobs.

Dynamic sky wouldn't actually cost more unless you wanted the sun to move and create a dynamic day/night cycle. Even then you can redraw the 6 sides of the skybox separately for that and spread it out over several frames. Depending on how quickly the sun moves you would probably only need to re-render the sky once every couple of seconds and only update one side of the skybox per second.

[vladislavbelov]

22 minutes ago, aeonios said:

You can technically draw up to 800 particles at once with drawinstanced, but that's openGL3.

Why only 800? You can draw 1e3, 1e4 even 1e5 particles (if it's a simple quad), and it works good.

22 minutes ago, aeonios said:

Dynamic sky wouldn't actually cost more unless you wanted the sun to move and create a dynamic day/night cycle. Even then you can redraw the 6 sides of the skybox separately for that and spread it out over several frames. Depending on how quickly the sun moves you would probably only need to re-render the sky once every couple of seconds and only update one side of the skybox per second.

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.

[aeonios]

22 minutes ago, vladislavbelov said:

Why only 800? You can draw 1e3, 1e4 even 1e5 particles (if it's a simple quad), and it works good.

I think you can only pass 800 sets of instance attributes at a time. That's still 800 times fewer draw calls though.

23 minutes ago, vladislavbelov said:

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.

Ah I wasn't thinking of rendering the clouds into the skybox, but rather having them be particles in worldspace like the cloud particle effect used in maps. They could even cast shadows. In fact they should cast shadows! Drawing them that way would allow them to move and be visible in the camera as an object above the ground, which looks ridiculously cool.

 

[vladislavbelov]

37 minutes ago, aeonios said:

I think you can only pass 800 sets of instance attributes at a time. That's still 800 times fewer draw calls though.

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.

49 minutes ago, aeonios said:

Drawing them that way would allow them to move and be visible in the camera as an object above the ground, which looks ridiculously cool.

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.

[WhiteTreePaladin]

1 hour ago, aeonios said:

They could even cast shadows. In fact they should cast shadows!

That would be awesome!

Edited April 20, 2018 by WhiteTreePaladin

[aeonios]

1 hour ago, vladislavbelov said:

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.

Ah you're right, that's only if you pass vertex data in a uniform. If you use instanced arrays you can pass as much vertex data as will fit in GPU memory.

1 hour ago, vladislavbelov said:

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.

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.