CesiumGS / CesiumGS/cesium

Property Textures refer to all meshes

Open
#11,977 0 comments 0 reactions 0 assignees View on GitHub
category - model/gltf type - bug
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:

![Cesium property texture refer to meshes 01 gif](https://github.com/CesiumGS/cesium/assets/5597569/b9af92e9-3fc9-4df4-b270-14a79283884f)

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](https://github.com/CesiumGS/cesium/assets/5597569/8b31d397-1ae7-4147-bc4f-03ad566dac31)

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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.