浏览代码

added randomizer markdown docs

/main
Steven Leal 4 年前
当前提交
54ae757a
共有 6 个文件被更改,包括 147 次插入230 次删除
  1. 74
      com.unity.perception/Documentation~/Randomization/Index.md
  2. 50
      com.unity.perception/Documentation~/Randomization/Scenarios.md
  3. 29
      com.unity.perception/Documentation~/Randomization/RandomizerTags.md
  4. 42
      com.unity.perception/Documentation~/Randomization/Randomizers.md
  5. 182
      com.unity.perception/Documentation~/Randomization/Tutorial.md

74
com.unity.perception/Documentation~/Randomization/Index.md


*NOTICE: The perception randomization toolset is currently marked as experimental and will experience a number of updates in the near future.*
The randomization toolset simplifies randomizing aspects of generating synthetic data. It facilitates exposing parameters for randomization, offers samplers to pick random values from parameters, and provides scenarios to define a full randomization process. Each of these also allows for custom implementations to fit particular randomization needs.
The randomization toolset simplifies randomizing aspects of generating synthetic data. It facilitates exposing parameters for randomization, offers samplers to pick random values from parameters, and provides scenarios to coordinate a full randomization process. Each of these also allows for custom implementations to fit particular randomization needs.
**What is Domain Randomization?**
#### What is Domain Randomization?
**How can a Unity project be randomized using the Perception Randomization toolset?**
#### How can a Unity project be randomized using the Perception Randomization toolset?
1. Create a parameter configuration
2. Add parameters to the parameter configuration
3. Customize parameter properties and samplers
4. Create a scenario to control simulation execution
1. Create a scenario
2. Define and add randomizers to the scenario
3. Customize parameters and samplers in the randomizers
4. Generate randomized perception data
As the first step mentions, randomization begins with creating a new ParameterConfiguration component. From here, users can configure and organize new random parameters to control various aspects of their simulation directly from the inspector in the Unity editor.
Beginning with step 1, add a scenario component to your simulation. This scenario will act as the central hub for all randomization activities that occur when your scene is executed.
![Example Parameters](./Images/ParameterConfiguration.png)
Next, add a few randomizers to the scenario. The randomizers, in conjunction with the scenario, will perform the actual randomization activities within the simulation.
Next, create a few parameters and modify their properties. Parameters often customize their random variables through the parameter configuration using samplers. Samplers enable users to specify a type of probabilty distribution to use when generating random values.
After adding the necessary randomizers, configure the random parameters assigned to each randomizer to further customize how the simulation is randomized. The random parameters and samplers exposed in each randomizer's inspector can be manipulated to specify different probabilty distributions to use when generating random values.
Finally, add a Scenario component to the scene. Scenarios are used to coordinate the application of randomizations during the execution of a simulation.
Once the project has been randomized and your scene has been configured with the data capture tools available in the perception package, enter play mode in the editor or execute your scenario through the Unity Simulation Cloud service to generate domain randomized perception data.
Continue reading for more details concerning the primary components driving randomizations in the perception package, including:
1. Scenarios
2. Randomizers
3. Randomizer Tags
4. Parameters
5. Samplers
Continue reading for more details concerning the three primary components driving randomizations in the perception package: parameters, samplers, and scenarios.
## Scenarios
## Parameters
Within a randomized simulation, the scenario component has three responsibilities:
1. Controlling the execution flow of your simulation
2. Defining a list of randomizers
3. Defining constants that can be configured externally from a built Unity player
Parameters are used to map common types of simulation properties to random variables. For example, a Vector3 size parameter can be used to randomize the x, y, and z dimensions of an obstacle. Or a material parameter can be used to swap between different terrain surface materials. Additionally, parameter sub-properties can be modified from the parameter configuration in playmode better visualize the impact of different randomization settings.
The fundamental principle of domain randomization is to simulate environments under a variety of randomized conditions. Each **iteration** of a scenario is intended to encapsulate one complete run of a simulated environment under uniquely randomized conditions. Scenarios futher define what conditions determine the end of an iteration and how many iterations to perform.
To read more about how to create custom parameter types, navigate over to the [parameters doc](Parameters.md).
To actually randomize a simulation, randomizers can be added to a scenario to vary different simulation properties. At runtime, the scenario will execute each randomizer according to its place within the randomizers list.
Scenarios can also define constants from which to expose global simulation behaviors automatically. By modifying serialized constants externally, users can customize their simulation runtime even after their project has been built.
To read more about scenarios and how to customize them, navigate over to the [scenarios doc](Scenarios.md).
## Randomizers
Randomizers encapsulate specific randomization activities to perform during the lifecycle of a randomized simulation. For example, randomizers exist for spawning objects, repositioning lights, varying the color of objects, etc. Randomizers expose random parameters to their inspector interface to further customize these variations.
To read more about how to create custom parameter types, navigate over to the [randomizers doc](Randomizers.md).
## Samplers
Samplers generate random float values by sampling from probability distributions. They are considered bounded since each random sampler generates float values within a range defined by a minumum and maximum value. The values generated from samplers are often used to randomize the sub components of parameters.
## Randomizer Tags
![Example Parameters](./Images/ColorParameter.png)
RandomizerTags are the primary mechanism by which randomizers query for a certain subset of GameObjects to randoize within a simulation. For example, a rotation randomizer could query for all GameObjects with a RotationRandomizerTag component to obtain an array of all objects the randomizer should vary for the given simulation iteration.
For example, a color parameter has four independently randomizable components: hue, saturation, value, and alpha. Each of the four samplers attached to a color parameter can employ a unique probability distribution to customize how new colors are sampled within a simulation. Out of the box, the perception package supports uniform and normal distribution sampling. So in our color example, a user may choose a normal distribution for their hue, a uniform distribution for saturation, and a constant value sampler for the value and alpha color components.
To read more about how to use RandomizerTags, navigate over to the [RandomizerTags doc](RandomizerTags.md).
Take a look at the [samplers doc](Samplers.md) to learn more about implementing custom probability distributions and samplers that can integrate with the perception package.
## Parameters
## Scenarios
Parameters are classes that utilize samplers to deterministically generate random typed values. Parameters are often exposed within the inspector interface of randomizers to allow users to customize said randomizer's behavior. To accomplish this, parameters combine and transform the float values produced by one or more samplers into various C# types. For example, a Vector3 parameter can be used to map three samplers to the x, y, and z dimensions of a GameObject. Or a material parameter can utilize a sampler to randomly select one material from a list of possible options.
Scenarios have three responsibilities:
1. Controlling the execution flow of your simulation
2. Customizing the application of random parameters in your project
3. Defining constants that can be configured externally from a built Unity player
To read more about how to create custom parameter types, navigate over to the [parameters doc](Parameters.md).
The fundamental principle of domain randomization is to simulate environments under a variety of randomized conditions. Each **iteration** of a scenario is intended to encapsulate one complete run of a simulated environment under uniquely randomized conditions. Scenarios determine how to setup a new iteration, what conditions determine the end of an iteration, how to clean up a completed iteration, and finally how many iterations to perform. Each of these behaviors can be customized for a new scenario by deriving from the Scenario class in the perception package.
It is possible to configure parameters to affect simulation properties directly from the parameter configuration. While useful, this feature is constrained to a particular set of use cases. Instead, a user can reference existing parameters in their scenario to implement more intricate randomizations. For example, a user can reference a `SpawnCount` parameter and a `ObjectPosition` parameter to randomize the positions of a dynamic number of objects during the setup step of a scenario.
## Samplers
![Example Parameters](./Images/TestScenario.png)
Samplers generate bounded random float values by sampling from probability distributions. They are considered bounded since each random sampler generates float values within a range defined by a minumum and maximum value.
Finally, scenarios define constants from which to expose global simulation behaviors automatically. By modifying serialized constants externally, users can customize their simulation runtime even after their project has been built.
Take a look at the [samplers doc](Samplers.md) to learn more about implementing custom probability distributions and samplers that can integrate with the perception package.
Visit our [randomization tutorial doc](Tutorial.md) to get started using the perception package's randomization tools in an example project.
Visit our [randomization tutorial doc]() to get started using the perception package's randomization tools in an example project.

