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

Adds normalShading option to the repo #5433

Closed

Conversation

AnimatedRNG
Copy link
Contributor

Part of #5152

var vertexArray = content._drawCommand.vertexArray;

var normalsEnabled = hasNormals && normalShading;
Copy link
Contributor

Choose a reason for hiding this comment

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

I actually think this boolean may not be the right approach. We still want backFaceCulling to work even if normalShading is false.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Updated with a new fix for this case

Copy link
Contributor

Choose a reason for hiding this comment

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

backFaceCulling will have issues because all the normal attribute setup is still behind the normalsEnabled boolean. Ultimately normalsEnabled should probably be removed.

Copy link
Contributor Author

@AnimatedRNG AnimatedRNG Jun 8, 2017

Choose a reason for hiding this comment

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

So that entire function should just ignore normalShading?

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, except for the part that actually does normal shading.

Another approach is to continue to use normalsEnabled but set it equal to normalShading || backFaceCulling.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I made those edits, although I'm don't totally understand the relationship between backface culling and normal shading in that function

Copy link
Contributor

Choose a reason for hiding this comment

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

backFaceCulling and normalShading are independent of each other but both require normals. So normalsEnabled should be true if hasNormals is true and at least one of the options is true. When appending the back face culling code it will need to check normalsEnabled && backFaceCulling and when appending the normal shading code it will need to check normalsEnabled && normalShading.

The original idea I had was to keep most of the code as is and just wrap the normal shading code with hasNormals && normalShading.

@lilleyse
Copy link
Contributor

lilleyse commented Jun 8, 2017

Also be sure to write a test for this. It can be something like rendering with normalShading, then rendering with normalsShading off, then checking that the colors are different.

See rebuilds shader style when expression changes for a partway example.

@lilleyse
Copy link
Contributor

lilleyse commented Jun 8, 2017

Other than those comments, looks great! I tested that it works in Sandcastle.

@AnimatedRNG
Copy link
Contributor Author

Updated with a new test

@mramato mramato changed the base branch from 3d-tiles to master June 19, 2017 17:11
@pjcozzi
Copy link
Contributor

pjcozzi commented Jul 21, 2017

What's the plan here? Do we still plan to do this in light of #5455?

Copy link
Contributor

@lilleyse lilleyse left a comment

Choose a reason for hiding this comment

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

It's still a good idea to finish this up - these are my last comments here.

var vertexArray = content._drawCommand.vertexArray;

var normalsEnabled = (hasNormals && normalShading) || backFaceCulling;
Copy link
Contributor

Choose a reason for hiding this comment

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

This should be:

var normalsEnabled = hasNormals && (normalShading || backFaceCulling);

@@ -1002,7 +1009,7 @@ define([

vs += ' color = color * u_highlightColor; \n';

if (hasNormals) {
if (normalsEnabled) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Should be normalsEnabled && normalShading

@@ -1012,7 +1019,7 @@ define([
vs += ' v_color = color; \n' +
' gl_Position = czm_modelViewProjection * vec4(position, 1.0); \n';

if (hasNormals && backFaceCulling) {
if (normalsEnabled) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Should be normalsEnabled && backFaceCulling.

@lilleyse
Copy link
Contributor

lilleyse commented Nov 7, 2017

I made some final adjustments here. @ggetz would you like to review?

@ggetz
Copy link
Contributor

ggetz commented Nov 8, 2017

@lilleyse Looks good to me

@pjcozzi
Copy link
Contributor

pjcozzi commented Nov 8, 2017

Quick out of touch question: since PointCloud3DTileContent is private, when and how is this used?

@lilleyse
Copy link
Contributor

lilleyse commented Nov 8, 2017

Right now it's not used, unless someone knows what they're doing. It's like the backFaceCulling option which is also only in this file.

I don't think we ever concluded if these should be properties of the tileset, or the style, or just in the styling language.

@pjcozzi
Copy link
Contributor

pjcozzi commented Nov 8, 2017

So are we sure we want to merge this? Seems like no.

@hpinkos
Copy link
Contributor

hpinkos commented Jan 11, 2018

@lilleyse Are we planning to merge this at some point or should we close this?

@lilleyse
Copy link
Contributor

Personally I don't think there's any harm in merging this since it doesn't preclude a future PR, and everything in here is @private.

I also don't care that strongly if it's closed either.

@hpinkos
Copy link
Contributor

hpinkos commented Jan 11, 2018

Is this something that is going to be useful or is it not going to be used? If it doesn't add any particular value we should probably just close it.

@lilleyse
Copy link
Contributor

It's minor enough to close.

@lilleyse lilleyse closed this Jan 11, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants