Hi everyone, I want to make a space sky, i. e. you can see background textures into all six directions. It seems that there are two major methods, that I want to call “Spacebox” and “Spacesphere”. I have several questions to both of them.
Method Spacesphere
Is described in the wiki tutorial “Skybox from DDS cubemap”. I am wondering if this method may be inefficient.
Importing the DDS file to UE takes a long time, e. g. about 20 minutes for a 6 x 4096x4096 dds texture file. Is that normal, how can I make it faster?
When opening the texture after importing it, it looks like a single rectangular texture with very distorted poles. Does that mean that these poles use a lot of memory although they cover only a small area on the skysphere? And do they use this much memory after mapped to the sphere, too?
The surrounding sphere probably consists of hundreds or thousands of polygons (spaceboxes only use six), and the dds file has to be mapped to these polygons. Isn’t this all very expensive, especially when compared to the other method (see below)?
Method Spacebox
I created a cube in my favourite 3D modelling tool and unwrapped it to a 3x2 grid, see:
[ATTACH=JSON]{“data-align”:“none”,“data-size”:“full”,“data-tempid”:“temp_125063_1513279656813_563”,“title”:“cubemap_base.jpg”}[/ATTACH]
When I now export my skybox as six single images and merge them to one big 12288x8192 image (i. e. a 3x2 grid each with size 4096x4096), this seems to be a perfect solution. (The rest of the steps to be done is analogous to the other method.)
Nevertheless, there are some issues:
When opening the texture, UE says “Attempting to import 12,288 x 8,192 texture, proceed? Largest supported texture size: 8,192 x 8,192”. Though, it seems to work. So, is this a problem?
The texture is not quadratic and its lengths are not both powers of 2. Does this yield in a waste of resources, e. g. by automatically padding the texture?
And, of course, my most important question is: Which of these two methods should be prefered, and why? The spacebox method seems to be easier and save resources, but the only satisfying tutorial in the UE wiki prefers the spacesphere method.
Thanks a lot for reading my concerns, hoping for answers,
There’s not much of a difference for most usage scenarios. 20 minute import doesn’t matter since you only do that once.Performance wise they basically don’t have any differences (Sphere rendering performance is relatively the same due to shaders). The Sky Sphere seems to get more love and by UE4 default stuff - see this day/night tutorial which relies on the default sky sphere:
But in the end - if you believe in the box then use the box. Nothing wrong with that.
Either method will work. The runtime cost shouldn’t be too much of a difference, because the skysphere mesh doesn’t have to be that dense in geometry if you’re doing just a static skybox image and the constant cost of that geo on the screen would be negligible. I’d compare total memory costs though, as those high-res images are pretty costly for memory purposes, even more so depending on if you stick with DXT1 compression or not. As for the padding, that’s not really needed because in most cases, you don’t want your skybox to stream or mip.
20 minutes is indeed ok for importing, but nearly all of this time is used for MipGen settings. Importing with NoMipmaps would it make much faster. And perhaps later, I want to be able to import 8K textures, that would be annoying long.
If there is no real disadvantage for the skybox method, I’d prefer it because there is no such import delay. Nevertheless, good to know that there is only negligible difference in consumption of resources. I did not yet understand the issue with compression settings, as the tutorial suggests just to use UserInterface2D.
I assume that the error message when opening the texture within the skybox method is not significant.
No, there’s only one link, and it works. But the image is not always loaded on my screen (?) … strange.
Avoiding a spacemap at all is not a point in my case, as there has to be a background. Anyway, any scene does need a background, doesn’t it? Though, I try to take your hint into account.
Well, once again: Is this message a problem? I am asking because the UE documentation Textures/SupportAndSettings says that only up to 8k is possible. So is my texture in fact scaled down? And if yes, is the only solution (when insisting on method skybox) that you have to use six single images and six different materials, or is there perhaps a clever trick to avoid such a tortuous overhead?
And finally, one more question (that is a little bit Off Topic): Are six 4k textures sufficient for today’s computers, or should it be 8k instead? Think of a 4k monitor whose screen shows only a part of one face of the skybox …
Most details in a skybox are not sharp, clouds, far off mountains behind some atmospheric fog, etc. Not sure if you really need a 1:1 pixel ratio at all times, but if you are going for overkill, lets assume 1:1 is your target.
A 4k display is showing 8,294,400 pixels, a 4096x4096 texture is 16,777,216, a 8k texture 8192x8192, 67,108,864. 6x 4k textures would be 100,663,296 pixels.
At the default 90 fov, you can view 90 degrees horizontally. If you are just looking at a skybox, that means you’ll be looking at ~1/12th of the total sphere at any given time. 100,663,296 / 12 = 8,388,608 which is basically a 1:1 pixel ratio to a 4k display.
You probably could get away with no texture on the bottom in many situations, depending on your scene.
Yes, the calculations are correct: With the default field of view of 90 degree a 4k texture yields to a 1:1 pixel ratio on a 4k display. Thanks for that effort!
I assume that a 1:1 ratio is sufficient, but I don’t know for sure because a higher texture resolution might still lead to better results due to sampling/aliasing (?). If anyone has experience with that issue, his knowledge is welcome here. For the time being, I stick to 4k textures.
I am still interested in opinions to the above mentioned error message.