50
com.unity.perception/Documentation~/Randomization/Scenarios.md


# Scenarios
Scenarios have three responsibilities:
1. Controlling the execution flow of your simulation
2. Customizing the application of random parameters in your project
3. Defining constants that can be configured externally from a built Unity player
1. Controlling the execution flow of your simulation
2. Defining a list of randomizers
3. Defining constants that can be configured externally from a built Unity player
By default, the perception package includes one ready-made scenario, the `FixedLengthScenario` class. This scenario runs each iteration for a fixed number of frames and is compatible with the Run in USim window for cloud simulation execution.
## Scenario Cloud Execution (USim)
Users can utilize Unity's Unity Simulation (USim) service to execute a scenario in the cloud through the perception package's Run in USim window. To open this window from the Unity editor using the top menu bar, navigate to `Window -> Run in USim`.
From the newly opened editor window, customize the following settings to configure a new USim run:
1. **Run Name** - the name of the USim run (example: TestRun0)
2. **Total Iterations** - The number of scenario iterations to complete during the run
3. **Instance Count** - The number of USim worker instances to distribute execution between
4. **Main Scene** - The Unity scene to execute
5. **Scenario** - The scenario to execute
6. **USim Worker Config** - the type of USim worker instance to execute the scenario with. Determines per instance specifications such as the number of CPU cores, amount of memory, and presence of a GPU for accelerated execution.
By default, the perception package includes one ready-made scenario, the `FixedFrameLengthScenario` class. This scenario is useful for when all created parameters have target GameObjects configured directly in the `ParameterConfiguration` and the scenario execution requires little modification.
NOTE: To execute a scenario using the Run in USim window, the scenario class must implement the USimScenario class.
More commonly, users will find the need to create their own Scenario class. Below is an overview of the more common scenario properties and methods a user can override:
## Custom Scenarios
For use cases where the scenario should run for an arbitrary number of frames, implementing a custom scenario may be necessary. Below are the two most common scenario properties a user might want to override to implement custom scenario iteration conditions:
3. **Initialize** - actions to complete before the scenario has begun iterating
4. **Setup** - actions to complete at the beginning of each iteration
5. **Teardown** - actions to complete at the end of each iteration
6. **OnComplete** - actions to complete after the scenario as completed
Scenarios define constants from which to expose global simulation behaviors like a starting iteration value or a total iteration count. Users can serialize these scenario constants to JSON, modify them in an external program, and finally reimport the JSON constants at runtime to configure their simulation even after their project has been built. Below is an example of the constants used in the `FixedLengthScenario` class:
Scenarios define constants from which to expose global simulation behaviors like a starting iteration value or a total iteration count. Users can serialize these scenario constants to JSON, modify them in an external program, and finally reimport the JSON constants at runtime to configure their simulation even after their project has been built. Below is an example of the constants class used in the `FixedLengthScenario` class:
public class Constants
public class Constants : USimConstants
public int iterationFrameLength = 1;
public int startingIteration;
public int totalIterations = 1000;
public int framesPerIteration = 1;
A few key things to note here:
1. Make sure to include the [Serializable] attribute on a constant class. This will ensure that the constants can be manipulated from the Unity inspector.
2. By default, UnityEngine.Object class references cannot be serialized to JSON in a meaningful way. This includes Monobehaviors and SerializedObjects. For more information on what can and can't be serialized, take a look at the [Unity JsonUtility manual](https://docs.unity3d.com/ScriptReference/JsonUtility.html).
3. A scenario class's Serialize() and Deserialized() methods can be overriden to implement custom serialization strategies.
There are a few key things to note here:
1. The constants class will need to inherit from USimConstants to be compatible with the Run in USim window. Deriving from USimConstants will add a few key properties to the constants class that are needed to coordinate a USim run.
2. Make sure to include the [Serializable] attribute on a constant class. This will ensure that the constants can be manipulated from the Unity inspector.
3. By default, UnityEngine.Object class references cannot be serialized to JSON in a meaningful way. This includes Monobehaviors and SerializedObjects. For more information on what can and can't be serialized, take a look at the [Unity JsonUtility manual](https://docs.unity3d.com/ScriptReference/JsonUtility.html).
4. A scenario class's Serialize() and Deserialized() methods can be overriden to implement custom serialization strategies.

