Search Issue Tracker
Won't Fix
Won't Fix in 2023.1.X
Votes
0
Found in
2019.4.40f1
2020.3.35f1
2021.2.19f1
2022.1.9f1
2022.2.0b1
2023.1.0a1
Issue ID
UUM-1874
Regression
No
Objects are black after rendering when using CommandBuffer
Reproduction steps:
1. Open the attached 'Bug Test' project
2. Open the 'Test' Scene
3. Enter the Play mode
Expected result: boxes are rendered correctly
Actual result: boxes are black after rendering
Reproducible with: 2019.4.34f1, 2020.3.25f1, 2021.2.7f1, 2022.1.0b2
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Objects with Universal Render Pipeline/Particles/Lit shader are always lit up when changing their Rendering Layer Mask
- PolySpatial “Trying to set shader on a Material Variant.” error is printed in the console when entering Play Mode
- Error “Shader error in 'YSCloudCover': call to 'tex3D' is ambiguous at Assets/YSCloudCoverText.shader(606) (on d3d11)“ is present when compiling tex3D shader with DXC
- Placeholder asset is not loaded with Advertisement Legacy sample when using the latest version of the package
- Addressables content build fails but the Player build is successful when building a development build
Resolution Note:
The reason this issue occurs is because draw calls executed via a render event invocation do not inherit the same state that normal draw calls do.
For example, normal draw calls are split into jobs that each have their own copy of a passContext which is updated to enable various passes like rendering reflections and emissions.
The passContext is updated in the job threads. However, the passContext isn't shared with the draw calls that happen within a render event.
The behavior of the builtin renderer's render events has been around for quite some time and we are hesitant to change it as
it could break many developers who depend on it. I would suggest that the developer consider switching to a scriptable render pipeline where they will have much more control over the rendering.
I was able to improve the situation by changing a few things in their project however it does not render identically to the version with command buffers.
They will need to ensure the correct stencil buffer settings are used in "Instanced/InstancedSurfaceShader" by adding the following
Stencil
{
Ref 192
Comp Always
Pass Replace
}
Additionally, they will need to add the following to ensure that reflections are applied to their command buffer draw calls.
cam.AddCommandBuffer(CameraEvent.AfterReflections, gbufferCommandBuffer);
Resolution Note (2023.1.X):
The reason this issue occurs is because draw calls executed via a render event invocation do not inherit the same state that normal draw calls do.
For example, normal draw calls are split into jobs that each have their own copy of a passContext which is updated to enable various passes like rendering reflections and emissions.
The passContext is updated in the job threads. However, the passContext isn't shared with the draw calls that happen within a render event.
The behavior of the builtin renderer's render events has been around for quite some time and we are hesitant to change it as
it could break many developers who depend on it. I would suggest that the developer consider switching to a scriptable render pipeline where they will have much more control over the rendering.
I was able to improve the situation by changing a few things in their project however it does not render identically to the version with command buffers.
They will need to ensure the correct stencil buffer settings are used in "Instanced/InstancedSurfaceShader" by adding the following
Stencil
{
Ref 192
Comp Always
Pass Replace
}
Additionally, they will need to add the following to ensure that reflections are applied to their command buffer draw calls.
cam.AddCommandBuffer(CameraEvent.AfterReflections, gbufferCommandBuffer);