Skip to content

Conversation

sebastienlagarde
Copy link
Contributor

@sebastienlagarde sebastienlagarde commented Sep 8, 2021

Purpose of this PR

This PR is a big cleanup PR and also change the way we handle emissive to works correctly with RTGI/SSGI/Mixed and APV.

This PR:

  • Remove all the code introduce for ForceForwardEmissive including documentation, Receive SSGI, stripping code etc...
  • Cleanup remaining code from ProbeVolume V1
  • Cleanup stencil related code of Receive SSGI in SSGI and RTGI code
  • Uniformize the code use for RTGI/SSGI/Mixed and APV regarding lightloop, AO and SampleGI
  • Try to simplify code path, and optimize where possible
  • Added an alias EvaluateLightProbe for the function EvaluateAmbientProbe for more clarity

Explanation about how APV and SSGI/RTGI/Mixed effects will handle emissve with this PR and the steps.

All effects will output only Emissive inside the lighting buffer (gbuffer3) in case of deferred (For APV this is done only if we are not a lightmap). The Lightmaps/Lightprobes contribution is 0 for those cases. Code enforce it in SampleBakedGI(). The remaining code of Material pass (and the debug code) is exactly the same with or without effects on, including the EncodeToGbuffer. builtinData.isLightmap is used by APV to know if we have lightmap or not and is harcoded based on preprocessor in InitBuiltinData()

AO is also store with a hack in Gbuffer3 if possible. Otherwise it is set to 1.
In case of regular deferred path (when effects aren't enable) AO is already apply on lightmap and emissive is added on to of it. All is inside bakeDiffuseLighting and emissiveColor is 0. AO must be 1

When effects are enabled and for APV we don't have lightmaps, bakeDiffuseLighting is 0 and emissiveColor contain emissive (Either in deferred or forward) and AO should be the real AO value.
Then in the lightloop in below code we will evalaute APV or read the indirectDiffuseTexture to fill bakeDiffuseLighting.
We will then just do all the regular step we do with bakeDiffuseLighting in PostInitBuiltinData()
No code change is required to handle AO, it is the same for all path.

Note: With current approach, Decals Emissive aren't taken into account by RTGI and by the Mixed method.
Note2: With current approach, Transparent Emissive works with SSGI and RTGI but can cause artifact with Mixed (RayMarch part could get a hit and thus avoid Raytrace path)
Note3: Forward opaque emissive work in all cases. The current code flow with Emissive store in GBuffer3 is only to manage the case of Opaque Lit Material with Emissive in case of deferred
Note4: Only APV can handle backFace lighting, all other effects are front face only.

TODO: complete documentation


Testing status

TODO (no test done yet) Test Plan:

Scenario are: SSGI, RTGI, Mixed, APV, SSGI with APV with forward and deferred case

With scene that have emissive decal, emissive transparent unlit, emissive opaque unlit lit opaque emissive.

Test all debug lighting mode: lighting only, emissive only, override emissive for all scenario
Test with probe volume on/off when APV is enable
Test indirect diffuse multiplier for all scenario
Test that AO behave correctly in all scenario


Comments to reviewers

Notes for the reviewers you have assigned.

@github-actions
Copy link

github-actions bot commented Sep 8, 2021

Hi! This comment will help you figure out which jobs to run before merging your PR. The suggestions are dynamic based on what files you have changed.
Link to Yamato: https://yamato.cds.internal.unity3d.com/jobs/902-Graphics
Search for your PR branch using the sidebar on the left, then add the following segment(s) to the end of the URL (you may need multiple tabs depending on how many packages you change)

HDRP
/.yamato%252Fall-hdrp.yml%2523PR_HDRP_trunk

Depending on the scope of your PR, you may need to run more jobs than what has been suggested. Please speak to your lead or a Graphics SDET (#devs-graphics-automation) if you are unsure.

@github-actions github-actions bot added the HDRP label Sep 9, 2021
outGBuffer3 = float4(builtinData.bakeDiffuseLighting * surfaceData.ambientOcclusion + builtinData.emissiveColor, 0.0);
// Pre-expose lighting buffer
outGBuffer3.rgb *= GetCurrentExposureMultiplier();
outGBuffer3.xz = AO_IN_GBUFFER3_TAG.xz;
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@FrancescoC-unity . I finally decided to do some kind of hack to store AO. See the comment, but short: if we don't have emissive, then we store AO. Should solve 90% of our use case and don't require extra buffer.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah sounds like a valid solution indeed

Copy link
Contributor

@anisunity anisunity left a comment

Choose a reason for hiding this comment

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

Approved after changes

Copy link
Contributor

@remi-chapelain remi-chapelain left a comment

Choose a reason for hiding this comment

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

This PR simplifies greatly the setup and need for comprehension when having a combinaison of real-time/baked global illumination technique with emissive materials.

Before, in deferred, users needed to disable receive SSGI flag or enable Force Forward Emissive per material which created much confusion.
Now, everything is supposed to work properly out of the box without having to enable anything new.

PR have been tested thoroughly to ensure no unexpected regressions.
What's tested:

  • Upgrade a project with SSGI and Force Forward Emissive ✔️
  • SSGI / RTGI / Mixed still replaces lightmaps ✔
  • Check transparent emissive still not contributing except when in pre-refraction for SSGI ✔️
  • Decal Emissive still not contributing in RTGI or Mixed mode ✔️
  • Building APV and relying on probe data to fill SSGI artefacts with emissive objects in the scenes ✔️
  • Material with Diffuse, AO, Emissive with SSGI and/or APV ✔️
    (in Deferred, with SSGI or APV, we lose material AO contribution, but not with Lightmaps)
    (in Forward, everything works in all cases)
  • SSAO/RTAO still contributes as expected ✔️
  • Can still multiply indirect lighting contribution for Lightmaps / APV / SSGI / RTGI / Mixed ✔️
  • Emissive still works with SSS ✔️
  • Emissive still works with RT SSS 🔴 (not related to this PR > reported here)
  • DXR Tests are all green locally ✔️
  • Performance (roughly same frame time in 4K in a scene with SSGI with lots of emissive / ao) ✔️

@sebastienlagarde sebastienlagarde marked this pull request as ready for review September 10, 2021 17:25
@sebastienlagarde sebastienlagarde merged commit 4debbac into master Sep 12, 2021
@sebastienlagarde sebastienlagarde deleted the HDRP/remove-force-forward-emissive branch September 12, 2021 16:48
sebastienlagarde added a commit that referenced this pull request Sep 12, 2021
@sebastienlagarde
Copy link
Contributor Author

@Vic-Cooper : Sorry I realize I forget to add you for doc checking on this PR. Could you add it in your backlog? Thanks a lot

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants