Unity-Technologies · armstrongl · Nov 2, 2022 · Oct 25, 2022 · Oct 27, 2022
diff --git a/docs/basics/scenemanagement/images/ClientSyncUpdates.png b/docs/basics/scenemanagement/images/ClientSyncUpdates.png
diff --git a/docs/basics/scenemanagement/images/ClientSyncUpdates_Dark.png b/docs/basics/scenemanagement/images/ClientSyncUpdates_Dark.png
diff --git a/docs/basics/scenemanagement/images/ClientSyncUpdates_Light.png b/docs/basics/scenemanagement/images/ClientSyncUpdates_Light.png
diff --git a/docs/basics/scenemanagement/images/LoadNewSceneTimeline.png b/docs/basics/scenemanagement/images/LoadNewSceneTimeline.png
diff --git a/docs/basics/scenemanagement/images/LoadNewSceneTimeline_Dark.png b/docs/basics/scenemanagement/images/LoadNewSceneTimeline_Dark.png
diff --git a/docs/basics/scenemanagement/images/LoadNewSceneTimeline_Light.png b/docs/basics/scenemanagement/images/LoadNewSceneTimeline_Light.png
diff --git a/docs/basics/scenemanagement/images/LoadingAdditiveScene.png b/docs/basics/scenemanagement/images/LoadingAdditiveScene.png
diff --git a/docs/basics/scenemanagement/images/LoadingAdditiveScene_Dark.png b/docs/basics/scenemanagement/images/LoadingAdditiveScene_Dark.png
diff --git a/docs/basics/scenemanagement/images/LoadingAdditiveScene_Light.png b/docs/basics/scenemanagement/images/LoadingAdditiveScene_Light.png
diff --git a/docs/basics/scenemanagement/images/SceneEventSynchronizationTimeline.png b/docs/basics/scenemanagement/images/SceneEventSynchronizationTimeline.png
diff --git a/docs/basics/scenemanagement/images/SceneEventSynchronizationTimeline_Dark.png b/docs/basics/scenemanagement/images/SceneEventSynchronizationTimeline_Dark.png
diff --git a/docs/basics/scenemanagement/images/SceneEventSynchronizationTimeline_Light.png b/docs/basics/scenemanagement/images/SceneEventSynchronizationTimeline_Light.png
diff --git a/docs/basics/scenemanagement/images/SwitchingToNewSceneLight.png b/docs/basics/scenemanagement/images/SwitchingToNewSceneLight.png
diff --git a/docs/basics/scenemanagement/images/SwitchingToNewScene_Dark.png b/docs/basics/scenemanagement/images/SwitchingToNewScene_Dark.png
diff --git a/docs/basics/scenemanagement/images/SwitchingToNewScene_Light.png b/docs/basics/scenemanagement/images/SwitchingToNewScene_Light.png
diff --git a/docs/basics/scenemanagement/images/UnloadingAdditiveScene.png b/docs/basics/scenemanagement/images/UnloadingAdditiveScene.png
diff --git a/docs/basics/scenemanagement/images/UnloadingAdditiveScene_Dark.png b/docs/basics/scenemanagement/images/UnloadingAdditiveScene_Dark.png
diff --git a/docs/basics/scenemanagement/images/UnloadingAdditiveScene_Light.png b/docs/basics/scenemanagement/images/UnloadingAdditiveScene_Light.png
diff --git a/docs/basics/scenemanagement/images/UnloadingSceneTimeline.png b/docs/basics/scenemanagement/images/UnloadingSceneTimeline.png
diff --git a/docs/basics/scenemanagement/images/UnloadingSceneTimeline_Dark.png b/docs/basics/scenemanagement/images/UnloadingSceneTimeline_Dark.png
diff --git a/docs/basics/scenemanagement/images/UnloadingSceneTimeline_Light.png b/docs/basics/scenemanagement/images/UnloadingSceneTimeline_Light.png
diff --git a/docs/basics/scenemanagement/timing-considerations.md b/docs/basics/scenemanagement/timing-considerations.md
@@ -18,7 +18,11 @@ In each diagram, you will see two types of black arrows:
 
 ## Client Synchronization:
 The below diagram, Client Synchronization Updates, steps you through the entire client synchronization process from starting the client all the way to the client being fully synchronized and connected.  
