-
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
Procedural IBL Enhancement in CesiumJS #12129
base: main
Are you sure you want to change the base?
Conversation
Thank you for the pull request, @ggetz! ✅ We can confirm we have a CLA on file for you. |
if (defined(uniformMap)) { | ||
const manualUniforms = this._manualUniforms; | ||
len = manualUniforms.length; | ||
for (i = 0; i < len; ++i) { | ||
const mu = manualUniforms[i]; | ||
mu.value = uniformMap[mu.name](); | ||
try { |
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.
This update is not strictly necessary, but I found it helpful for debugging.
@jjspace Could you please take a review pass on this? |
@ggetz Couple initial comments playing with the new sandcastle.
|
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.
Had a handful of really small, mostly optional, code comments in addition to the comments above
I don't know if I feel fully qualified to review the shaders but they look ok to me at a cursory glance
for (const faceName of CubeMap.faces()) { | ||
const face = source[faceName]; |
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.
This is a bit of a nitpick but I find this naming change confusing.
Given a function named CubeMap.faces()
I would expect that to return a list of actual faces that I could iterate over like const face of CubeMap.faces()
(which I was going to suggest this be changed to). But the next line here implies that it's not actually the face itself but still only a face name. The type of the iterable also still says they're FaceName
values.
* | ||
* @type {Iterable<CubeMap.FaceName>} | ||
* | ||
* @type {iterable<CubeMap.FaceName>} |
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.
* @type {iterable<CubeMap.FaceName>} | |
* @type {Iterable<CubeMap.FaceName>} |
height, | ||
level, | ||
) { | ||
xOffset = defaultValue(xOffset, 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.
Given that we're trying to remove defaultValue
I think it's good to avoid adding new calls to avoid future conflicts?
xOffset = defaultValue(xOffset, 0); | |
xOffset = xOffset ?? 0; |
* @throws {DeveloperError} framebufferYOffset must be greater than or equal to zero. | ||
* @throws {DeveloperError} xOffset + source.width must be less than or equal to width. | ||
* @throws {DeveloperError} yOffset + source.height must be less than or equal to height. | ||
* @throws {DeveloperError} This CubeMap was destroyed, i.e., destroy() was called. |
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.
More of a meta question: All of these errors get thrown only in development because of the pragma.debug
. Given that we use the JSDoc to generate our actual documentation but these will never affect downstream users should they actually be documented like this?
if (!this._environmentMapManager.isDestroyed()) { | ||
this._environmentMapManager.destroy(); | ||
} |
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.
No change needed but curious about this pattern.
It feels like the responsibility for this check should live in the destroy
function itself. I feel like you should be able to just call destroy()
regardless and let it handle checking if it's already destroyed and essentially turn into a noop function. Then in this function the logic would just be "We know we want to guarantee this is destroyed so call destroy()
" and no wrapper check for if it's already destroyed?
defined(sphericalHarmonicCoefficients) && | ||
defined(sphericalHarmonicCoefficients[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.
It's a slightly weird syntax so completely optional but Optional Chaining does work on array access
defined(sphericalHarmonicCoefficients) && | |
defined(sphericalHarmonicCoefficients[0]) | |
defined(sphericalHarmonicCoefficients?.[0]) |
const sphericalHarmonicCoefficients = defaultValue( | ||
imageBasedLighting.sphericalHarmonicCoefficients, | ||
environmentMapManager.sphericalHarmonicCoefficients, | ||
); |
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.
const sphericalHarmonicCoefficients = defaultValue( | |
imageBasedLighting.sphericalHarmonicCoefficients, | |
environmentMapManager.sphericalHarmonicCoefficients, | |
); | |
const sphericalHarmonicCoefficients = | |
imageBasedLighting.sphericalHarmonicCoefficients ?? | |
environmentMapManager.sphericalHarmonicCoefficients; |
@@ -263,6 +263,11 @@ Model3DTileContent.prototype.update = function (tileset, frameState) { | |||
: undefined; | |||
} | |||
|
|||
const tilesetEnvironmentMapManager = tileset.environmentMapManager; | |||
if (model.environmentMapManager !== tilesetClippingPlanes) { | |||
model._environmentMapManager = tilesetEnvironmentMapManager; |
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.
Should this be using the actual setter so all that logic runs correctly?
model._environmentMapManager = tilesetEnvironmentMapManager; | |
model.environmentMapManager = tilesetEnvironmentMapManager; |
* @name czm_computeAtmosphereColor | ||
* @glslFunction | ||
* | ||
* @param {czm_rat} primaryRay Ray from the origin to sky fragment to in world coords (low precision) |
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.
🧀 🐀
* @param {czm_rat} primaryRay Ray from the origin to sky fragment to in world coords (low precision) | |
* @param {czm_ray} primaryRay Ray from the origin to sky fragment to in world coords (low precision) |
@@ -3,7 +3,7 @@ void geometryStage(out ProcessedAttributes attributes) | |||
attributes.positionMC = v_positionMC; | |||
attributes.positionEC = v_positionEC; | |||
|
|||
#if defined(COMPUTE_POSITION_WC_CUSTOM_SHADER) || defined(COMPUTE_POSITION_WC_STYLE) || defined(COMPUTE_POSITION_WC_ATMOSPHERE) | |||
#if defined(COMPUTE_POSITION_WC_CUSTOM_SHADER) || defined(COMPUTE_POSITION_WC_STYLE) || defined(COMPUTE_POSITION_WC_ATMOSPHERE) |
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.
#if defined(COMPUTE_POSITION_WC_CUSTOM_SHADER) || defined(COMPUTE_POSITION_WC_STYLE) || defined(COMPUTE_POSITION_WC_ATMOSPHERE) | |
#if defined(COMPUTE_POSITION_WC_CUSTOM_SHADER) || defined(COMPUTE_POSITION_WC_STYLE) || defined(COMPUTE_POSITION_WC_ATMOSPHERE) |
Description
This pull request introduces a new system for "procedural" lighting that builds on the Image-Based Lighting (IBL) approach in CesiumJS, aimed at improving the realism and visual quality of the default lighting environment. The changes focus on techniques that create a plausible environment map dynamically based on the current lighting conditions an existing atmospheric scattering code which renders the sky.
Image-Based Lighting Sandcastle
After
Before
Mirror Ball
After
Before
High Altitude Mirror Ball
After
Before
Dynamic Lighting
TODO: More screenshot comparisons
Key Changes
DynamicEnvironmentMapManager
: This new component generates lighting value dynamically based on the existing atmospheric calculations. It uses compute command to generate the following when position or sun position has significantly changed.DynamicEnvironmentMapManager
options accessible via theModel
andCesium3DTileset
only, at least for this PR, mainly due to the performance impact if these values are constantly updated.Additional Updates
ImageBasedLighting.imageBasedLightingFactor
: This property was broken and went unnoticed.ImageBasedLighting.luminanceAtZenith
: This property was removed instead of deprecated because there is no direct equivalent in the new implementation, and is likely not widely used (based on the fact that the above bug went unnoticed).CubeMap
: New utility functions in support of the operations inDynamicEnvironmentMapManager
, such as copying a texture to a specific face.Issue number and link
N/A
Testing plan
Author checklist
DynamicEnvironmentMapManager
options for Model entities?CONTRIBUTORS.md
CHANGES.md
with a short summary of my change