Tiling stops at 9% and causing massive texture compression

Hello everyone people!

I’m making my first Cesium library and facing quite a strange problem. Here it is.

I have 2 very similar buildings models made in Blender3D. In fact, they are almost copies of each other with very little differences in geometry and UV mapping. Then I’m exporting both of that models to .obj using integrated exporter, while all materials are baked manually to .png’s (no plugins are used). I pack .mtl, .obj and .png to ZIP archive with no compression and trying to upload those archives to Cesium Ion in “3D Model (tile as 3D Tiles)” mode without compressions.
For the first model everything goes fine, it uploads and looks as nice as I expected it to be. BUT the second one looks really terrible with ugly-compressed texture. I tried almost everything you can imagine from Cesium noob to solve this issue - but nothing actually works. Nothing even tells me what kind of problem can cause such an issue: if I import those .obj back to my Blender or other 3d-software, both models look identically nice and smooth.
The only thing I noticed is that while uploading model-1, which looks fine, final tiling process goes all the way through from 0 to 100%, but when model-2 (the “bad” one) is uploading, progress bar stops at 9%, freezes for a little while and then SUDDENLY the model preview starts without any reporting that tiling is now complete.

Does anyone have any ideas what am I doing wrong? I’m attaching screenshots of both “fine” and “bad” models Cesium preview state, 9%-freeze screenshot and links to archives I uploaded if that would be useful.

“Fine” model: https://drive.google.com/file/d/1VjbKQTXacvp_3twB_Zuxgl1HGFkM61BM/view?usp=sharing
“Bad” overcompressed model: https://drive.google.com/file/d/1uO1jEaAv0HlxOxEOn6yYbdeeCh0ZI6MP/view?usp=sharing

Hello!

Welcome to the forum, and thanks for the detailed question, screenshots, and assets. All of those materials are a great help as we investigate an issue like this.

We’re seeing that same behavior on our end: the tiler seems to make a different decision on texture compression for one asset vs. the other. We’re looking into this, and I hope to have more details for you soon.

Thanks,
Matt

Thanks for your answer, Matt!

Before you find the reason why this kind of issue takes place, are there any methods to set up compression manually via web-based interface? Unfortunately I’m very limited in time solving this problem, yet very interested in using nothiтg but Cesium in my current project. So, if there’s some quick way to fix import on-the-fly with a little bit of code, I’ll be just fine with that.

Also, here’s one more sample of model being overcompressed on import, hope that might be useful too: Gorkogo___65.zip - Google Drive

Hi,

Configuring texture-compression settings isn’t available via ion’s web GUI, but it looks like that wouldn’t make a difference either way: I did some quick internal tests with those settings, and changing them doesn’t have an effect. Reducing maximumScreenSpaceError in CesiumJS also doesn’t fix the problem.

Here are a couple of workarounds you could try while we’re working on this:

  1. Instead of tiling the model, convert it to a glTF. See Cesium ion import settings below.

  1. Export the model as a COLLADA (.dae) file and create a KML file for it to use Cesium’s KML/COLLADA pipeline for 3D buildings. If you went this route, you would need to specify the building’s location on the globe in the KML file, and you wouldn’t be able to adjust it in the ion GUI using Adjust Tileset Location afterward.

Here are a couple of example KML files that demonstrate the KML/COLLADA option:

40_let_PB___2A.kml (509 Bytes)
Gorkogo___63.kml (505 Bytes)

To test them, export your model as a COLLADA (.dae) file with the same filename that is referenced in the body of the KML file (or revise the filename in the KML):

<Link>
	<href>Gorkogo___63.dae</href>
</Link>

Then upload the .dae, .kml, .mtl, and .png together into ion, and for What kind of data is this? select KML/COLLADA (tile as 3D Tiles):

If you let us know more about your use case, we may be able to provide more recommendations. How was this data generated and how will it be used?

Thanks,
Matt

Thanks a lot Matt!
I’ll try to test out all your suggestions on import tomorrow.

As for use cases I hope to get in the end of this project: this gonna be some kind of 3d-map of a small city in Russia (as you could notice from asset names). Assets are mostly generated manually by modeling and texturing buildings based on that city streets photographs, no photogrammetry data is used. I don’t really care of how accurate geodata would be, as well as how fine street navigation from point to point will work. For the first iteration, all of this is mostly a stylized dummy with a small part of real functionality, so correct buildings visualization is a priority at the moment.

Hello again!

So I conducted a series of tests, and found out that:

  1. Unfortunately every type of simple export/import I can provide with web-based version of Cesium Ion (.dae, .fbx, .obj) doesn’t display textures for my assets properly: overcompressing everywhere for each model except for that first one “40_let_PB___2A”;

  2. Importing “problematic” assets as glTF gives me a nice and clear texture, but I don’t actually see a way how can I place such assets in Stories or on a map. Are there any ways to do that via web interface?

  3. Importing “problematic” assets as KML/COLLADA also provides nice and smooth texturing, but setting buildings to their geoposition is a kind of nightmare: I have to search the referring building among OSM buildings library, copy and past lat./long. to KML file, copy and paste altitude, and somehow guess the Z axis rotation (“heading” as it’s called here) or place a dummy building over OSM one and adjust it’s heading first in order to copy and paste that value to KML. As far as I understand KML, there’s no way to place KML/COLLADA assets manually as we do with “tile as 3D Tiles” assets, right? Also, as I set heading value other than zero, the model starts crawling out of bounding box (shown on screenshot below). Is it O.K.?

And finally, will I be right if I say that in order to accompany my buildings by useful information such as name, address and so on while someone doing left mouse click on them, I have to use no other import type but KML/COLLADA and keep all those useful info in KML file?