-![image](images/ClientSyncUpdates.png)<br/>
+<figure>
+<ImageSwitcher 
+lightImageSrc="images/ClientSyncUpdates_Light.png?text=LightMode"
+darkImageSrc="images/ClientSyncUpdates_Dark.png?text=DarkMode"/>
+</figure>
 Above, we can see that the client will first send a connection request to the server that will process the request, handle the approval process via ConnectionApprovalCallback (if connection approval is enabled), and if approved the server will:
 - Send a connection approved message back to the client
     - This only means the connection is approved, but the client is not yet synchronized.
@@ -45,7 +49,11 @@ Take note that after the client finishes processing the synchronization event, t
 
 ### Client-Side Synchronization Timeline
 Now that we have covered the high-level synchronization process, we can dive a little deeper into what happens on the client side as it processes the synchronize message.  The below sub-diagram, "Scene Event Synchronization Timeline", provides you with a more detailed view of how the client processes the synchronize message:
-![image](images/SceneEventSynchronizationTimeline.png)
+<figure>
+<ImageSwitcher 
+lightImageSrc="images/SceneEventSynchronizationTimeline_Light.png?text=LightMode"
+darkImageSrc="images/SceneEventSynchronizationTimeline_Dark.png?text=DarkMode"/>
+</figure>
 You can see that upon receiving the message, the client appears to be iterating over portions of the data included in the synchronize message.  This is primarily the asynchronous scene loading phase of the client synchronization process. This means the more scenes loaded, the more a client will be required to load which means the Client Synchronization Period is directly proportional to the number of scene being loaded and the size of each scene being loaded.  Once all scenes are loaded, the client will then locally spawn all `NetworkObject`s.  As a final step, the client sends the list of all `NetworkObjectId`s it spawned as part of its `SceneEventType.SynchronizeComplete` scene event message so the server can determine if it needs to resynchronize the client with a list of any `NetworkObjects` that might have despawned during the Client Synchronization Period.
 
 ## Loading Scenes
@@ -54,9 +62,11 @@ You can see that upon receiving the message, the client appears to be iterating
 Looking at the timeline diagram below, "Loading an Additive Scene", we can see that it includes a server, two clients, and that the server will always precede all clients when it comes to processing the scene loading event. The big-picture this diagram is conveying is that only when the server has finished loading the scene and spawning any in-scene placed `NetworkObject`s, instantiated by the newly loaded scene, will it send the scene loading event message to the clients. 
 
 Another point of interest in the below diagram is how Client 1 receives the scene loading event, processes it, and then responds with a `SceneEventType.LoadComplete` scene event message before client 2. This delta between client 1 and client 2 represents the varying client-server latencies and further enforces the underlying concept behind the `SceneEventType.LoadEventCompleted` message.  Once a server has received all `SceneEventType.LoadComplete` messages from the connected clients, it will then broadcast the `SceneEventType.LoadEventCompleted` message to all connected clients.  At this point, we can consider the scene loading event (truly) complete and all connected clients are able to receive and process netcode messages.
-
-![image](images/LoadingAdditiveScene.png)
-
+<figure>
+<ImageSwitcher 
+lightImageSrc="images/LoadingAdditiveScene_Light?text=LightMode"
+darkImageSrc="images/LoadingAdditiveScene_Dark?text=DarkMode"/>
+</figure>
 :::caution
 While a client can start sending the server messages (including NetworkVariable changes) upon local `SceneEventType.LoadComplete` event notifications, under more controlled testing environments where the network being used has very little to no latency (i.e. using loopback with multiple instances running on the same system or using your LAN), this approach will not expose latency related issues. Even though the timing might "work out" under controlled low latency conditions you could still run into edge case scenarios where if a client approaches or exceeds a 500ms RTT latency you could potentially run into issues.
 :::
@@ -86,15 +96,24 @@ How you load scenes is really up to your project/design requirements.
     - Any scenes loaded by `NetworkSceneManager`, prior to scene switching, will be unloaded and any `NetworkObject` that has the `DestroyWithScene` set to `true` will be destroyed.
         - If `DestroyWithScene` is set to `false` it will be "preserved" (_see the sub-diagram "Load New Scene Timeline" below_)
 