29
com.unity.perception/Documentation~/Randomization/RandomizerTags.md


# Randomizer Tags
RandomizerTags are the primary mechanism by which randomizers query for a certain subset of GameObjects to randomize within a simulation.
More specifically, RandomizerTags are components that can be added to GameObjects to register them with the active scenario's TagManager. This TagManager is aware of all objects with tags in the scene and can be queried to find all GameObjects that contain a specific tag. Below is a simple example of a ColorRandomizer querying for all GameObjects with a ColorRandomizerTag that it will apply a random material base color to:
```
[Serializable]
[AddRandomizerMenu("Perception/Color Randomizer")]
public class ColorRandomizer : Randomizer
{
static readonly int k_BaseColor = Shader.PropertyToID("_BaseColor");
public ColorHsvaParameter colorParameter;
protected override void OnIterationStart()
{
var taggedObjects = tagManager.Query<ColorRandomizerTag>();
foreach (var taggedObject in taggedObjects)
{
var renderer = taggedObject.GetComponent<MeshRenderer>();
renderer.material.SetColor(k_BaseColor, colorParameter.Sample());
}
}
}
```
RandomizerTags can also be used to customize how randomizers apply their randomizations to a particular GameObject. Visit [part two of the randomization tutorial]() to explore an in depth example of implementing a LightRandomizer that does exactly this.

