-
-
Notifications
You must be signed in to change notification settings - Fork 43
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
fix: several issues with surface plots: surfaceColors, shadow (#123)
* Bugfix: make surfaceColors optional for SURFACE plots Without this there was actually no proper way to let the user specify that surfaceColors should not be used (other than setting `graph.surfaceColors = undefined` manually after construction), which means the `else { ... }` branch of the corresponding check in _redrawSurfaceGraphPoint was effectively dead code: - if called with `options.surfaceColors = undefined`, the default DEFAULTS.surfaceColors value was used - the `if (colors && colors.length !== 0)` check in _redrawSurfaceGraphPoint makes it look as it was avoidable by specifying an empty array, however throws an error in Settings.setSurfaceColor. * Improve lighting calculation The previous behaviour looked incomprehensible to me. Now it scales by how much the surface is oriented toward the viewer, and makes the bottom of the surface darker. This corresponds to diffuse lighting with light shining in the view direction. Alternatively, we could: - make no distinction between bottom and top: v = Math.abs(crossproduct.z / crossproduct.length()) - use a more standard lighting model (e.g. diffuse/specular/phong) as described here: https://learnopengl.com/Lighting/Basic-Lighting - let the user provide a function (normal vector -> lighting value) in the showShadow option Note that shadow for surface plots was probably not used by many users, because before this PR this did require manually unsetting graph.surfaceColors after graph initialization. * Fix a bug with top/bottom side calculation + showPerspective The criterion that distinguishes whether we are viewing the top or bottom of a surface is the angle between surface normal and **view direction**, which in case of the perspective projection is not the Z-axis but the location of the fragment relative to the camera. * Make showShadow work in combination with surfaceColors * Add option 'showGrayBottom' Previously, this depended on the value of showShadow, which IMO is a bug, because it couples two independent decisions. The option was mentioned as not working, because of (I'm guessing) two problems: First, the top/bottom-side calculation bug addressed in the previous commit. Second, because there are edge-cases (literally) where where a surface is curved such that part of it is viewed from below and another part from above. To properly address this scenario we would need different drawing styles for the individual triangles of the surface polygon. However, this scenario occurs so rarely, and it even then looks good enough to me. Furthermore, since this option is new and disabled by default, I doubt we will make anyone unhappy by giving them this choice. I made this new option visible in "Styling Surface", because I think it fits there the most, and it should be visible at least one of the examples. * Add option 'showSurfaceGrid' This fixes the following unexpected/inconsistent behaviours: - if surfaceColors was active (which was basically *always*, before this PR), the style for grid lines was dependent on what was drawn before (which was usually an axis or legend, and therefore basically always defaulted to axisColor), because strokeStyle was never explicitly set in this `if` branch. - if surfaceColors was inactive (for which a user would have had to manually set `graph.surfaceColors = undefined`) it was dependent on the value of the showShadow option , which is IMO also not a good choice Again, I make new possibility to disable surface grid visible in the "styling surface" example, because I believe it fits there the most, and it should be visible at least one of the examples.
- Loading branch information
Showing
8 changed files
with
103 additions
and
15 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters