-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
Extent setters in Cesium3DTileStyle #5412
Conversation
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. |
I saw the forum discussion, and the approach is OK with me. Thanks for the update, @SunBlack! |
Source/Scene/Cesium3DTileStyle.js
Outdated
@@ -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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
Source/Scene/Cesium3DTileStyle.js
Outdated
} else { | ||
this._show = undefined; | ||
return; | ||
} |
There was a problem hiding this comment.
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;
}
Source/Scene/Cesium3DTileStyle.js
Outdated
@@ -246,13 +246,24 @@ define([ | |||
return this._show; | |||
}, | |||
set : function(value) { | |||
if (typeof value === 'boolean') { | |||
this._show = new Expression(String(value)); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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; | ||
} | ||
}, |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Depends on discussion above ;)
There was a problem hiding this comment.
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
.
There was a problem hiding this comment.
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
.
There was a problem hiding this comment.
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;
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 ;) )
…um3DTileStyle_setters
…_setters' into Extent_Cesium3DTileStyle_setters
No idea why the other tests are failing. |
@SunBlack is this ready? The new changes look good to me. |
Yes, i'm finished :) |
Actually one small fix is needed in
|
Maybe we should add a note to Readme about this changes. Any suggestion for a good short description? |
A somewhat long description, but it works:
|
Should we mention that |
…um3DTileStyle_setters
…um3DTileStyle_setters
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 |
Maybe, I'll try to look at this soon. |
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. |
Yes, this does not need to go through deprecation. Please add a bit more doc to the set/get that explains that the @lilleyse please merge when ready; I will not have the bandwidth to look at this again. |
Thanks @SunBlack! |
Tweaked doc is not fully correct, because if you set a custom object getter will return this custom object instead of an |
See discussion here