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

Extent setters in Cesium3DTileStyle #5412

Merged
merged 26 commits into from
Jul 25, 2017

Conversation

SunBlack
Copy link

@SunBlack SunBlack commented Jun 2, 2017

See discussion here

@SunBlack
Copy link
Author

No idea why tests are failing here, during tests in #5308 seems to pass currently. On my local machine tests currently stucks on 3d-tiles and my branch.

@pjcozzi
Copy link
Contributor

pjcozzi commented Jun 12, 2017

I saw the forum discussion, and the approach is OK with me. Thanks for the update, @SunBlack!

@mramato mramato changed the base branch from 3d-tiles to master June 19, 2017 17:11
@@ -209,7 +209,7 @@ define([
},

/**
* Gets or sets the {@link StyleExpression} object used to evaluate the style's <code>show</code> property.
* Gets or sets the {@link StyleExpression} object used to evaluate the style's <code>show</code> property. Alternative an object defining a show style can be used.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add examples of each of these cases to the doc.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also tweak the new description a bit: Alternatively a boolean, string, or object defining a show style can be used.

} else {
this._show = undefined;
return;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe it's not necessary to split up these two last cases. This would also allow someone to define their own evaluator like the example in the documentation.

if (typeof value === 'boolean') {
    this._show = new Expression(String(value));
} else if (typeof value === 'string') {
    this._show = new Expression(value);
} else if (defined(value.conditions)) {
    this._show = new ConditionsExpression(value);
} else {
    this._show = value;
}

@@ -246,13 +246,24 @@ define([
return this._show;
},
set : function(value) {
if (typeof value === 'boolean') {
this._show = new Expression(String(value));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that defines are part of the styling language also pass those through to the expressions.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should be a separate PR, because we don't have a getter/setter for defines now. So I don't know if you really want old defines are still evaluated. And in case you allow getter and setter for defines you have to think other things, like if you need to recreate all expressions.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it hurts to pass the defines in even if they are no longer relevant to the new style, at the very least it does cut down on the code duplication. But if you would prefer that to be a different PR that is also ok with me.

this._showShaderFunctionReady = false;
this._show = value;
}
},
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The setup function can now be simplified be calling these setters within.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Depends on discussion above ;)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I having some trouble with a test, if I use setter in setup. In case I use new setter to initialize all variables following test fail: return undefined shader functions when the style is empty. But I think existing tests are wrong in this case. If e.g. no color is defined DEFAULT_JSON_COLOR_EXPRESSION will be used. So I don't understand why the test is expecting an undefined result instead of a shader generated from value DEFAULT_JSON_COLOR_EXPRESSION.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For shader styling undefined is returned because otherwise DEFAULT_JSON_COLOR_EXPRESSION would cause all points to be white.

To fix this

that._colorShaderFunctionReady = !defined(styleJson.color);
that._showShaderFunctionReady = !defined(styleJson.show);
that._pointSizeShaderFunctionReady = !defined(styleJson.pointSize);

need to go below the setters in setup.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It works, but I don't like code design here, because it is not really clear why one time getColorShaderFunction returns undefined and other times a valid shader, if both times value of color is equal to DEFAULT_JSON_COLOR_EXPRESSION.

So I would prefer: In case no color expression is defined color returns undefined instead of DEFAULT_JSON_COLOR_EXPRESSION. In Cesium3DTileBatchTable.prototype.applyStyle change code from:

            var color = style.color.evaluateColor(frameState, feature, scratchColor);
            var show = style.show.evaluate(frameState, feature);

to

            var color = defined(style.color) ? style.color.evaluateColor(frameState, feature, scratchColor) : 'white';
            var show = defined(style.show) ? style.show.evaluate(frameState, feature) : true;

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That approach seems good to me too.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Behavior changed. I should be finished with the PR (hopefully all tests are passing on travis ;) )

@SunBlack
Copy link
Author

No idea why the other tests are failing.

@lilleyse
Copy link
Contributor

@SunBlack is this ready? The new changes look good to me.

@SunBlack
Copy link
Author

Yes, i'm finished :)

@lilleyse
Copy link
Contributor

Actually one small fix is needed in Cesium3DTilesInspectorViewModel:

this._style.color.evaluateColor(frameState, currentFeature, scratchColor); will need to check if color is defined first.

@SunBlack
Copy link
Author

Maybe we should add a note to Readme about this changes. Any suggestion for a good short description?

@lilleyse
Copy link
Contributor

A somewhat long description, but it works:

  • Added ability to set a style's color, show, or pointSize with a string or object literal. show may also take a boolean and pointSize may take a number.

@SunBlack
Copy link
Author

Should we mention that Cesium3DTileStyle don't is initialized anymore with default values, because this is a breaking change?

@lilleyse
Copy link
Contributor

Yes also mention that in the breaking changes.

@pjcozzi would it be fine for this change to not go through deprecation? The change is that color, show, and pointSize properties of Cesium3DTileStyle can now be undefined rather than being set to default values.

@pjcozzi
Copy link
Contributor

pjcozzi commented Jul 18, 2017

Maybe, I'll try to look at this soon.

@SunBlack
Copy link
Author

In general I think it is okay to have here a breaking change, because 3d tiles are new to stable branch and I'm not sure if anyone is really using getter here. If not: We could add a deprecated warning to getter for release in 2 weeks and merge this MR direct after release. But I'm not sure if it is a good idea, because getter will be called at each tile and I'm not sure how I can filter it so message occurs only if it is really a deprecating case.

@pjcozzi
Copy link
Contributor

pjcozzi commented Jul 21, 2017

Yes, this does not need to go through deprecation.

Please add a bit more doc to the set/get that explains that the get function doesn't always return exactly what is provided to the set function since it is converted to the native expression.

@lilleyse please merge when ready; I will not have the bandwidth to look at this again.

@lilleyse
Copy link
Contributor

Thanks @SunBlack!

@lilleyse lilleyse merged commit fbb1dd7 into CesiumGS:master Jul 25, 2017
@SunBlack SunBlack deleted the Extent_Cesium3DTileStyle_setters branch July 25, 2017 11:26
@SunBlack
Copy link
Author

Tweaked doc is not fully correct, because if you set a custom object getter will return this custom object instead of an Expression, but i think it is okay ;)

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

Successfully merging this pull request may close these issues.

3 participants