-![image](images/SwitchingToNewSceneLight.png)
+<figure>
+<ImageSwitcher 
+lightImageSrc="images/SwitchingToNewScene_Light?text=LightMode"
+darkImageSrc="images/SwitchingToNewScene_Dark?text=DarkMode"/>
+</figure>
 
 ## Load New Scene Timeline (Sub-Diagram)
 Both scene loading diagrams (Additive and Single) refer to the below sub-diagram that provides additional details of the scene loading process.
 :::important
 When looking at the below sub-diagram, both single and additive scene loading modes use close to the exact same flow with the exception that additively loaded scenes only flow through the four middle steps that are grouped together by the light red filled region highlighted by red dashed lines.  When loading a scene additively, no other scenes are unloaded nor are any NetworkObjects moved into the DDoL temporarily. This setting, by default, is true for dynamically spawned `NetworkObject`s unless otherwise specified when using `NetworkObject.Spawn`, `NetworkObject.SpawnWithOwnership`, or `NetworkObject.SpawnAsPlayerObject`.  In-scene placed `NetworkObject`'s, by default, will be destroyed with the scene that instantiated them.  At any point, within a `NetworkBehaviour` you can change the `NetworkObject.DestroyWithScene` property.
 :::
 
-![image](images/LoadNewSceneTimeline.png)
+<figure>
+<ImageSwitcher 
+lightImageSrc="images/LoadNewSceneTimeline_Light?text=LightMode"
+darkImageSrc="images/LoadNewSceneTimeline_Dark?text=DarkMode"/>
+</figure>
+
 **Load New Scene Additively**
 1. Starts loading the scene
 2. During the scene loading process, in-scene placed `NetworkObject`s are instantiated and their `Awake` and then `Start` methods are invoked (in that order).