42
com.unity.perception/Documentation~/Randomization/Randomizers.md


# Randomizers
Randomizers encapsulate specific randomization activities to perform during the execution of a randomized simulation. For example, randomizers exist for spawning objects, repositioning lights, varying the color of objects, etc. Randomizers expose random parameters to their inspector interface to further customize these variations. Users can add a set of randomizers to a scenario in order to define an ordered list randomization activities to perform during the lifecycle of a simulation.
To define an entirely new randomizer, derive the Randomizer class and implement one or more of the methods listed in the section below to randomize GameObjects during the runtime of a simulation.
## Randomizer Hooks
1. OnCreate() - called when the Randomizer is added or loaded to a scenario
2. OnIterationStart() - called at the start of a new scenario iteration
3. OnIterationEnd() - called the after a scenario iteration has completed
4. OnScenarioComplete() - called the after the entire scenario has completed
5. OnStartRunning() - called on the first frame a Randomizer is enabled
6. OnStopRunning() - called on the first frame a disabled Randomizer is updated
7. OnUpdate() - executed every frame for enabled Randomizers
## Randomizer Coding Example
Below is the code for the sample rotation randomizer included with the perception package:
```
[Serializable]
[AddRandomizerMenu("Perception/Rotation Randomizer")]
public class RotationRandomizer : Randomizer
{
public Vector3Parameter rotation = new Vector3Parameter();
protected override void OnIterationStart()
{
var taggedObjects = tagManager.Query<RotationRandomizerTag>();
foreach (var taggedObject in taggedObjects)
taggedObject.transform.rotation = Quaternion.Euler(rotation.Sample());
}
}
```
There are a few key things to note from this example:
1. Make sure to add the [Serializable] tag to all randomizer implementations to ensure that the randomizer can be customized and saved within the Unity Editor.
2. The [AddRandomizerMenu] attribute customizes the "Add Randomizer" sub menu path in the scenario inspector for a particular randomizer. In this example, the RotationRandomizer can be added to a scenario by opening the add randomizer menu and clicking `Perception -> Rotation Randomizer`.
3. The line `var taggedObjects = tagManager.Query<RotationRandomizerTag>();` uses RandomizerTags in combination with the current Scenario's tagManager to query for all objects with RotationRandomizerTags to obtain the subset of GameObjects within the simulation that need to have their rotations randomzied. To learn more about how RandomizerTags work, visit the [RandomizerTags doc](RandomizerTags.md).

182
com.unity.perception/Documentation~/Randomization/Tutorial.md


# Randomization Tutorial
This goal of this tutorial is to walk users through an example randomized perception project that explores the following activities:
1. Creating a parameter configuration
2. Customizing parameters and samplers
4. Configuring a scenario to run the simulation
5. Configure the perception camera
6. Building a simulation runtime
7. Modifying scenario constants
By the end of this guide, the user should have a new project that generates the perception data necessary to train a model to identify a cube from a solid colored background.
Note: Before beginning the tutorial, follow [this guide](../SetupSteps.md) to install the perception package into a new Unity project.
## Step 1: Create Scene and GameObjects
1. Create a new scene using `File -> New Scene`
2. Use the key combo `Ctrl+S` to save and name the new scene
3. Create a new cube GameObject
1. Create a new cube GameObject by navigating to `GameObject -> 3D Object -> Cube` in the menubar
2. Rename the new cube GameObject "Cube" by double clicking on the new GameObject that appeared in the hierarchy
3. Reset the cube's transform component by right clicking on transform component in the cube's inpector and clicking `Reset`
4. Create a new background GameObject
1. Create a new quad GameObject and rename it "Background"
2. Set the background quad's position to (0, 0, 2) to set it behind the cube and make the quad large enough to fill the camera by change the quad's scale to (30, 30, 1)
5. In the *MeshRenderer* component of the *Cube* and *Background* GameObjects, set `Lighting -> Cast shadows -> Off` to prevent the two objects from casting shadows on each other
## Step 2: Create Parameter Configuration
1. Create a new empty GameObject by using `GameObject -> Create Empty` from the menubar
2. Rename the new empty GameObject "Config" by double clicking on the new GameObject that appeared in the hierarchy
3. To add a new Parameter Configuration component to the Config GameObject, click on the GameObject in the hierarchy and then click the `Add Component` button in the inspector window. Select `Randomization -> Parameter Configuration` to add the new component.
## Step 3: Create and Customize Parameters
In this step, we will configure 6 parameters to randomize the scene: *CubePosition*, *CubeRotation*, *CubeScale*, *CubeColor*, *BackgroundColor*, and *CameraRotation*
#### Parameter 1: Cube Position
1. Create a new Vector3 parameter by clicking *Add New Parameter -> Vector3* on the parameter configuration inspector
2. Rename the parameter "CubePosition" by typing the text box next to the blue text indicating the parameter's type
3. Click the *Target GameObject* checkbox and select the *Cube* GameObject in the target object selector. Select the property *position* from the property dropdown.
4. Consider using the following sampler values:
* X : Uniform [-5, 5]
* Y : Uniform [-5, 5]
* Z : Constant [Value = 0]
#### Parameter 2: Cube Rotation
1. Create a new Vector3 parameter named "CubeRotation"
2. Select the *Cube* GameObject as the target GameObject and select the property *Transform.eulerAngles* from the property dropdown
3. Consider using the following component values:
* X : Uniform [0, 360]
* Y : Uniform [0, 360]
* Z : Uniform [0, 360]
#### Parameter 3: Cube Scale
1. Create a new Vector3 parameter named "CubeScale"
2. Select the *Cube* GameObject as the target GameObject and select the property *Transform.localScale* from the property dropdown
3. Consider using the following component values:
* X : Uniform [0.5, 2]
* Y : Uniform [0.5, 2]
* Z : Uniform [0.5, 2]
4. To ensure that the X, Y, and Z samplers all sample equal scale values, copy the X sampler's random seed to all three samplers
#### Parameter 4: Cube Color
1. Create a new ColorHSVA parameter named "CubeColor"
2. Skip setting the target GameObject. We will be using this parameter from within the scenario instead.
3. Consider using the following component values:
* Hue : Uniform [0, 1]
* Saturation : Uniform [0, 1]
* Value : Uniform [0.25, 1]
* Alpha : Constant [Value = 0]
#### Parameter 5: Background Color
1. Create a new ColorHSVA parameter named "BackgroundColor"
2. Skip setting the target GameObject. We will be using this parameter from within the scenario instead.
3. Consider using the following component values:
* Hue : Uniform [0, 1]
* Saturation : Uniform [0, 1]
* Value : Uniform [0.25, 1]
* Alpha : Constant [Value = 0]
#### Parameter 6: Camera Rotation
1. Create a new Vector3 parameter named "CameraRotation"
2. Select the *Main Camera* GameObject as the target GameObject and select the property *Transform.eulerAngles* from the property dropdown
3. Consider using the following component values:
* X : Constant [Value = 0]
* Y : Constant [Value = 0]
* Z : Uniform [0, 360]
## Step 4: Configure Scenario
1. Right click on the *Scripts* folder in the project hierarchy and select `Create -> C# Script`. Name the script "CubeScenario" and press enter.
2. Double click on the new "CubeScenario" script to open it for edit
3. In your code editor, paste the following C# code into the CubeScenario script:
```
using System;
using UnityEngine;
using UnityEngine.Perception.Randomization.Configuration;
using UnityEngine.Perception.Randomization.Parameters;
using UnityEngine.Perception.Randomization.Scenarios;
public class CubeScenario : Scenario<CubeScenario.Constants>
{
[Serializable]
public class Constants
{
public int totalIterations = 1000;
}
public override bool isIterationComplete => currentIterationFrame >= 1;
public override bool isScenarioComplete => currentIteration >= constants.totalIterations;
public ParameterConfiguration config;
public GameObject background;
public GameObject cube;
ColorHsvaParameter m_BackgroundColorParameter;
ColorHsvaParameter m_CubeColorParameter;
Material m_BackgroundMaterial;
Material m_CubeMaterial;
static readonly int k_BaseColor = Shader.PropertyToID("_BaseColor");
public override void OnInitialize()
{
m_BackgroundColorParameter = config.GetParameter<ColorHsvaParameter>("BackgroundColor");
m_CubeColorParameter = config.GetParameter<ColorHsvaParameter>("CubeColor");
m_BackgroundMaterial = background.GetComponent<MeshRenderer>().material;
m_CubeMaterial = cube.GetComponent<MeshRenderer>().material;
}
public override void OnIterationSetup()
{
m_BackgroundMaterial.SetColor(k_BaseColor, m_BackgroundColorParameter.Sample());
m_CubeMaterial.SetColor(k_BaseColor, m_CubeColorParameter.Sample());
}
}
```
So what is this CubeScenario script accomplishing?
1. The *Constants* nested class in this scenario script determines what scenario parameters can be JSON serialized. Only these parameters can be changed externally from a built player. In this example, we expose the number of total iterations the scenario will complete.
2. The overrided properties *isIterationComplete* and *isScenarioComplete* are checked before every frame to control the scenario's execution flow. In this case, the scenario will execute for only one frame for each iteration and continue executing until reaching the total iteration limit set by the *totalIterations* field in the constants class.
3. In Unity, manipulating the color of a material is a shader specific task that cannot be accomplished directly from a color parameter's target GameObject setting. Instead we:
1. Expose a reference to the parameter configuration this scenario's inspector as the public script variable
2. Cache the ID of the *_BaseColor* shader property
3. Override the OnInitialize() method to cache a few references. First, we lookup the parameters *BackgroundColor* and *CubeColor* by name from the the parameter configuration. Second, we grab the references to the materials attached to the cube and background GameObjects when the simulation starts.
4. Override the OnIterationSetup() method to apply randomly sampled color values to the shaders of the cached materials at the beginning of each scenario iteration
4. Back in the Unity editor, navigate to the inspector of the *Config* GameObject and use `Add Component -> CubeScenario` to add the new CubeScenario component to your parameter configuration.
5. Open the constants dropdown and confirm how many iterations the scenario should run (the default is 1000)
6. Use the *backgroundColorParameter* and *cubeColorParameter* dropdowns to inform the script of which parameters in the configuration to use for the BackgroundColor and CubeColor respectively.
7. Select the *Background* and *Cube* GameObjects from their respective GameObject field selectors
8. Confirm that the scenario and parameter configuration are composed properly by clicking the play button in the editor. In the Game window, a cube of different sizes, rotations, scales, and colors should be appearing against a color changing background.
9. To serialize the constants used in the scenario to JSON for external modification after this project has been built into a runtime, click the *Serialize Config* button on the parameter configuration
## Step 5: Configure Perception Camera
Read through the [general perception getting started guide](../GettingStarted.md) before completing the following steps:
1. (For URP projects) Add GroundTruthRendererFeature
2. Add a *PerceptionCamera* component to the MainCamera
3. Label the cube
1. Add a *Labeling* component to the cube GameObject
2. Create a *LabelingConfiguration* asset
3. Add the cube label to the new configuration
4. Select the new configuration asset from the perception camera
4. Enter play mode to confirm that labeled data is being generated
## Step 6: Build Simulation Runtime
1. Create a new sub-folder under "Assets" in the Project Hierarchy named "BuildConfigurations"
2. Right click on the BuildConfigurations folder and use `Create -> Build -> Empty Build Configuration` to create a new build configuration asset
3. Rename the build configuration asset "TutorialBuild"
4. Copy the settings from the example build configuration screenshot below:
![TutorialBuild](Images/TutorialBuild.png)
5. Click the "Build" button in the upper righthand corner of the build configuration inspector to create an executable of the tutorial scene.
## Step 7: Modify Scenario Constants
**Note**: Make sure that the "Deserialize On Start" field is checked in the scenario's inspector. A player built without this field checked will cause the player to not load serialized constants.
1. Navigate to the folder created during the build from the previous step of this tutorial (example: C:\projects\RandomizationTutorial\Builds\Tutorial)
2. Open the "_Data" folder (example: Tutorial_Data) and then open the "StreamingAssets" folder
3. Inside the folder should be the JSON scenario constants serialized from the parameter configuration in Step 4
4. Edit this JSON file to update the scenario constants used in the player
5. Confirm the new constants are deserialized at runtime by executing the simulation
正在加载...
取消
保存