-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
Fix wall negative height #9022
Fix wall negative height #9022
Conversation
Thanks for the pull request @baothientran!
Reviewers, don't forget to make sure that:
|
]), | ||
maximumHeights: [40000.0, 60000.0, 60000.0, 50000.0], | ||
minimumHeights: [60000.0, 60000.0, 60000.0, 50000.0], | ||
}) |
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'm not sure if maximumHeights should always be larger than minimumHeights. This seems to work in the master, so I assume I should test as well
Thanks @baothientran! I'll try to give this a review early next week |
@hpinkos will you be able to look at this PR soon? |
@lilleyse, yes, this and a few other CesiumJS PRs are on my list to review |
@baothientran thanks for the PR, but the amount of re-factoring you did along the way made this impossible to review. It's important that each PR only contain code changes related to a single issue instead of adding in changes to catch other things you find along the way. I've opened a PR here to fix the negative height issue: #9041 It would be much appreciated if you could open a new PR for fixing #9042. Thanks! |
Fixes #4274
Currently there is a check to prevent maxHeights from being negative in the function
removeDuplicates()
in WallGeometryLibrary.js file. I remove it, and walls with negative height are rendered correctly. But with the old method when the first member of maximumHeights array is equal to 0.0, normal vector can't be calculated. It's because vertices of the geometry are clamped to the earth's surface first before being used to calculate normal. So when the vertices themselves are on the surface, they and the clamped values have the same coordinates, which leads to undefined normal vectors. for example, there is an exception thrown when running this Sandcastle example. I'm not sure if we should let maximumHeight == minimumHeight. But since it works with value other than 0.0 in the master branch, I think I should fix it as well.For the undefined normal vector problem above, instead of clamping the top vertex to the earth surface, I use the bottom vertex to calculate normal. If the top and bottom positions have the same coordinates at the beginning (aka maximumHeight[0] == minimumHeights[0]), I just assign Y_Axis to normal, X_Axis to tangent, and Z_Axis to bitangent. If the top and bottom positions in the middle of the wall are overlapped, I just assigned the last valid normal to it. Same with tangent and bitangent. So that should prevent all of those vectors from having zero length, which leads to the error above. I had to cleanup the WallGeometry.createGeometry() method more than I expected to accommodate the changes better. Please let me know if you have a better way.
There is also a bug where texture coordinate seems to be larger than 1.0 for this sandcastle's example. This is the wall with checkerboard texture rendered in the master branch:
This is the fix in the PR:
@hpinkos @lilleyse Can you please take a look at it? Please let me know if there are anything I need to test