Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Property Textures refer to all meshes #11977

Open
javagl opened this issue May 12, 2024 · 0 comments
Open

Property Textures refer to all meshes #11977

javagl opened this issue May 12, 2024 · 0 comments

Comments

@javagl
Copy link
Contributor

javagl commented May 12, 2024

When a property texture is applied to one mesh primitive, then CesiumJS applies it to all mesh primitives (and crashes if it cannot be applied).

The following is an archive that contains the relevant test data:

  • two tilesets, each referring to a GLB with two meshes
  • a sandcastle for testing
  • (The code that I quickly threw together for generating the GLBs, based on the 3d-tiles-tools - no warranty, just for reference)

property textures refer to all meshes.zip

The tileset in the hasTexCoords folder:

It contains a GLB with two meshes.
Both meshes contain one primitive.
Both primitives define TEXCOORD_0 attributes
Only the first primitive defines a property texture.

When rendering this with the given sandcastle, this is the result:

Cesium property texture refer to meshes 01 gif

It can be seen that it uses the property texture for both primitives, even though it is only assigned to one of them. (One could argue what the behavior should be in this case...)

The tileset in the noTexCoords folder:

This is equal to the one described above, except for the fact that the second primitive does not define a TEXCOORD_0 attribute. It does not need one, because it does not have a texture, and no property texture. Rendering this with the given sandcastle results in...

Cesium property texture refer to meshes 02

when just trying to load the data. This might nearly be "expected" at this point (considering the behavior in the first case), but is far more critical, because it causes a hard crash of CesiumJS by just loading a valid input file.


(There are some ... "similarities" ... of this to #11683. Maybe not even on a technical/implementation level, but on the level of the question of ~"What part of a model does metadata belong to?")

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants