Program Adaptation Requirements

# LarkSR Deployment Architecture & System Requirements

LarkSR supports four deployment modalities designed to optimize cloud rendering performance and resource utilization.

---

## 1. Core Operating Modes

### 1.1 SR: 3D Shared Mode (Parallel Cloud Solution)
This mode is strictly optimized for pure 3D simulation applications. It enables a single server to host and run multiple application instances concurrently, maximizing hardware efficiency.

### 1.2 SR: 2D Shared Mode (Parallel Cloud Solution)
Designed for hybrid applications containing both 2D and 3D elements, this mode accommodates multi-instance requirements for 2D-dependent software. While instance concurrency is lower compared to 3D Shared Mode, it serves as a viable alternative to Exclusive Mode in numerous deployment scenarios.

* **Supported Features:** Pre-launch functionality, audio output, dedicated data channels, and interactive mode.
* **Unsupported Features:** Client-side resolution adjustment and peripheral device pass-through (e.g., microphones, cameras).

> **⚠️ Critical Operations & Security Notes (2D Shared Mode)**
> 
> 1. **User Directories:** The system automatically generates local users; residual user directory artifacts may persist post-session.
> 2. **Naming Conventions:** Standard system usernames must not use the prefix `_LARKXR_`.
> 3. **RDP Dependencies:** Remote Desktop Protocol (RDP) services are required. For enhanced security, it is highly recommended to modify the default RDP port.
> 4. **Security Hardening:** In environments with strict security audits, 2D Shared Mode can be fully disabled by adding this property to the management node configuration file:  
>    `pxy.render-server.remote-desktop.enable=false`
> 5. **Network Overhead:** Each active 2D shared connection consumes local server bandwidth, though the overall performance impact is minimal.
> 6. **Initialization Time:** Application launch times are marginally longer compared to 3D Shared Mode.
> 7. **Multi-GPU Orchestration:** Resource scheduling for single-machine, multi-card configurations relies on the native operating system's polling allocation across available GPU hardware.

### 1.3 SR: Exclusive Mode
This mode is recommended for applications that require local installation, rely heavily on persistent user directories, present cross-user permission conflicts, or demand multi-screen configurations.

In this mode, a server is dedicated to hosting a single simulation application instance.

> **🔄 Version Compatibility Note**
> 
> As of Version V3.3.3.0, Exclusive Mode is disabled by default. To manually enable this feature, add the following configuration property to `larkxr-center/application.properties`:  
> `pxy.dispatch-policy.enable-exclude-mode=true`

---

## 2. Technical Requirements for 3D Shared Mode

To ensure optimal performance and stability within 3D Shared Mode, applications must adhere to the following architectural guidelines:

### 2.1 Engine Compatibility
Supported graphics frameworks and engines include: Unreal Engine, Unity3D, DirectX 9/10/11/12, OpenGL, Enscape, and related runtimes.

### 2.2 Windowing & Resolution Best Practices
* Applications should be configured to initialize at the target rendering resolution intended for the end-user experience.
* Applications must execute in **Maximized Windowed Mode**. Do **not** deploy applications in Full-Screen Exclusive Mode.
    * **Impact:** Full-screen exclusive mode restricts the host server to a single application instance. Furthermore, if the application resolution mismatches the host OS, it will force-change the server's native display resolution.
    * **Unity Configuration Hazard:** When configuring a Unity build, ensure the option highlighted in the reference image below remains **unchecked** to avoid server resolution conflicts:

### 2.3 Process & Architecture Constraints
The application must function as a pure 3D, single-process entity. Please account for the following development constraints:
* **Single-Process Windows:** Only single-process window architectures (such as native Unreal Engine or Unity3D builds) are supported.
* **OS Pop-ups:** Native OS dialog boxes and window pop-ups are unsupported. All user interface prompts must be rendered graphically within the main application canvas.
* **QT/OpenGL Integration:** If utilizing QT for OpenGL program development, replace standard QT controls with `OpenGL/Widget` to ensure unified canvas rendering. Standard QT controls will fail to be captured by the stream.
* **External API Calls:** Applications must not invoke external document viewers (e.g., opening Word, PDF, or Excel files via system APIs).

### 2.4 Unreal Engine Deployment Guide
When specifying the executable path during application upload, **do not** target the root directory stub executable. Instead, map the path directly to the compiled binaries directory:

> **Target Path Structure:** > `[Project Root] -> [Project Name] -> Binaries -> Win64 -> [ProjectName].exe`

* **Startup Parameters:** If the application requires specific launch arguments, input them directly into the background startup parameter configuration field.
* **Technical Reference:** For detailed implementation steps, consult the [Paraverse Documentation](https://www.pingxingyun.com/contribute/detail?topicId=10107&categoryId=3).