Does the new reality tiler use ETC1S, UASTC, or both, for compressing textures (can we specify)?
Looks like only gltf/objs inputs are supported at the moment - is there a plan to include fbx as input?
Thanks!
1 Like
Just to confirm you talking about the tiler command line and not the one run through the Cesium ion platform online, correct?
Currently FBX is only supported through Cesium ion online. However we are considering adding support for additional formats to the command line version.
For both command line and Cesium ion tilers the texture compression is using ETC1S. There is currently no way to specify this, however it may be added in the future. Are you able to provide any more details about your use case for specifying the texture compression? That will help inform our future roadmap.
And just in case you were not aware, here is a link to the documentation for the new reality tiler command line.
Hi @mdc9001 , sorry for the late response.
I’m personally more concerned about the on-premise command line tool.
Sure, when taking a look at the examples of the reality tiler vs the old tiler:
We can see the textures are a little blurred when we get close to a surface:
Tiles 1.1:
Tiles 1.0:
It’s not very noticeable, and 90% of the time this is fine, But we have some photogrammetry models where textures need to be more crisp to be able to read signage, and we were becoming accustomed to little texture degradation from the source files when converting to cesium tiles using the 1.0 tiler.
Reading the KTX 2.0 spec, it looks like using both ETC1S & UASTC compressions could be of benefit for highly detailed models:
file/gpu memory size of the above:
quote from KTX Artist Guide:
The lamp on the far right is compressed only with ETC1S which causes obvious block compression artifacts. This may be acceptable if file and GPU sizes are more important than quality. This demonstrates the importance of fine-tuning compression codecs and settings; as the UASTC+ETC1S example shows these artifacts can be nearly eliminated by implementing more refined compression settings, as demonstrated below.
For the high-quality UASTC+ETC1S version, the textures were compressed from PNG source files using toktx via a combination of compression settings that favored high quality. UASTC was used for packed textures (ORM, Normal, etc.) and ETC1S for Base Color and Emissive textures, however exceptions were made based on analyzing results… the
glass_basecolor-alphaandglass_emissivetextures were changed from ETC1S to UASTC since these were prominently displayed on the model and contained a lot of color variation.
So from the above it doesn’t seem trivial to introduce UASTC compression, mainly because of the last line:
exceptions were made based on analyzing results… the
glass_basecolor-alphaandglass_emissivetextures were changed from ETC1S to UASTC since these were prominently displayed on the model and contained a lot of color variation.
It would be great if texture compression types could be included as an additional flag (experimental?) - but I appreciate it’s not trivial!
That’s fine - we’ve updated our pipeline to convert to glb prior to running through the tiler, although fbx input would be useful to align with the old tiler for testing both tilers.
Also - in the documentation it states DRACO is the default compression method. Is there a reason for this over using MESHOPT? It seems like MESHOPT would be superior in terms of runtime streaming, and using gzip would also help reach the same file size as draco compression. Is there something I’m missing here? Is the meshopt decoder not in a webworker in cesiumjs or something?
Thanks for your time,
Tom
Thank you for that additional information.
Draco was selected over Meshopt because it had better performance for streaming. Our team did some testing and found that using Draco resulted in slightly quicker loading in environments where there was limited bandwidth. Meshopt did slightly better in performance when loading straight from disk.
That’s great thanks for the info - are you aware if the meshopt decoder is using a webworker - and if not will we expect to see it surpass draco performance when it is implemented? I found the following line in this pdf (albeit from 2022):
Experimental meshopt decoder doesn’t use Web Workers yet - expecting to see even better decode performance
Also - do you have any comment on the KTX 2.0 compression methods?
Thanks
A few notes regarding the KTX compression:
There is an implementation note in the extension specification:
As a general rule, textures with color data should use ETC1S while textures with non-color data (such as roughness-metallic or normal maps) should use UASTC.
Very roughly speaking: The ETC1S compression may more easily introduce block artifacts, whereas UASTC is nearly lossless in terms of visual differences. But this comes at a price: UASTC textures are noticably larger, both in terms of file size as well as GPU memory size.
The KTX Artist Guide points out some exceptions to that rule, and their justification:
For the high-quality UASTC+ETC1S version, the textures were compressed […] via a combination of compression settings that favored high quality. UASTC was used for packed textures (ORM, Normal, etc.) and ETC1S for Base Color and Emissive textures, however exceptions were made based on analyzing results… the
glass_basecolor-alphaandglass_emissivetextures were changed from ETC1S to UASTC since these were prominently displayed on the model and contained a lot of color variation.
It then lists the exact options that have been used for the middle (high-quality, UASTC+ETC1S) option. And you can see that different options have been used for the different texture types, carefully tweaked for this particular model.
Much of this ‘type-specific tweaking’ may not be sooo relevant for the usual 3D Tiles output: 3D Tiles usually only has a ‘base color’ texture (no metallic-roughness, no occlusion, no transmissive, and no emissive textures). Still, one could examine the effects of different compression types and settings. As an example, I created a comparison of different compression options for the texture of the “Duck” glTF Sample Asset:
DuckCompare-2023-12-05.zip (279.0 KB)
You can drag-and-drop this into https://gltf.report/, and it will look like this:
You can see the different file sizes, and when you select the ‘Textures’ tab, you can also inspect the GPU memory (“VRAM”) sizes (here, for one ETC1S and one UASTC texture):
At this level, there are no visual differences, but you can zoom in to see the artifacts. For example, this is an animated GIF with a comparison of ETC1S with qualityLevel=0 and with qualityLevel=255, when zooming in reeeeally closely:
One can see that the block artifacts are much less prominent in for qualityLevel=255 (but still there).
What does this mean for the ion tiling pipeline? That depends. You specifically asked for the compression type, and mentioned…
It would be great if texture compression types could be included as an additional flag (experimental?) - but I appreciate it’s not trivial!
It could be relatively easy “just to offer some options for the compression type” (e.g. PNG, KTX+ETC1S, and KTX+UASTC). But there are many configuration options for each type, and the interdependencies are complex - in terms of compression/decompression speed, file size, and visual quality. The Khronos Group recently released an online tool for interactively trying out different compression options at glTF Compressor for KTX , and one can play with all the different settings there. (Select the “Texture Compressor” tab at the right)
For now, Cesium ion should provide sensible defaults for the type of textures that usually appear in 3D Tiles. And they usually contain only the ‘base color’ texture, so ETC1S (with a default qualityLevel) should be a reasonable default.
Options for offering more fine-grained control over the compression types and their options are already investigated, and may be offered at some point. For example, one could consider a ‘High Quality ETC1S’ setting that sets the qualityLevel=255. But care has to be taken to not overwhelm the user with fine-grained options, without conveying a clear idea about their effect on the end result.
I apologise for the late reply, I’ve been away and I forgot to respond.
Thankyou for the very detailed response, I appreciate it.
I completely agree with the above.
Understandable - and although I agree with this when using Cesium ION SAAS, I would say there is more of a use case for implementing flags for additional options and finer control when using the on-premise pipeline executables.