@@ -119,7 +138,11 @@ Primarily, this applies to unloading additively loaded scenes via th `NetworkSce
 ### Unloading an Additive Scene
 If you look at the below diagram, "Unloading an Additive Scene", you will see a very similar flow as that of loading a scene.  The server still initiates the `SceneEventType.Unload` scene event and will not send this message to clients until it has completed the `Unload` scene event locally.
 
-![image](images/UnloadingAdditiveScene.png)<br/>
+<figure>
+<ImageSwitcher 
+lightImageSrc="images/UnloadingAdditiveScene_Light?text=LightMode"
+darkImageSrc="images/UnloadingAdditiveScene_Dark?text=DarkMode"/>
+</figure>
 
 ### Unloading Scenes Timeline:
 Review over the below diagram and take note of the following things:
@@ -131,4 +154,8 @@ Review over the below diagram and take note of the following things:
     - While a server is unloading a scene, the client could begin to receive a bunch of despawn messages for the `NetworkObject`s being destroyed on the server-side while the scene is being unloaded.
         - By the time a client receives the `SceneEventType.Unload` scene event message, it very well could have no remaining `NetworkObject`s in the scene being unloaded.  This will not impact the client-side scene unloading process, but it is useful to know that this will happen.
 
-![image](images/UnloadingSceneTimeline.png)
+<figure>
+<ImageSwitcher 
+lightImageSrc="images/UnloadingSceneTimeline_Light?text=LightMode"
+darkImageSrc="images/UnloadingSceneTimeline_Dark?text=DarkMode"/>
+</figure>
diff --git a/...sequence_diagrams/BossRoomExamples/HidingLatency_AnimationAnticipation_Dark.png b/...sequence_diagrams/BossRoomExamples/HidingLatency_AnimationAnticipation_Dark.png
diff --git a/...img/sequence_diagrams/BossRoomExamples/RPCFlowExample_ArcherRangedShot_Dark.png b/...img/sequence_diagrams/BossRoomExamples/RPCFlowExample_ArcherRangedShot_Dark.png
diff --git a/static/img/sequence_diagrams/BossRoomExamples/RPCFlowExample_ArcherVolley_Dark.png b/static/img/sequence_diagrams/BossRoomExamples/RPCFlowExample_ArcherVolley_Dark.png
diff --git a/...ic/img/sequence_diagrams/BossRoomExamples/RPCFlowExample_MageMagicBolt_Dark.png b/...ic/img/sequence_diagrams/BossRoomExamples/RPCFlowExample_MageMagicBolt_Dark.png
diff --git a/static/img/sequence_diagrams/BossRoomExamples/RPCFlowExample_PlayerEmote_Dark.png b/static/img/sequence_diagrams/BossRoomExamples/RPCFlowExample_PlayerEmote_Dark.png
diff --git a/static/img/sequence_diagrams/BossRoomExamples/RPCFlowExample_RogueSneak_Dark.png b/static/img/sequence_diagrams/BossRoomExamples/RPCFlowExample_RogueSneak_Dark.png
diff --git a/static/img/sequence_diagrams/NetworkVariable/NetVarDataUpdates_Dark.png b/static/img/sequence_diagrams/NetworkVariable/NetVarDataUpdates_Dark.png
diff --git a/static/img/sequence_diagrams/NetworkVariable/NetworkVariables_Dark.png b/static/img/sequence_diagrams/NetworkVariable/NetworkVariables_Dark.png
diff --git a/.../img/sequence_diagrams/NetworkVariable/NetworkVariables_LateJoinClient_Dark.png b/.../img/sequence_diagrams/NetworkVariable/NetworkVariables_LateJoinClient_Dark.png
diff --git a/...ic/img/sequence_diagrams/NetworkVariableVSRPCs/ManagingNetVarData_RPCs_Dark.png b/...ic/img/sequence_diagrams/NetworkVariableVSRPCs/ManagingNetVarData_RPCs_Dark.png
diff --git a/static/img/sequence_diagrams/NetworkVariableVSRPCs/RPCsLateJoin_Dark.png b/static/img/sequence_diagrams/NetworkVariableVSRPCs/RPCsLateJoin_Dark.png
diff --git a/static/img/sequence_diagrams/RPCs/ClientRPCs_CertainClients_Dark.png b/static/img/sequence_diagrams/RPCs/ClientRPCs_CertainClients_Dark.png
diff --git a/...c/img/sequence_diagrams/RPCs/ClientRPCs_ClientHosts_CalledByClientHost_Dark.png b/...c/img/sequence_diagrams/RPCs/ClientRPCs_ClientHosts_CalledByClientHost_Dark.png
diff --git a/static/img/sequence_diagrams/RPCs/ClientRPCs_Dark .png b/static/img/sequence_diagrams/RPCs/ClientRPCs_Dark .png
diff --git a/static/img/sequence_diagrams/RPCs/ClientRPCs_Dark.png b/static/img/sequence_diagrams/RPCs/ClientRPCs_Dark.png
diff --git a/...c/img/sequence_diagrams/RPCs/ServerRPCs_ClientHosts_CalledByClientHost_Dark.png b/...c/img/sequence_diagrams/RPCs/ServerRPCs_ClientHosts_CalledByClientHost_Dark.png
diff --git a/static/img/sequence_diagrams/RPCs/ServerRPCs_ClientHosts_CalledByClient_Dark.png b/static/img/sequence_diagrams/RPCs/ServerRPCs_ClientHosts_CalledByClient_Dark.png
diff --git a/static/img/sequence_diagrams/RPCs/ServerRPCs_Dark.png b/static/img/sequence_diagrams/RPCs/ServerRPCs_Dark.png
diff --git a/...ams/dealing_with_latency/Example_CaptureFlagPart1_ClientAuthorityIssue_Dark.png b/...ams/dealing_with_latency/Example_CaptureFlagPart1_ClientAuthorityIssue_Dark.png
diff --git a/...grams/dealing_with_latency/Example_CaptureFlagPart2_ServerAuthorityFix_Dark.png b/...grams/dealing_with_latency/Example_CaptureFlagPart2_ServerAuthorityFix_Dark.png
diff --git a/...sequence_diagrams/dealing_with_latency/Example_CharPos_ClientAuthority_Dark.png b/...sequence_diagrams/dealing_with_latency/Example_CharPos_ClientAuthority_Dark.png
diff --git a/...sequence_diagrams/dealing_with_latency/Example_CharPos_ServerAuthority_Dark.png b/...sequence_diagrams/dealing_with_latency/Example_CharPos_ServerAuthority_Dark.png