Property Textures refer to all meshes
- Dominant language
- JavaScript
- Stars
- 15.7k
- Forks
- 3.9k
- Avg merge
- 4d 6h
- Merged PRs (30d)
- 34
Description
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](https://github.com/CesiumGS/cesium/files/15286563/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:

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...

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 https://github.com/CesiumGS/cesium/issues/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?")
Contributor guide
Research direction
Start with the supplied sandcastle and the hasTexCoords/noTexCoords tilesets in the archive, then trace how CesiumJS applies property textures across the two mesh primitives. Done means a property texture assigned to one primitive is not applied to unrelated primitives, and the valid noTexCoords case no longer crashes.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- computer-graphics, web-dev
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100