I have been using cubemaps with default compression for a custom skybox material without any issues on PC (even with mobile and high-end mobile preview rendering modes enabled), but, as soon as I package it for Android, I get a bright white seam along some of the cube face edges. It doesn’t matter if I package the build for ES2 or ES31 and it happens without or without Vulkan enabled.
This seam is present regardless of what texture filtering mode I use, whether or not I enable mipmaps, whether or not I’m using sRGB (with default compression, I use sRGB in the texture and material). Enabling clamping or wrapping does not help.
If I switch the texture and material over to linear color (“HDR” or “HDR compressed”), the cubemap renders perfectly…but I see performance degradation if I maintain the desired resolution (512) and the memory footprint of the texture increases by quite a bit. As I haven’t been able to capture the device on a profiler, I haven’t been able to verify which texture compression format is actually being used with the present settings.
I’ve been packaging the build for ATSC compression, but I’m assuming the linear / floating point formats are being packaged as uncompressed textures (can’t find any details about this in the UE4 docs).
Can you provide me with some screenshots and the cubemap texture file in question so I can test this on my end as well?
Could you also provide me with the device you are testing?
I will also need the packaging settings you are using so I can replicate this issue on my end. If you are developing a project that is aimed at using one of these devices, it is highly recommended that you perform extensive performance and compatibility testing to ensure that the device delivers your project in the manner you intended.
I’m waiting on approval for whether or not I can share any assets with you.
Our game is for Daydream VR and I’m testing on Google Pixel. I’m packaging Android (ATSC) for arm64 with only OpenGLES 3.1 and Vulkan enabled, minimum and target SDK is set to 24 since we don’t have to worry about targeting older hardware. I’ve verified that 3.1 specific features in my materials are indeed working as expected within our compiled version of the engine on device (i.e. using feature switches with 3.1-specific features like fetching a specific mip-level within a texture cube sampler and passing data through customized uv values beyond the 3 allowed by ES2…my goal is to shift more operations of my custom materials into the vertex shader via the additional customized UVs hoping to get some performance gains).
Mobile HDR is disabled, lightmap directionality is disabled, force low quality reflections is on.
They just mentioned this issue in the latest Unreal Engine Twitch Livestream, mobile will reduce an image’s quality, to avoid this you need to enable “Full Precision” in your material under your mobile section.
I enabled “Full Precision” as a test, but the rendering remained the same as I expected. My assumption remains that this is an issue with how Unreal is converting the texture from HDR latlong map to either compressed or uncompressed cubemap texture. Note that if I enable mipmapping and modify my material to cycle through the miplevels, I can see the glowing edge texels increase in size…it really looks like an error in the texture generated for the device, not a material issue.
Again, the errant seam doesn’t appear if the texture is set to use HDR or HDR compressed texture compression…only if I use the default compression setting. The only thing that changes in the material is whether or not the texture cube sampler uses “linear color” (for the HDR/HDR compressed) or “color” (for default compressed sRGB enabled texture).
Could you provide me with a screenshot and/or asset to test so I can get this issue to appear on my end?
Possibly some steps to follow so I can see the artifact?
Cubemaps should not need mimaps as they are used for the ambient lighting for the reflection environment. You can get an idea of the default cubemap settings when using a SceneCapture Cube and creating a static texture from the cube render target.
I’ve been told I can’t share assets from our game here, so I’ll have to throw together a test asset and cubemap fetching material when I get some time, but I figure all you would have to do is take any cubemap and set the following: default compression (which would be DXT1 or 5 on PC), sRGB enabled (as all of the mobile docs recommend for mobile), no mipmapping. You won’t see the problem on PC…it only shows up on device (packaged Android ATSC). You would NOT see the problem if you set it to use a linear format (HDR or HDR compressed)…the only reason I was trying to avoid the latter is the file size is much larger (I’m assuming these are actually packaged as an uncompressed format on Android) and I’m pretty sure performance dropped when I kept the 512 resolution.
I was only using mipmaps to test something…in general I do NOT plan to have mipmaps enabled for my custom skybox material (however, do note that I have used mipmapped cubemaps with custom shaders on many other projects for other engines, so I have reasons why I may at some point want to use my own…which I figure I can still supply via dds format if I really need it).
Note that I’m currently working around the issue by supplying lower res maps (256 resolution) using HDR Compressed…I had to manually apply blur before down-rezzing the source art to keep the images from appearing too pixelated at that resolution. But a couple of the skyboxes have some high detail features that really need the additional resolution…
So just to clarify, your issue is the memory that is being taken up by the Cubemaps and the artifact you are reporting when using the default compression?
I did some testing on my end in a new blank project and found some interesting results. So, the default texture compression and settings that Unreal chooses when you create a Static Cubemap Texture is optimized for the PC platforms.
This is why it compresses using the HDR (RGB, no sRGB), unchecks sRGB, and has NoMipmaps. I took a look at the resource size after messing around with some of the compression settings, and found that if you check the ‘Compress Without Alpha’, your resource size is cut in half. This is also when using the the Default (DXT1/5, BC1/3 on DX11).
Hopefully this provided a little bit of insight into this issue, but let me know if you have further questions. I still need a way to reproduce the artifact you are reporting so I can enter an bug report if necessary.
For clarity, the artifact I’m talking about shows up with Default (DXT1/5) compression…but the artifact (approximately a texel-wide seam around some cube facings) only shows up on device (Android ATSC…which I assume means that the texture is actually compressed using ATSC). You can’t see the issue on PC regardless of whether or not you are viewing it with one of the mobile preview rendering modes.
The memory/performance issue is only suspected, the assumption being that HDR/HDR Compressed do not actually apply any compression when targeting Android. I’m not sure what compression type is actually being packaged for device when using this setting because I don’t know how to view the asset as packaged.
And compress without alpha was already enabled on all of my cubemaps.
OK, this is a capture from device. I assigned a really small all black cubemap, sRGB enabled, no mipmap cube using the above mentioned “default” settings. Because the resolution is only 16, the artifact is much more visible as the texels cover a bit more screen real estate. This is looking up one corner of a hemisphere using a simple variant of my sky material.
Additionally, I’ve attached a zip file containing uassets for the texture, the base sky material, a material instance that references the base material, and the geo I use. Note that I am using translucency so the sky renders after all of the opaque geo.
I appreciate your patience while I tested to confirm this issue. I have gone ahead and entered a bug, which you can track by following the link I have provided below.
just FYI; I just ran into this site as I have also noticed that the cooker does not compress “HDR Compressed” textures even though ASTC is selected and it’s perfectly capable of doing so. It’s a big deal for mobile development as it’s a pretty big memory footprint “on disk” and on “memory”. I’m running 4.15 and this issue persists.
So the end result of this post was linked to an artifact regarding ASTC compressed HDR cubemaps which has been fixed. Your issue sounds like an issue with the textures themselves being compressed correctly. Please create a new post and reply to this comment with a link to the post.
Be sure in your new post to provide me with steps to follow in order to reproduce it on a device on my end. Screenshots and clear instructions will benefit the both of us when getting it entered as a bug.
