com.unity.render-pipelines.core@11.0.0 in Unity 2021.1.0f1

## [11.0.0] - 2020-10-21

### Added
- Support for the PlayStation 5 platform has been added.
- Support for the XboxSeries platform has been added.

### Fixed
- Fixed the default background color for previews to use the original color.
- Fixed a bug in FreeCamera which would only provide a speed boost for the first frame when pressing the Shfit key.
- Fixed spacing between property fields on the Volume Component Editors.
- Fixed ALL/NONE to maintain the state on the Volume Component Editors.
- Fixed the selection of the Additional properties from ALL/NONE when the option "Show additional properties" is disabled
- Fixed ACES tonemaping for Nintendo Switch by forcing some shader color conversion functions to full float precision.
- Fixed missing warning UI about Projector component being unsupported (case 1300327).
- Fixed the display name of a Volume Parameter when is defined the attribute InspectorName
- Fix crash on VolumeComponentWithQualityEditor when the current Pipeline is not HDRP

CHANGELOG.md

@@ -6,8 +6,20 @@ and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.
 
 ## [11.0.0] - 2020-10-21
 
-Version Updated
-The version number for this package has increased due to a version update of a related graphics package.
+### Added
+- Support for the PlayStation 5 platform has been added.
+- Support for the XboxSeries platform has been added.
+
+### Fixed
+- Fixed the default background color for previews to use the original color.
+- Fixed a bug in FreeCamera which would only provide a speed boost for the first frame when pressing the Shfit key.
+- Fixed spacing between property fields on the Volume Component Editors.
+- Fixed ALL/NONE to maintain the state on the Volume Component Editors.
+- Fixed the selection of the Additional properties from ALL/NONE when the option "Show additional properties" is disabled
+- Fixed ACES tonemaping for Nintendo Switch by forcing some shader color conversion functions to full float precision.
+- Fixed missing warning UI about Projector component being unsupported (case 1300327).
+- Fixed the display name of a Volume Parameter when is defined the attribute InspectorName
+- Fix crash on VolumeComponentWithQualityEditor when the current Pipeline is not HDRP
 
 ## [10.2.0] - 2020-10-19
 

Documentation~/TableOfContents.md

@@ -12,7 +12,7 @@
 * [RTHandle system](rthandle-system.md)
   * [RTHandle fundamentals](rthandle-system-fundamentals.md)
   * [Using the RTHandle system](rthandle-system-using.md)
-
+* [Custom Material Inspector](custom-material-inspector.md)
 
 * [Look Dev](Look-Dev)
 

Documentation~/custom-material-inspector.md

