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

Cesium3DTileStyle - alpha value not respected for loaded tiles #11300

Closed
TJPovey opened this issue May 22, 2023 · 4 comments · Fixed by #11399
Closed

Cesium3DTileStyle - alpha value not respected for loaded tiles #11300

TJPovey opened this issue May 22, 2023 · 4 comments · Fixed by #11399

Comments

@TJPovey
Copy link

TJPovey commented May 22, 2023

CesiumJS versions
Issue present in CesiumJS version 1.105 & 1.105.1. (No issues in cesiumjs version 1.92) Only tested in versions: 1.105, 1.105.1, 1.92

Expected behaviour:

When changing the style of a Cesium3DTileset using either of the following:

    tileset.style = new Cesium.Cesium3DTileStyle({
      color: 'rgba(255,255,255,0.5)'
    });
    tileset.style = new Cesium.Cesium3DTileStyle({
      color: 'color("white", 0.5)'
    });

I expect that all existing / newly loaded tiles to respect the assigned alpha value. Regardless of if the style has been added before or after the initial render of a Cesium3DTileset.

Actual behaviour
When changing the alpha value of a Cesium3DTileset, existing tiles use the old alpha value. Newly loaded tiles use the new alpha value.

The alpha value is respected if the style has been added prior to the model being added to the scene. If the alpha value is changed after this, the issue occurs:

Tile_Alpha_Issue

Sandcastle example:

By showing the tiles content volume, we can see that older tiles aren't affected by the alpha value change.

Sandcastle

Browser:
Tested on Chrome (Version 113.0.5672.127) & Edge (Version 113.0.1774.50)

Operating System:
Windows 10 Enterprise - version 21H2

@TJPovey
Copy link
Author

TJPovey commented May 22, 2023

More easily seen when showing content volumes:
Tile_Alpha_Issue_2

@TJPovey
Copy link
Author

TJPovey commented May 22, 2023

Ok, I've tested on all versions between 1.92 and 1.105.1, it looks like the bug was introduced in version 1.97. These were the major changes in this version.
Maybe texture caching is the culprit?

@j9liu
Copy link
Contributor

j9liu commented May 22, 2023

The culprit is this block of code:

/**
 * @private
 */
Model.prototype.applyColorAndShow = function (style) {
  const previousColor = this._color;
  const hasColorStyle = defined(style) && defined(style.color);
  const hasShowStyle = defined(style) && defined(style.show);

  this._color = hasColorStyle
    ? style.color.evaluateColor(undefined, this._color)
    : Color.clone(Color.WHITE, this._color);
  this._show = hasShowStyle ? style.show.evaluate(undefined) : true;

  if (isColorAlphaDirty(previousColor, this._color)) {
    this.resetDrawCommands();
  }
};

previousColor is storing this._color, and when this._color is later being changed by the style, this also changes previousColor. The correct solution would be to use a scratch Color variable for previousColor. Then, use Color.clone to copy the color into previousColor, before potentially changing it via the style.

@TJPovey
Copy link
Author

TJPovey commented May 22, 2023

perfect thanks @j9liu

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

Successfully merging a pull request may close this issue.

2 participants