Normalized result is not a number from i3dm

3D Tiles
1

Hi,

I’m trying to convert instanced geometry to the i3dm format in our 3D Tiles export from Remoscape to Cesium. I’m starting with regular non-quantized positions and rotations.

In ION I’m getting a “normalized result is not a number” error, probably from the normalize operation performed on the calculated forward vector. I have tried calculating the forward vector at creation of the i3dm file to see if any zero length vector is created, but it looks okay.

The 3d-tiles-validator says nothing about this, but maybe it just stops at complaining about my padded URI to fulfill the alignment requirement - more about that in another topic.

I’m attaching my small tileset here, can anyone see what’s wrong with the i3dm files?
Brazil_3D_Tiles.zip (6.3 MB)

/Andreas

2

Hi again,

I had misunderstood the documentation. After putting all the positions first, then all the normals, etc. the error disappeared. The 3d-tiles-validator doesn’t give any errors or warnings now, only information about that “URI is used in GLB container” for my images, which seems to work fine otherwise in Cesium.

But I’m still getting “A 3D tile failed to load” and “Error: Invalid tile content.” from my i3dm files. Any idea why?

Here is the updated tileset:
Brazil_3D_Tiles.zip (4.6 MB)

/Andreas

3

If the remaining issue for you is only the “Error: Invalid tile content” message: The file /0/5.b3dm has 0 bytes - that alone would cause this error to appear at least once.

But… can you actually render the tileset without any crashes? I started investigating this a bit, but admittedly, was stumped by how hard it crashes when trying to load that in a local Sandcastle: For me, it complains about a wrong texture size, related to losing the GL context, and then completely crashes the browser tab - going so far that after 1 or 2 attempts, I have to restart the whole browser.

So there is something odd with the data, but I still don’t know what exactly it is. The validator mentions unsupported image features a few times, as in

    {
      "type": "CONTENT_VALIDATION_WARNING",
      "path": "0/5_kapok4_0_0.i3dm",
      "message": "0/5_kapok4_0_0.i3dm caused validation warnings",
      "severity": "WARNING",
      "causes": [
        {
          "type": "CONTENT_VALIDATION_WARNING",
          "path": "0/5_kapok4_0_0.i3dm",
          "message": "0/5_kapok4_0_0.i3dm caused validation warnings",
          "severity": "WARNING",
          "causes": [
            {
              "type": "CONTENT_VALIDATION_WARNING",
              "path": "0/5_kapok4_0_0.i3dm",
              "message": "Content 0/5_kapok4_0_0.i3dm caused validation warnings",
              "severity": "WARNING",
              "causes": [
                {
                  "type": "CONTENT_VALIDATION_INFO",
                  "path": "/images/0/uri",
                  "message": "URI is used in GLB container.",
                  "severity": "INFO"
                },
                {
                  "type": "CONTENT_VALIDATION_INFO",
                  "path": "/images/1/uri",
                  "message": "URI is used in GLB container.",
                  "severity": "INFO"
                },
                {
                  "type": "CONTENT_VALIDATION_WARNING",
                  "path": "/images/1",
                  "message": "Image contains unsupported features like non-default colorspace information, non-square pixels, or animation.",
                  "severity": "WARNING"
                }
              ]
            }
          ]
        }
      ]
    },

This message is actually generated by the glTF validator, which is used for validating the GLB data in the I3DM data, and I’ll have to zoom in to what this refers to. But it might be related to the crashes that I’ve been observing here…

I first thought that it may be related to some strange PNG file that appeared in the first data set…

Cesium Strange PNG

but that does not seem to be referred to by any file, and does not seem to appear in the second data set, so that can’t be it…

4

Hi Marco,

Thanks you for the detailed answer and for investigating my strange data. :slight_smile:

I didn’t get the hard crash as you did, but I also didn’t realize 5.b3dm was empty actually. Its source tile only contained instanced geometry so the conversion produced only i3dm tiles and apparently an empty b3dm file. I am now automatically removing this empty “parent” tile from disk and from the tileset at conversion, and the problem disappeared! Nice when it’s that easy sometimes.

I tracked down the “unsupported features” warning to a color profile in a PNG, when removing the color profile the warning disappeared.

So now I can see my instanced geometry, next problem is to get the normals right, and optimizing by using quantized positions and normals.

Thanks again!
/Andreas

5

I’m still a bit curious about the crashes that I observed. I mean … whatever is wrong, it should never crash so hard. Although it’s a bit of a stretch, I wondered whether the color profile in the PNG file could somehow have caused this. Had these been (some of) the PNG files in the root directory, or ones that have been embedded in B3DM/GLB data?

6

They are still in the root directory, I haven’t managed to embed images properly yet. However, these PNGs in particular will stay separate and referred to by an URI, since they are reused many times. And it all works fine now, so I assume it was due to the empty .b3dm.