@@ -0,0 +1,50 @@
+# Custom Material Inspector
+
+Custom Material Inspectors enable you to define how Unity displays properties in the Material Inspector for a particular shader. This is useful if a shader includes a lot of properties and you want to organize them in the Inspector. The Universal Render Pipeline (URP) and High Definition Render Pipeline (HDRP) both support custom Material Inspectors, but the method to create them is slightly different.
+
+## Creating a custom Material Inspector
+
+The implementation for custom Material Inspectors differs between URP and HDRP. For example, for compatibility purposes, every custom Material Inspector in HDRP must inherit from `HDShaderGUI` which does not exist in URP. For information on how to create custom Material Inspectors for the respective render pipelines, see:
+
+- **HDRP**: [HDRP custom Material Inspectors](https://docs.unity3d.com/Packages/com.unity.render-pipelines.high-definition@latest?subfolder=/manual/hdrp-custom-material-inspector.html).
+- **URP**: [Unity Custom Shader GUI](https://docs.unity3d.com/Manual/SL-CustomShaderGUI.html).
+
+## Assigning a custom Material Inspector
+
+When you create a shader, either hand-written or using Shader Graph, both URP and HDRP provide a default editor for it to use. To override this default and provide your own custom Material Inspector, the method differs depending on whether you hand-wrote the shader or used Shader Graph.
+
+### Using hand-written shaders
+
+To set a custom Material Inspector for a hand-written shader:
+
+1. Open the shader source file.
+2. Assign a string that contains the class name of the custom Material Inspector to the **CustomEditor** shader instruction.
+
+This is the same method as for the Built-in Renderer's [custom shader GUI](<https://docs.unity3d.com/Manual/SL-CustomShaderGUI.html>).
+
+For an example of how to do this, see the following shader code sample. In this example, the name of the custom Material Inspector class is **ExampleCustomMaterialInspector**:
+
+```c#
+Shader "Custom/Example"
+{
+    Properties
+    {
+        // Shader properties
+    }
+    SubShader
+    {
+        // Shader code
+    }
+    CustomEditor "ExampleCustomMaterialInspector"
+}
+```
+
+
+### Using Shader Graph
+
+To set a custom Material Inspector for a Shader Graph shader:
+
+1. Open the Shader Graph.
+2. In the [Graph Inspector](<https://docs.unity3d.com/Packages/com.unity.shadergraph@latest?subfolder=/manual/Internal-Inspector.html>), open the Graph Settings tab.
+3. If **Active Targets** does not include the render pipeline your project uses, click the **plus** button then, in the drop-down, click the render pipeline.
+4. In the render pipeline section (**HDRP** or **URP** depending on the render pipeline your project uses) find the **Custom Editor GUI** property and provide it the name of the custom Material Inspector.

Documentation~/render-graph-benefits.md

@@ -2,12 +2,12 @@
 
 ## Efficient memory management
 
-When you manage resource allocation manually, you have to account for when every rendering feature is active at the same time and thus allocate for the worst-case scenario. When particular rendering features are not active, the resources to process them are there, but the render pipeline just does not use them. Contrarily, a render graph only allocates resources that the frame actually uses. This reduces the memory footprint of the render pipeline and means that there is no need to create complicated logic to handle resource allocation. Another benefit of efficient memory management is that, since a render graph can reuse resources efficiently, there are more resources available to create features for your render pipeline.
+When you manage resource allocation manually, you have to account for scenarios when every rendering feature is active at the same time and thus allocate for the worst-case scenario. When particular rendering features are not active, the resources to process them are there, but the render pipeline does not use them. A render graph only allocates resources that the frame actually uses. This reduces the memory footprint of the render pipeline and means that there is no need to create complicated logic to handle resource allocation. Another benefit of efficient memory management is that, because a render graph can reuse resources efficiently, there are more resources available to create features for your render pipeline.
 
 ## Automatic synchronization point generation
 
 Asynchronous compute queues can run in parallel to the regular graphic workload and, as a result, may reduce the overall GPU time it takes to process a render pipeline. However, it can be difficult to manually define and maintain synchronization points between an asynchronous compute queue and the regular graphics queue. A render graph automates this process and, using the high-level declaration of the render pipeline, generates correct synchronization points between the compute and graphics queue.
 
 ## Maintainability
 
-One of the most complex issues when it comes to render pipeline maintenance is the management of resources. Since a render graph manages resources internally, it makes it much easier to maintain your render pipeline. Using the RenderGraph API, you can write efficient self-contained rendering modules that declare their input and output explicitly and are able to plug in anywhere in a render pipeline.
+One of the most complex issues in render pipeline maintenance is the management of resources. Because a render graph manages resources internally, it makes it much easier to maintain your render pipeline. Using the RenderGraph API, you can write efficient self-contained rendering modules that declare their input and output explicitly and are able to plug in anywhere in a render pipeline.

Documentation~/render-graph-fundamentals.md

@@ -1,37 +1,37 @@
 # Render graph fundamentals
 
-This document describes the main principles behind a render graph and an overview of how Unity executes it.
+This document describes the main principles of a render graph and an overview of how Unity executes it.
 
 ## Main principles
 
-There are a few things to know before you can write render passes with the [RenderGraph](../api/UnityEngine.Experimental.Rendering.RenderGraphModule.RenderGraph.html) API. The following principles are the foundation of how a render graph works.
+Before you can write render passes with the [RenderGraph](../api/UnityEngine.Experimental.Rendering.RenderGraphModule.RenderGraph.html) API, you need to know the following foundational principles:
 
 - You no longer handle resources directly and instead use render graph system-specific handles. All RenderGraph APIs use these handles to manipulate resources. The resource types a render graph manages are [RTHandles](rthandle-system.md), [ComputeBuffers](https://docs.unity3d.com/ScriptReference/ComputeBuffer.html), and [RendererLists](../api/UnityEngine.Experimental.Rendering.RendererList.html).
 - Actual resource references are only accessible within the execution code of a render pass.
-- The framework requires an explicit declaration of render passes. Each render pass needs to state which resources it reads from and/or writes to.
+- The framework requires an explicit declaration of render passes. Each render pass must state which resources it reads from and/or writes to.
 - There is no persistence between each execution of a render graph. This means that the resources you create inside one execution of the render graph cannot carry over to the next execution.
-- For resources that need persistence (from one frame to another for example), you can create them outside of a render graph, like regular resources, and import them in. They behave as any other render graph resource in terms of dependency tracking, but the graph does not handle their lifetime.
+- For resources that need persistence (from one frame to another for example), you can create them outside of a render graph, like regular resources, and import them in. They behave like any other render graph resource in terms of dependency tracking, but the graph does not handle their lifetime.
 - A render graph mostly uses `RTHandles` for texture resources. This has a number of implications on how to write shader code and how to set them up.
 
 ## Resource Management
 
-The render graph system calculates the lifetime of each resource using the high-level representation of the whole frame. This means that when you create a resource via the RenderGraph API, the render graph system does not actually create the resource at that time. Instead, the API returns a handle that represents the resource that you then use with all RenderGraph APIs. The render graph only creates the resource just before the first pass that needs to write it. In this case, “creating” does not necessarily mean the render graph system allocates resources, but rather that it provides the necessary memory to represent the resource so that it can use the resource during a render pass. In the same manner, it also releases the resource memory after the last pass that needs to read it. This way, the render graph system can reuse memory in the most efficient manner based on what you declare in your passes. This also means that if the render graph system does not execute a pass that requires a specific resource, then the system does not allocate the memory for the resource.
+The render graph system calculates the lifetime of each resource with the high-level representation of the whole frame. This means that when you create a resource via the RenderGraph API, the render graph system does not create the resource at that time. Instead, the API returns a handle that represents the resource, which you then use with all RenderGraph APIs. The render graph only creates the resource just before the first pass that needs to write it. In this case, “creating” does not necessarily mean that the render graph system allocates resources. Rather, it means that it provides the necessary memory to represent the resource so that it can use the resource during a render pass. In the same manner, it also releases the resource memory after the last pass that needs to read it. This way, the render graph system can reuse memory in the most efficient manner based on what you declare in your passes. If the render graph system does not execute a pass that requires a specific resource, then the system does not allocate the memory for the resource.
 
 ## Render graph execution overview
 
-Render graph execution is a three-step process the render graph system completes, from scratch, every frame. This is because a graph can change dynamically from frame to frame, depending on the actions of the user for example.
+Render graph execution is a three-step process that the render graph system completes, from scratch, every frame. This is because a graph can change dynamically from frame to frame, for example, depending on the actions of the user.
 
 ### Setup
 
-The first step is to set up all the render passes. This is where you declare all the render passes to execute as well as the resources each render pass uses.
+The first step is to set up all the render passes. This is where you declare all the render passes to execute and the resources each render pass uses.
 
 ### Compilation
 
-The second step is to compile the graph. During this step, the render graph system culls render passes if no other render pass uses their outputs. This allows for more careless setups because you can reduce specific logic when you set up the graph. A good example of that is debug render passes. If you declare a render pass that produces a debug output that you don't present to the back buffer, the render graph system culls that pass automatically.
+The second step is to compile the graph. During this step, the render graph system culls render passes if no other render pass uses their outputs. This allows for less organized setups because you can reduce specific logic when you set up the graph. A good example of that is debug render passes. If you declare a render pass that produces a debug output that you don't present to the back buffer, the render graph system culls that pass automatically.
 
 
 This step also calculates the lifetime of resources. This allows the render graph system to create and release resources in an efficient way as well as compute the proper synchronization points when it executes passes on the asynchronous compute pipeline.
 
 ### Execution
 
-Finally, execute the graph. The render graph system executes all render passes, that it did not cull, in declaration order. Before each render pass, the render graph system creates the proper resources and releases them after the render pass if later render passes do not use them.
+Finally, execute the graph. The render graph system executes all render passes that it did not cull, in declaration order. Before each render pass, the render graph system creates the proper resources and releases them after the render pass if later render passes do not use them.

Documentation~/render-graph-system.md

@@ -1,16 +1,16 @@
 # The render graph system
 
-The render graph system is a system that sits on top of Unity's Scriptable Render Pipeline (SRP). It allows you to author a custom SRP in a maintainable and modular way. Unity's High Definition Render Pipeline (HDRP) uses the render graph system.
+The render graph system sits on top of Unity's Scriptable Render Pipeline (SRP). It allows you to author a custom SRP in a maintainable and modular way. Unity's High Definition Render Pipeline (HDRP) uses the render graph system.
 
-You use the [RenderGraph](../api/UnityEngine.Experimental.Rendering.RenderGraphModule.RenderGraph.html) API to create a render graph. A render graph is a high-level representation of the custom SRP's render passes, which explicitly states how they use resources.
+You use the [RenderGraph](../api/UnityEngine.Experimental.Rendering.RenderGraphModule.RenderGraph.html) API to create a render graph. A render graph is a high-level representation of the custom SRP's render passes, which explicitly states how the render passes use resources.
 
-Describing render passes in this way has two benefits: it simplifies render pipeline configuration, and it allows the render graph system to efficiently manage various parts of the render pipeline, which can result in improved runtime performance. For more information on the benefits of the render graph system, see [benefits of the render graph system](render-graph-benefits.md).
+Describing render passes in this way has two benefits: it simplifies render pipeline configuration, and it allows the render graph system to efficiently manage parts of the render pipeline, which can result in improved runtime performance. For more information on the benefits of the render graph system, see [benefits of the render graph system](render-graph-benefits.md).
 
 To use the render graph system, you need to write your code in a different way to a regular custom SRP. For more information on how to write code for the render graph system, see [writing a render pipeline](render-graph-writing-a-render-pipeline.md).
 
 For information on the technical principles behind the render graph system, see [render graph fundamentals](render-graph-fundamentals.md).
 
-**Note**: Render graph is currently experimental which means Unity may change its API during future development.
+**Note**: Render graph is currently experimental which means Unity might change its API during future development.
 
 This section contains the following pages: