Skip to content
1 change: 1 addition & 0 deletions com.unity.render-pipelines.high-definition/CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,6 +12,7 @@ and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.
- Support for encoded HDR cubemaps, configurable via the HDR Cubemap Encoding project setting.
- The rendering order of decals that have a similar draw order value was modified. The new order should be the reverse of the previous order.
- Fixed default value of "Distortion Blur" from 1 to 0 according to the doc.
- Updated Physically Based Sky documentation with more warnings about warmup cost.

### Fixed
- Fixed some XR devices: Pulling camera world space position from mainViewConstants instead of transform.
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -133,6 +133,8 @@ The default values in either mode make it so the planet's surface is at **0** on
## Warmup cost

This sky type requires heavy precomputation to be rendered. Because of this, the first few frames (depending on the *Number of bounces* parameter) are going to take much longer. This needs to be taken into consideration when switching from another sky type to the Physically Based Sky for example as it might produce a noticeable drop in framerate.
Copy link
Contributor

Choose a reason for hiding this comment

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

Improved this bit too. Suggested change:

When you use a Physically Based Sky it might cause a noticeable drop in framerate. This is because HDRP performs a large amount of precomputations to render a Physically Based Sky, so the first few frames (depending on the Number of bounces parameter) takes more time to render than other HDRP sky types.

Copy link
Contributor Author

@JulienIgnace-Unity JulienIgnace-Unity Dec 8, 2021

Choose a reason for hiding this comment

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

Change sounds good but I think it's missing emphasis on this part:

This needs to be taken into consideration when switching from another sky type to the Physically Based Sky for >example as it might produce a noticeable drop in framerate.

That stresses out the fact that switching sky type during gameplay is going to show this drop in framerate.

Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks for your feedback! I've changed my suggestion to the following:

When you switch to or from a Physically Based Sky, it might cause a noticeable drop in framerate. This is because HDRP performs a large amount of precomputations to render a Physically Based Sky, so the first few frames (depending on the Number of bounces parameter) takes more time to render than other HDRP sky types.

This also applies when interpolating between two different Physically Based Skies with different sets of parameters by using the volume system. By doing this, Unity is forced to restart the precomputation every frame as long as interpolation is happening causing noticeable drop in framerate. To avoid that, it is recommended to only rely on a single set of parameters for a particular scene and use the sun light direction and intensity to attain the desired result.
Here is the list of parameters that will cause to restart precomputation upon change: Type, Planetary Radius, Ground Tint, Air Maximum Altitude, Air Density, Air Tint, Aerosol Maximum Altitude, Aerosol Density, Aerosol Tint, Aerosol Anisotropy, Number of Bounces.

### Reference list

Expand Down