Skip to content

[Fogbugz 1330769] Fixing bloom bicubic filtering for DRS #4370

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.

Sign up for GitHub

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

Merged
merged 4 commits into from
Apr 30, 2021
Merged

[Fogbugz 1330769] Fixing bloom bicubic filtering for DRS #4370

Show file tree
Hide file tree
Changes from 2 commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
35cb082
Fixing bloom bicubic filtering for DRS, bicubic was using the wrong d…
kecho Apr 28, 2021
afd7e20
Adding better comment to explain offseting of bicubic texture offset fix
kecho Apr 29, 2021
aeea9e7
Merge branch 'hd/bugfix' into HDRP/FixDRSBloom
sebastienlagarde Apr 30, 2021
2b7356c
update reference screenshots
sebastienlagarde Apr 30, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions com.unity.render-pipelines.high-definition/CHANGELOG.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -169,6 +169,7 @@ and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.
- Fixed NaNs when denoising pixels where the dot product between normal and view direction is near zero (case 1329624).
- Fixed ray traced reflections that were too dark for unlit materials. Reflections are now more consistent with the material emissiveness.
- Fixed pyramid color being incorrect when hardware dynamic resolution is enabled.
- Fixed blocky looking bloom when dynamic resolution scaling was used.

### Changed
- Changed Window/Render Pipeline/HD Render Pipeline Wizard to Window/Rendering/HDRP Wizard
Expand Down
10 changes: 10 additions & 0 deletions ...y.render-pipelines.high-definition/Runtime/RenderPipeline/HDRenderPipeline.PostProcess.cs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3165,6 +3165,16 @@ void PrepareBloomData(RenderGraph renderGraph, in RenderGraphBuilder builder, Bl
// the mip up 0 will be used by uber, so not allocated as transient.
m_BloomBicubicParams = new Vector4(passData.bloomMipInfo[0].x, passData.bloomMipInfo[0].y, 1.0f / passData.bloomMipInfo[0].x, 1.0f / passData.bloomMipInfo[0].y);
var mip0Scale = new Vector2(passData.bloomMipInfo[0].z, passData.bloomMipInfo[0].w);

// We undo the scale here, because bloom uses these parameters for its bicubic filtering offset.
// The bicubic filtering function is SampleTexture2DBicubic, and it requires the underlying texture's
// unscaled pixel sizes to compute the offsets of the samples.
// For more info please see the implementation of SampleTexture2DBicubic
m_BloomBicubicParams.x /= RTHandles.rtHandleProperties.rtHandleScale.x;
Copy link
Contributor

@FrancescoC-unity FrancescoC-unity Apr 29, 2021 •
edited
Loading

Choose a reason for hiding this comment

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

So these parameters should be baked in the actualWidth/actualHeight used here https://github.com/Unity-Technologies/Graphics/pull/4370/files#diff-617165acfec9a5b4c1b26809291f30938d7a152b8e9fec0e5ae2c661078201dbR3148 , by dividing we are undoing that and assuming full resolution source?

I might be misreading here as I didn't have my coffee yet, but worth double checking values :D

Copy link
Contributor Author

@kecho kecho Apr 29, 2021

Choose a reason for hiding this comment

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

yes! we want exactly that, the actual full resolution of the texture. To understand why, you need to look at bicubic sampling. Thats were these params are used. Bicubic sampling function requires texel size to compute the offsets, but the texel size must be that of the physical texture (so the uv can be offset correctly).
If we use instead say texture.width here, then we have to write special code for hardware drs, because hardware drs hides the render - time resource size. So the easiest way is to just 'undo' the texture scale.

Copy link
Contributor Author

@kecho kecho Apr 29, 2021

Choose a reason for hiding this comment

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

@FrancescoC-unity I have added a comment on this snippet to explain it

Copy link
Contributor

@FrancescoC-unity FrancescoC-unity Apr 29, 2021

Choose a reason for hiding this comment

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

Yup it does make sense 👍

m_BloomBicubicParams.y /= RTHandles.rtHandleProperties.rtHandleScale.y;
m_BloomBicubicParams.z *= RTHandles.rtHandleProperties.rtHandleScale.x;
m_BloomBicubicParams.w *= RTHandles.rtHandleProperties.rtHandleScale.y;

passData.mipsUp[0] = builder.WriteTexture(renderGraph.CreateTexture(new TextureDesc(mip0Scale, true, true)
{
name = "Bloom final mip up",
Expand Down