Cross-process 3D effect rendering method and system

Abstract

The invention provides a cross-process 3D effect rendering method and system, and belongs to the technical field of computer graphic processing and cross-process communication. According to the method, after a client is started, a 3D library is initialized, a 3D view matched with a server is created, and the process state of the server is detected and is actively pulled up when the client is not started; connection is established through the binding port, a remote communication interface is obtained, an encrypted data transmission link is established after two-way communication interface registration is completed, then rendering service data is sent, and a rendering result returned by the server side is received. According to the scheme, by means of the centralized server rendering architecture, only one set of 3D engine is used, and memory occupation is remarkably reduced; the unified communication access mode simplifies the client integration process; and bidirectional encryption communication is supported, so that data security and interaction flexibility are improved. According to the scheme, the problems that traditional multi-process rendering is high in memory, non-uniform in interface and complex in communication are effectively solved.

Description

Technical Field

[0001] This invention relates to the fields of computer graphics processing and cross-process communication technology, specifically to a cross-process 3D effect rendering method and system. Background Technology

[0002] With the widespread application of mobile devices and smart terminals in multimedia, gaming, AR / VR, and other fields, 3D visual effects have become an important means of enhancing user experience. Traditional 3D rendering often uses independent local processes, where each application that needs to display 3D content loads its own 3D rendering engine and executes rendering tasks. In this mode, when multiple applications run simultaneously, each launches an independent 3D rendering instance, leading to a significant increase in system resources, especially memory consumption. Furthermore, the 3D rendering implementations across different applications are inconsistent, with fragmented interfaces, high maintenance costs, and cross-process communication typically only supports one-way calls, resulting in poor flexibility.

[0003] Current technologies lack a centralized, standardized 3D rendering architecture to address these issues. Especially in multi-process environments, repeated 3D rendering engine startup by different clients wastes memory; inconsistent rendering methods increase development and modification costs; and complex cross-process communication mechanisms, mostly supporting only one-way requests from client to server, fail to meet bidirectional interaction requirements. These problems severely restrict the efficient integration and large-scale deployment of 3D functionality. Summary of the Invention

[0004] To overcome the shortcomings of the prior art, this application provides a cross-process 3D effect rendering method and system, which can effectively solve the technical problems of high memory consumption, inconsistent calling methods, and complex and mostly unidirectional communication mechanisms in the prior art.

[0005] To achieve the above objectives, this application provides the following technical solution:

[0006] A first aspect of the present invention provides a cross-process 3D effect rendering method, the method comprising:

[0007] After the client starts, it performs initialization operations, loads and verifies 3D-related libraries, and creates a 3D view adapted for server-side rendering after the verification is successful.

[0008] Based on the 3D view, an operation request is sent to the server, and the server process status is detected. If the server is not started, the server process is started.

[0009] By establishing a binding with the server through the binding port opened by the server, the remote communication interface generated by the server can be obtained;

[0010] The client sends a communication interface registration request to the server through the remote communication interface. After the server verifies the registration, the client completes the registration and synchronously obtains the 3D view communication identifier fed back by the server.

[0011] An encrypted data transmission link is established with the server based on the registered communication interface. Rendering business data is sent to the server through the link, and the rendering results are received back from the server.

[0012] Optionally, the step of creating a 3D view adapted for server-side rendering after successful verification includes: traversing the local 3D-related library storage path by calling a preset initialization mechanism, loading all 3D-related library files, and verifying the compatibility of the library file version with the client system and the file integrity one by one; after all library files have passed verification, completing the initialization of the 3D-related libraries, calling the view creation tool to generate a 3D view containing server-side rendering adaptation parameters, verifying the communicability attributes of the 3D view, and obtaining a 3D view adapted for server-side rendering if the verification is correct.

[0013] Optionally, loading all 3D-related library files further includes: if a library file is detected to be missing or corrupted during the loading process, downloading the corresponding missing or corrupted library file from a preset resource server, and re-executing the 3D-related library loading and verification operation after the replacement is completed, until the verification passes.

[0014] Optionally, the detection of the server process status includes: after sending an operation request to the server, calling the process status query interface to detect in real time whether the server process PID exists; if the PID exists, it is determined that the server process has started, the process detection is stopped and the next step is entered; if the PID does not exist, it is determined that the server process has not started, a server process start command is generated, the process startup program under the server installation path is triggered, the server process is started and the PID generation status is continuously detected until the PID exists.

[0015] Optionally, the step of establishing a binding with the server through the binding port opened by the server and obtaining the remote communication interface generated by the server includes:

[0016] After the server process starts, the foreground service is started automatically. The foreground service is configured to run at a certain priority and a fixed bound port is opened. At the same time, port access permissions are set so that only authorized devices are allowed to access the server.

[0017] The client obtains the binding port opened by the server, generates a binding request containing its own device identifier, and sends it to the server through the port. After receiving the binding request, the server verifies the matching of the device identifier with the preset authorized device list. If they match, the server completes the binding with the client according to the preset binding protocol. After successful binding, the server generates a remote communication interface and sends it back to the client. After receiving the remote communication interface, the client completes the acquisition of the remote communication interface.

[0018] Optionally, the method further includes: after the client initiates a binding request, setting a response timeout threshold and a retry interval; if no binding response is received from the server or a binding failure feedback is received after the timeout, and the number of retries has not reached the preset limit, the binding request is resent at the retry interval until the binding is successful or the number of retries reaches the limit; if the binding still fails after the number of retries reaches the limit, a binding error message is output to the client.

[0019] Optionally, the step of sending a communication interface registration request to the server via a remote communication interface and completing the registration after the server verifies the request includes: when the server receives the communication interface registration request, it extracts the communication interface protocol type, transmission specification, and data compatibility format parameters carried in the request, compares them with its own preset communication adaptation standard, and determines that the verification is successful when the parameters match completely, completes the client communication interface registration, generates a 3D view communication identifier and feeds it back to the client.

[0020] After receiving the 3D view communication identifier, the client verifies the validity of the identifier. If the verification passes, the interface registration is confirmed to be complete.

[0021] Optionally, the establishment of an encrypted data transmission link between the registered communication interface and the server, and the sending of rendering business data to the server through the link and the receiving of rendering results from the server, includes: the client and the server negotiating a temporary encrypted transmission key based on the registered communication interface, and establishing a two-way encrypted data transmission link after the key negotiation is successful.

[0022] Analyze 3D rendering business requirements and extract rendering business data; wherein, the rendering business data includes: rendering scene, model parameters, and effect parameters;

[0023] The rendering service data is encapsulated according to the link adaptation format and sent to the server through the encrypted data transmission link. The server also receives encrypted data back through the encrypted data transmission link.

[0024] By decrypting the returned encrypted data, the server obtains the rendering result of rendering and integrating the decrypted rendering business data based on its own 3D rendering engine. The rendering result includes the result verification identifier corresponding to the rendering result.

[0025] After receiving the data, the client verifies the verification result and identifier. If the verification passes, the client confirms the validity of the rendering result and accepts it. If the verification fails, the client sends a retransmission request for the rendering result to the server.

[0026] Optionally, the step of encapsulating the rendering business data according to the link adaptation format includes: calling a preset data encapsulation method to define data fields in JSON format, filling in the rendering business data and adding a data verification code to complete the data encapsulation.

[0027] A second aspect of the present invention provides a cross-process 3D effect rendering system, the system comprising:

[0028] The view creation module is used to perform initialization operations after the client starts, load and verify 3D related libraries, and create a 3D view adapted to server-side rendering after the verification is passed;

[0029] The process status detection module is used to send operation requests to the server based on the 3D view and detect the server process status. If the server is not started, the server process will be started.

[0030] The binding module is used to establish a binding with the server through the binding port opened by the server and obtain the remote communication interface generated by the server.

[0031] The interface registration module is used to send a communication interface registration request to the server through the remote communication interface. After the server verifies the registration, the client will complete the registration and synchronously obtain the 3D view communication identifier fed back by the server.

[0032] The rendering data transmission module is used to establish an encrypted data transmission link with the server based on the registered communication interface, send rendering business data to the server through the link, and receive the rendering results returned by the server.

[0033] Compared with the prior art, the advantages of the present invention are as follows:

[0034] This application provides a cross-process 3D rendering method and system. By centralizing 3D rendering on the server side and using only one 3D rendering engine, it avoids memory waste caused by repeated loading of multiple processes and solves the problem of high memory consumption under multi-process conditions. Through standardized initialization, binding, registration, and communication processes, it unifies the client access method and reduces development and maintenance costs. By establishing a two-way encrypted communication link, it supports secure and reliable data interaction, improving the system's security and stability. Therefore, this method achieves low memory consumption, high security, and easy scalability for cross-process 3D rendering. Attached Figure Description

[0035] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the accompanying drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. In all the drawings, similar elements or parts are generally identified by similar reference numerals. In the drawings, the elements or parts are not necessarily drawn to scale.

[0036] Figure 1 This is a flowchart of a cross-process 3D effect rendering method provided by the present invention;

[0037] Figure 2This is a schematic diagram of the structure of a cross-process 3D effect rendering system provided by the present invention;

[0038] Figure 3 This is an internal structural diagram of the electronic device provided by the present invention. Detailed Implementation

[0039] The present invention will now be described in further detail with reference to embodiments. It is to be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit the invention.

[0040] This invention provides a cross-process 3D effect rendering method and system, aiming to solve the following problems existing in multi-process 3D effect rendering:

[0041] In traditional implementations, multiple applications or modules independently launch their 3D rendering engines, leading to a significant increase in overall system memory usage. Different processes employ differentiated 3D rendering APIs and communication mechanisms, resulting in high development, maintenance, and upgrade costs. Furthermore, the cross-process communication architecture is complex, with most solutions only supporting one-way data transmission from client to server, lacking bidirectional interaction capabilities and limiting the application scenarios for dynamic rendering control and real-time feedback. These issues make it difficult for existing technologies to meet the demands of high-performance cross-platform 3D rendering in terms of resource utilization, system maintainability, and communication flexibility.

[0042] Example 1: Based on this, Example 1 provides a cross-process 3D effect rendering method. Specifically, it is a technical solution that centrally deploys the 3D rendering function in an independent server process, with the client initiating and coordinating the entire rendering process, and both parties completing data exchange and state synchronization through a standardized and secure communication mechanism.

[0043] This method is applicable to 3D graphics processing scenarios in mobile terminals, embedded devices, or multi-process collaborative systems, and is particularly suitable for application environments that require reduced memory overhead, unified access standards, and guaranteed communication security. In this architecture, the client does not directly perform 3D rendering calculations, but instead acts as the business logic entry point, responsible for initialization, request scheduling, and result display. The server, on the other hand, is dedicated to executing complex 3D rendering tasks, thereby achieving separation of responsibilities and resource optimization.

[0044] like Figure 1 As shown, the specific steps include:

[0045] Step S101: After the client starts, it performs initialization operations, loads and verifies 3D-related libraries, and creates a 3D view adapted to server-side rendering after the verification is passed;

[0046] The initialization process performed after client startup refers to the proactive triggering of the 3D rendering module's preparation process after the client application (such as an Android app or desktop client) completes its basic lifecycle initialization (such as the Application onCreate phase). Loading and verifying 3D-related libraries involves reading the core dynamic link library files (such as OpenGL ES, Vulkan, Unity Engine Runtime, etc.) supporting 3D functionality from local storage and ensuring their availability through integrity verification algorithms (such as SHA-256 hash comparison) and version compatibility checks. 3D-related libraries include, but are not limited to, graphics driver interface libraries, shader compilers, texture management components, and physical simulation engine dependencies.

[0047] Furthermore, if any library file is detected to be missing or fails verification during the loading process, the corresponding file is automatically downloaded from a preset secure resource server for completion, and the loading and verification process is re-executed until all necessary libraries are successfully loaded. This process can be executed asynchronously in the background to avoid blocking the main thread and improving the user experience.

[0048] Creating a 3D view adapted for server-side rendering involves calling view construction tools (such as GLSurfaceView, SurfaceTexture, or a custom ViewGroup) after the 3D-related libraries are initialized to generate a virtual 3D display container with remote rendering adaptation capabilities. This 3D view encapsulates metadata parameters necessary for communication with the server, such as rendering resolution preferences, frame rate strategies, anti-aliasing levels, and whether HDR is enabled. Furthermore, this view has a self-diagnostic mechanism that can make a preliminary judgment on its ability to establish communication with the server (such as network permissions and Binder communication channel availability) to ensure the smooth progress of subsequent binding processes.

[0049] The initialization and view creation processes described above work together: 3D views are only allowed to be created when the underlying library is stable and reliable, and the created views provide the structural foundation for subsequent binding and communication with the server. Together, they constitute the prerequisite for the client to participate in cross-process rendering.

[0050] Through the above steps, this application achieves the trusted construction of the runtime environment and the preparation of the visualization carrier on the client side, solves the problem of initialization failure caused by missing local dependencies or version mismatch, and improves the robustness and automation level of the system.

[0051] Step S102: Send an operation request to the server based on the 3D view and check the server process status. If the server is not started, start the server process.

[0052] Sending an operation request to the server based on a 3D view means using an existing 3D view instance as the starting point to construct a lightweight probing command (such as PING or GET_STATUS). This command attempts to establish a connection with the target server through inter-process communication mechanisms provided by the operating system (such as Android Binder, Socket Local communication, or D-Bus). This request does not carry actual rendered data; its primary purpose is to trigger server response behavior and determine its liveness status.

[0053] The server process status is detected by calling a system-level API to query whether the server process's PID (Process ID) exists. If a valid PID is returned, the server is considered to be running; otherwise, it is considered not started. In some embodiments, server activity can also be indirectly determined by listening to whether a specific port is in a LISTEN state.

[0054] When the server is determined not to be running, starting the server process involves activating the server application via Intent (Android), executing an executable file path (Linux / Windows), or calling the Package Manager API. This process is usually accompanied by a foreground service declaration to prevent termination by the system's low-memory reclamation mechanism. After the server is successfully started, it will enter the initialization process to prepare for receiving client bindings.

[0055] In this step, sending operation requests and process status detection form a closed-loop judgment logic, which, combined with conditional branch decision-making, realizes an automatic wake-up mechanism, enabling the client to seamlessly connect without prior knowledge of the server's running status, thus improving ease of use.

[0056] Through the above steps, this embodiment achieves intelligent perception and adaptive wake-up of the server's running status, solving the problems of manual service startup or frequent connection failures in traditional methods, and enhancing the automation and stability of cross-process collaboration.

[0057] Step S103: Establish a binding with the server through the binding port opened by the server and obtain the remote communication interface generated by the server;

[0058] The server-side open binding port refers to a communication access point actively exposed by the server during startup. This can be a TCP / IP local loopback port (such as localhost:8080), a Unix Domain Socket path, or the Binder node corresponding to the Android AIDL interface. This port has access control policies, allowing only trusted devices or applications (such as those matching package name signatures) to access it, preventing unauthorized connections.

[0059] Establishing a binding involves the client initiating a connection handshake through this port, submitting identity credentials including its own device identifier (such as DeviceID, Client Token, or certificate fingerprint). After the server verifies the credentials, it completes bidirectional channel negotiation according to a preset protocol (such as gRPC, HTTP+JSON, or a custom binary protocol). In the Android system, this process is often manifested as a bindService() call in conjunction with a ServiceConnection callback.

[0060] Obtaining the remote communication interface generated by the server means that after successful binding, the server dynamically creates an object reference (such as IRemoteInterface.Stub Proxy, WebSocket Client Handle, or RPC Client Stub) that can be used for subsequent message sending and receiving, and passes it to the client. This interface abstracts the underlying communication details, allowing the client to interact with it through standard method calls.

[0061] In one optional embodiment, the binding process supports a retry mechanism: the client sets a timeout threshold (e.g., 5 seconds) and a maximum number of retries. If no response is received within the specified time, the binding request is re-initiated at fixed intervals. After the upper limit is reached, an error message is reported to facilitate users in troubleshooting network or permission issues.

[0062] This step establishes a trusted connection bridge between the client and the server through port binding and interface distribution mechanisms, laying the foundation for subsequent registration and data transmission.

[0063] Through the above steps, this application achieves a secure and reliable cross-process connection establishment mechanism, solving the problems of unstable connections and susceptibility to interference in traditional communication, while improving system security through authorization verification.

[0064] Step S104: Send a communication interface registration request to the server through the remote communication interface. After the server verifies the request, the registration is completed. The client synchronously obtains the 3D view communication identifier fed back by the server.

[0065] In this context, registering a communication interface with the server via a remote communication interface means that the client registers its own callback interface, which it uses to receive messages from the server, with the server. For example, in the AIDL system, the client passes a Stub object that implements a specific callback interface; in the WebSocket scenario, it registers an event listener. This allows the server to proactively push messages to the client when rendering progress updates, error notifications, or interactive events occur.

[0066] Registration is completed after server-side verification. This means that the server verifies the legitimacy of the received client interface, including protocol type consistency (e.g., it must be IChatCallback v2.0), data serialization format compatibility (e.g., supporting Protobuf instead of JSON), and call permission authentication (e.g., token validity). Only when all verification items pass will the server add it to the list of active clients and mark it as "registered".

[0067] The 3D view communication identifier that the client synchronously obtains from the server refers to a unique identifier (such as Session ID, View Token, or UUID) generated by the server after successful registration and sent back to the client through the established link. This identifier indicates that the current 3D view has full communication capabilities and can be used for identity binding and context association in subsequent rendering requests.

[0068] In a variant embodiment, the identifier can be appended with a timestamp and an expiration date field, enabling the server to periodically clean up idle sessions and improve resource management efficiency.

[0069] This step achieves true full-duplex communication capability through a two-way interface registration mechanism, breaking the limitations of the traditional one-way call mode and enabling the server to actively influence the client's state.

[0070] Through the above steps, this application realizes the construction of bidirectional communication capability between the client and the server, solves the problem of single communication mode and inability to achieve real-time feedback in the prior art, and improves the real-time interaction and system response capability.

[0071] Step S105: The client and the server establish an encrypted data transmission link based on the registered communication interface. The client sends rendering business data to the server through this link and receives the rendering results returned by the server.

[0072] Establishing an encrypted data transmission link based on the registered communication interface refers to further negotiating a temporary session key using the bidirectional interface already registered in the previous steps, and constructing an end-to-end encrypted channel using standard encryption algorithms (such as AES-256-GCM, TLS 1.3). The key negotiation process can achieve forward confidentiality based on asymmetric algorithms such as ECDH (Elliptic Curve Diffie-Hellman), ensuring that even if the key is leaked long-term, it will not jeopardize historical communication content.

[0073] Sending rendering business data from the client to the server via this link refers to encapsulating and encrypting the 3D scene information to be rendered in a predefined format before transmission. Rendering business data includes at least: scene topology, model mesh data, material texture paths, lighting parameters, camera viewpoint, animation keyframes, and special effects instructions. The preferred data encapsulation format is JSON or Protocol Buffers, balancing readability and transmission efficiency.

[0074] Receiving the rendering results returned by the server means that after the server completes GPU-accelerated rendering, it encrypts and returns the output image frames (such as RGB bitmaps, YUV video streams) or vector graphics instruction sets, which are then decrypted by the client and displayed by the UI layer. In some embodiments, the rendering results may also include performance metrics (such as FPS, GPU load) or event logs for client-side monitoring and debugging.

[0075] To further ensure data integrity, a checksum (such as CRC32 or HMAC-SHA256) can be added to the data packet. The server verifies the data before parsing it, and the client performs the same verification on the returned result. If the verification fails, a retransmission mechanism is triggered.

[0076] This step enables the secure transmission of sensitive rendering data through an encrypted link, preventing man-in-the-middle attacks or data theft, and is particularly suitable for 3D applications involving copyrighted content or privacy information.

[0077] Through the above steps, an efficient and secure data interaction mechanism was achieved, solving the problems of high risk of data leakage and unreliable transmission in cross-process rendering, and ensuring the integrity and confidentiality of the rendered content.

[0078] Through the above steps, this application achieves a complete cross-process 3D rendering collaboration workflow: from client initialization, service discovery and wake-up, secure binding, two-way registration to encrypted data transmission, each step is interconnected and progressively builds upon the last. By centralizing 3D rendering in a single server-side process and using only one 3D rendering engine, the overall system memory footprint is significantly reduced; by encapsulating complex communication processes, external access methods are unified, lowering the technical barrier for other modules to integrate 3D functionality; two-way communication between both ends is supported, enhancing interactive flexibility; and end-to-end encryption ensures data security. Therefore, it achieves a comprehensive technical effect of reducing resource consumption, simplifying development and maintenance, and improving communication security and system stability.

[0079] Example 2: Based on the above examples, this example further provides: creating a 3D view adapted for server-side rendering includes: traversing the local 3D-related library storage path by calling a preset initialization mechanism, loading all 3D-related library files, verifying the library file version and client system compatibility and file integrity one by one; after all library files pass verification, the 3D-related library initialization is completed, the view creation tool is called to generate a 3D view containing server-side rendering adaptation parameters, the communicability attributes of the 3D view are verified, and if the verification is correct, a 3D view adapted for server-side rendering is obtained.

[0080] "Invoking the preset initialization mechanism" refers to triggering a predefined initialization process when the client starts and enters the 3D function module initialization phase. This mechanism can have its execution strategy specified by configuration files or code logic, such as through static code blocks, Provider components, or independent initialization services. Its purpose is to uniformly manage the loading and verification process of 3D-related resources, ensuring the consistency and reliability of environment preparation. This initialization mechanism can be activated during application cold starts or the first invocation of a specific function, avoiding resource waste caused by repeated loading. An optional implementation is to adopt a lazy initialization strategy, executing the complete verification process only before the user actually enters the 3D interactive interface, thereby improving startup efficiency.

[0081] "Traversing local 3D-related library storage paths" refers to the system recursively scanning dynamic link libraries (such as .so, .dll, .dylib, etc.) or other dependent components in a specified folder based on a pre-configured directory list. These storage paths can be the default installation paths (such as ` / libs / 3dengine / `) or custom paths remotely distributed from the configuration center. The traversal operation supports multiple file system formats (such as ext4, NTFS, APFS) and is compatible with path representation standards under different operating systems. To improve efficiency, multiple subdirectories can be read in parallel using multithreading during the traversal process, while recording the metadata of each library file (such as size, modification time, hash value) for subsequent verification.

[0082] "Load all 3D-related library files" means mapping the identified library files into the address space of the current process, typically done through a dynamic loading interface provided by the operating system. The loading order can be based on dependency topology, prioritizing basic runtime libraries (such as the OpenGL ES wrapper layer and mathematical operation libraries), followed by upper-level rendering engine modules (such as UnityPlayer and Unreal Core). Error codes (such as `ERROR_FILE_NOT_FOUND` and `ERROR_INVALID_IMAGE_HASH`) are logged when loading fails for subsequent remedial processing.

[0083] "Verifying the compatibility of library file versions with client systems and the integrity of files one by one" includes checks in three dimensions:

[0084] First, version compatibility verification involves determining whether the minimum / maximum supported client version, CPU architecture (ARMv7, ARM64-v8a, x86_64), and operating system type (Android, iOS, Windows) of the library match the current runtime environment. This can be achieved by parsing the version field in the library's embedded Manifest file or dedicated header file. For example, if a 3D physics engine library declares that it only supports Android API Level ≥ 24 and an ARM64 architecture, then it should be considered incompatible when running on devices running Android 10 or below, or on x86 emulators.

[0085] Second, system compatibility verification is performed to assess the availability of the system capabilities the library depends on, such as GPU driver version, OpenGL ES support level, and Vulkan availability. This can be done by calling the EGL or GLES interface to query the current context capability set and comparing it with the capabilities required by the library. If critical extensions are missing, the library will not function correctly even if the files exist.

[0086] Thirdly, file integrity verification is crucial to prevent library files from becoming corrupted due to download interruptions, disk damage, or malicious tampering. Common methods include calculating SHA-256 or MD5 hash values ​​and comparing them with trusted benchmarks, or verifying digital signatures (such as using the RSA+PKCS#1 v1.5 signature scheme). Lightweight checksums (CRC32) can also be used as a rapid screening method. For update packages obtained from unofficial channels, it is recommended to use Public Key Infrastructure (PKI) for signature verification to ensure the source is trustworthy.

[0087] "Complete 3D-related library initialization after all library files pass verification" means that the functional interfaces of these libraries are only officially activated if all the aforementioned verifications are successful. The initialization process may include operations such as registering callback functions, allocating a global memory pool, setting log output levels, and binding graphics contexts. If any library fails verification, the entire initialization process is terminated, and a repair mechanism is initiated (such as the automatic reloading process described in Implementation 3). This design embodies the "all files must pass before it works" security principle, avoiding state chaos caused by partial loading.

[0088] The "view creation tool" in the phrase "calling the view creation tool to generate a 3D view containing server-side rendering adaptation parameters" refers broadly to software used to build 3D display containers, such as "SurfaceView" and "TextureView" on the Android platform, or "RenderWidgetHostView" in cross-platform frameworks. This tool receives a set of server-side rendering-related configuration parameters, such as the target rendering resolution, frame rate limit, color space (sRGB / Display P3), and whether remote texture sharing is enabled, and creates a 3D view instance with network collaboration capabilities accordingly. Adaptation parameters can be passed via JSON configuration files, Bundle parameters, or IDL interfaces to ensure that the client-side view structure remains consistent with the server-side rendering pipeline. The view itself does not directly perform rendering but acts as a proxy node for data exchange and state synchronization.

[0089] "Verifying the communicability attributes of a 3D view" refers to performing functional checks on whether the 3D view object possesses cross-process communication capabilities. Specifically, this includes verifying whether its internal Binder interface is correctly bound, whether the AIDL stub object is ready, whether event listeners are successfully registered, and whether the underlying Socket channel is in a pending connection state. Additionally, a lightweight heartbeat probe can be initiated to confirm its ability to respond to message broadcasts from the server. Only when all communication-related attributes are valid can the view be considered suitable for subsequent cross-process collaboration.

[0090] The various technical features are sequentially linked according to a logical chain: path discovery → file loading → multi-dimensional verification → environment initialization → view construction → communication verification, forming a closed-loop quality assurance process. The results of the preceding steps directly affect the execution of subsequent steps. For example, missing library files will prevent initialization from being completed, thus blocking view creation; while failure to verify view communication attributes indicates that although the view exists, it cannot participate in distributed rendering collaboration.

[0091] Through the above steps, this application achieves the following: Establishing a systematic local dependency verification and initialization mechanism before the client creates a 3D view for centralized server-side rendering. Because comprehensive version, compatibility, and integrity checks are performed on 3D-related library files, runtime crashes caused by missing libraries, version mismatches, or file corruption are resolved. Because library initialization and view creation only occur after all verifications pass, the stability of the client's runtime environment is improved. Because the generated 3D view carries the adaptation parameters required for server-side rendering and verifies communication capabilities, it ensures seamless integration into the cross-process rendering system, thereby enhancing the overall system's robustness and user experience consistency. This implementation is applicable to various mobile applications, cloud gaming clients, or AR / VR terminal devices requiring remote 3D rendering, and can also be extended to other cross-process collaborative scenarios that rely on complex local libraries.

[0092] Example 3: Based on the above examples, this example further provides:

[0093] If a missing or corrupted library file is detected during the loading of 3D related libraries, the corresponding missing or corrupted library file will be downloaded from the preset resource server. After the replacement is completed, the 3D related library loading and verification operation will be re-executed until the verification passes.

[0094] This technical solution is applicable to the initialization phase on the client side of a cross-process 3D rendering system. When the client starts and attempts to load locally stored 3D-related libraries, some library files may be missing or corrupted due to reasons such as initial device installation, system upgrade, accidental file deletion, or storage media failure. Such anomalies will interrupt subsequent view creation and server-side communication processes, affecting overall functionality availability. To address this issue, this embodiment introduces an automated remote resource recovery mechanism to ensure reliable initialization of the 3D rendering module.

[0095] During the loading of 3D-related libraries, the system performs integrity and availability checks on each library file to be loaded. Integrity checks include, but are not limited to, verifying file hash values ​​(such as MD5, SHA-256), verifying digital signatures, and checking the validity of the file header structure; availability checks include determining whether the file can be successfully mapped into memory by the dynamic linker and whether dependency symbols are fully resolved. If any library file is found to be missing or fails verification, an exception handling process is triggered.

[0096] At this point, the client actively connects to a pre-defined resource server—which can be deployed in the cloud or on a corporate intranet, offering high availability and bandwidth guarantees, and centrally hosting all versions of 3D-related library files. Based on the name, version number, and target platform information (such as operating system type and CPU architecture) of the required library file, the client constructs a standard HTTP / HTTPS or FTP request and initiates a download task to the resource server. The download process supports resume functionality and multi-threaded acceleration, improving recovery efficiency in weak network environments.

[0097] Downloaded library files are stored in the client's local temporary directory by default, and a secondary verification is performed immediately after writing to ensure that no data errors are introduced during the transmission process. After successful verification, the new file is copied or replaced to the original 3D library path, completing the "re-installation" operation. Subsequently, the system automatically restarts the entire 3D-related library loading and verification process, re-traversing all library files and verifying their status one by one. This process is a closed-loop control logic and will continue to execute until all library files have passed verification, or until the maximum number of retries (e.g., 3 times) is reached, at which point it switches to manual intervention mode.

[0098] In one alternative embodiment, the default resource server is deployed using a Content Delivery Network (CDN) architecture to achieve geographically distributed, rapid response and reduce download latency. In another variant, the resource server supports an incremental update mechanism, providing only differentiated patch packages instead of complete library files, thereby reducing data transmission volume and making it suitable for mobile devices or low-bandwidth scenarios.

[0099] In another embodiment, the client is configured with a local cache pool to store copies of successfully downloaded library files. When the same missing file is encountered again during the next initialization, it is preferentially retrieved from the cache to avoid repeated network requests and improve initialization speed. Furthermore, the caching strategy can be combined with the Least Recently Used (LRU) algorithm to manage storage space and prevent unlimited disk resource consumption.

[0100] Through the above steps, this application achieves the following: when an anomaly is detected in the local 3D-related library files, the system can automatically obtain the correct version from a remote trusted source and complete the repair, then re-enter the normal initialization process. Due to the introduction of dynamic reloading and cyclic verification mechanisms, the system possesses strong fault tolerance and self-healing capabilities, effectively solving the problem of functional unavailability caused by an incomplete initial environment. This improves the robustness and deployment convenience of the cross-process 3D rendering solution, making it particularly suitable for large-scale distribution, unattended operation, or remote terminal application scenarios.

[0101] Example 4:

[0102] Based on the above embodiments, this embodiment further provides: detecting the server process status includes: after sending an operation request to the server, calling the process status query interface to detect in real time whether the server process PID exists; if the PID exists, it is determined that the server process has started, stopping process detection and proceeding to the next step; if the PID does not exist, it is determined that the server process has not started, generating a server process start command, triggering the process startup program under the server installation path, starting the server process, and continuously detecting the PID generation status until the PID is detected.

[0103] Sending an operation request to the server signifies that the client actively initiates a communication attempt with the server during the initialization process. This operation request can be any form of data packet or control signal, used to trigger interaction with the server. Sending this operation request marks the first step in establishing a cross-process communication link for the client. Its purpose is not only to convey business intent but, more importantly, to serve as a prerequisite for starting subsequent process status detection mechanisms. For example, in the Android system environment, this operation request can be implemented through AIDL (Android Interface Definition Language) remote calls or Socket connection requests; in general Linux systems, it can be completed through local sockets (Unix Domain Sockets) or HTTP / HTTPS simulated requests. This step does not require the server to respond with specific content; it only needs to confirm whether it has the capability to respond or the necessary operational foundation.

[0104] The "process status query interface" in "real-time detection of server process PID existence via process status query interface" refers to the standard interface provided by the operating system for obtaining process running information. Taking Linux / Unix-like systems as an example, this interface corresponds to the process directory traversal mechanism in the proc filesystem, i.e., checking if the path / proc / [pid] exists to determine if the process corresponding to the specified PID is alive. In Windows systems, the process status can be determined by calling the OpenProcess() API in conjunction with GetExitCodeProcess(). The PID (Process Identifier) ​​is a unique integer number assigned by the operating system to each running process. The client pre-configures the expected PID range or fixed name of the server process and periodically polls for the existence of the target process using system commands (such as pidof, ps) or a programming interface. The detection frequency can be dynamically adjusted according to system load; for example, initially checking every 200ms, then reducing the frequency to 500ms after three consecutive failures to reduce resource consumption.

[0105] The statement "If a PID exists, the server process is considered to be running, process detection is stopped, and the process proceeds to the next step" indicates that when a valid PID is detected, the server is considered to be in a communicable state, requiring no further intervention, and the binding process is immediately initiated. This design avoids resource waste and potential conflicts caused by repeatedly launching processes. Multiple verification mechanisms can be introduced into the judgment logic, such as not only checking for the existence of the PID but also further reading its memory usage, CPU utilization, and other operational metrics to rule out false positives such as "zombie processes" or "stuck processes." Once the server is confirmed to be running normally, the client terminates the polling action, releases relevant thread resources, and executes the next step of establishing a binding connection.

[0106] The statement "If the PID does not exist, the server process is determined not to be running" indicates that the target server process is not currently running in the system environment, or it has crashed and exited. In this case, the client cannot directly enter the communication process; it must first ensure that the server is available. This determination triggers a subsequent automatic wake-up mechanism to ensure the continuity of the entire rendering process and a seamless user experience.

[0107] "Generate server process launch command" refers to constructing a system-level command that can start the server application. The content of this command depends on the target operating system and the server deployment method. For example, in an Android-based application architecture, this command can be encapsulated as an Intent object with a specific Action field and activate the service component; in a desktop Linux system, it might be a shell command used to start the server executable in the background. This launch command typically includes necessary startup parameters, such as log level, working directory, and network port configuration, to ensure the server runs in the correct mode.

[0108] "Triggering the process startup program under the server installation path" generally refers to the process management mechanism provided by the operating system kernel or middleware layer. The client does not directly create a new process, but instead delegates execution to the system through a standard interface, complying with the requirements of a security sandbox mechanism. For example, on the Android platform, services can be started indirectly; in POSIX systems, startup scripts can be executed through library functions. The "server installation path" is a pre-configured item on the client, typically stored in a configuration file or registry in the application's private directory. The startup program can be an executable binary file, a script file, or a daemon process manager.

[0109] The phrase "continuously monitoring the PID generation status after starting the server process until a PID is detected" reflects a closed-loop monitoring of the startup process. Since process startup involves multiple stages such as loading library files, initializing resources, and binding ports, there is a certain delay. Therefore, the client needs to continuously poll after issuing the start command until the target PID is successfully observed. This process is implemented in a non-blocking asynchronous manner to prevent the main thread from being frozen. To improve robustness, a maximum waiting time (e.g., 10 seconds) and a retry limit (e.g., 3 times) can be set. If the PID is not detected after the timeout, it is considered a startup failure, and the exception is handled by the upper-level logic. In addition, other auxiliary judgment methods, such as listening to whether local ports are open and checking whether shared memory segments have been created, can be combined as supplementary verification for PID detection.

[0110] The aforementioned technical steps are sequentially linked to form a complete control flow of "request triggering → status detection → conditional branching → on-demand wake-up → status re-checking". Among them, the process status query interface and the system process scheduling module together constitute the basic support for cross-platform process management; PID, as the core judgment criterion, realizes lightweight and efficient runtime status identification; and the continuous detection mechanism ensures a smooth and reliable transition from being pulled up to being usable.

[0111] Through the above steps, this application achieves automated perception and recovery of the server-side process's running status. Because the client can proactively detect the existence of the server-side process before communication and automatically trigger the startup process if it is missing, the communication interruption problem caused by the server not being pre-started is resolved. By continuously monitoring the PID generation status, it ensures that subsequent binding operations only continue after the server has truly entered the running state, improving the overall robustness of the system and the consistency of user experience. This mechanism enables the 3D rendering service to have the ability to "start on demand and start immediately when needed," making it suitable for resource-constrained scenarios such as mobile devices and embedded terminals, effectively reducing the operational and maintenance threshold and the complexity of user operation.

[0112] Example 5: Based on the above examples, this example further provides: after the server process starts, the foreground service is automatically started, the foreground service running priority is configured and a fixed binding port is opened, and port access permissions are set to allow only authorized devices to access; the client obtains the binding port opened by the server, generates a binding request containing its own device identifier, and sends it to the server through the port; after receiving the binding request, the server verifies the matching of the device identifier with the preset authorized device list. If the matching is successful, the server completes the binding with the client according to the preset binding protocol. After successful binding, a dedicated remote communication interface is generated and fed back to the client. After receiving the interface, the client completes the acquisition of the remote communication interface.

[0113] The automatic startup of a foreground service after the server process starts means that the server immediately creates a high-system-priority foreground service upon startup to prevent the operating system from reclaiming it when resources are scarce. In mobile operating systems like Android, this foreground service can continuously display its running status via the notification bar, ensuring its long-term resident status in memory. The running priority of the foreground service can be set to "START_STICKY" or a similar mechanism via system API calls, ensuring it continues to run even in low-memory environments. Furthermore, the foreground service can be configured with a heartbeat keep-alive mechanism to periodically execute lightweight tasks to maintain its active state, thereby improving the stability and availability of the server process.

[0114] In this context, "open fixed port binding" refers to the server initializing its network communication module during startup and binding a pre-defined, fixed TCP / UDP port number as the communication access point. This port is typically statically assigned, such as using non-system reserved ports like 8088 or 9000, facilitating unified client identification and connection. The fixed port design avoids the connection uncertainty caused by dynamic port allocation, improving the client's ability to discover the server. Furthermore, this port is only used for device authentication and interface negotiation during the initial binding phase and does not carry subsequent business data transmission, thus reducing the risk of long-term exposure.

[0115] Setting port access permissions to allow only authorized devices to access the server refers to deploying access control policies at the server's network or application layer to restrict the sources of access to the bound port. Specific implementation methods include, but are not limited to, IP whitelist filtering, device MAC address verification, digital certificate authentication, or pre-shared key (PSK) mechanisms. For example, in a Linux system, iptables rules can be used to restrict access to the port from specific IP ranges; at the application layer, an authorized device list can be built using unique device identifiers (such as IMEI, Android ID, UUID, etc.), allowing connections only when the device identifier of the requesting source exists in this list. This mechanism effectively prevents unauthorized devices from scanning and attempting to access the server, enhancing system security.

[0116] The client obtains the open binding port from the server through methods such as pre-configured default port values, LAN broadcast probing, mDNS (Multicast DNS) service discovery, or distribution from a remote configuration center. If the default port is used, the client can initiate a connection directly without an additional discovery process. If dynamic discovery is supported, probe messages can be sent via UDP broadcast, and the server responds with its IP address and port number information. After obtaining a valid port, the client constructs a binding request data packet containing its own device identifier. This identifier can be an encrypted, unique device code, ensuring traceability and making it difficult to forge.

[0117] Generating a binding request containing its own device identifier involves the client encapsulating locally stored device identity information into a structured message body, typically serialized using JSON or Protocol Buffers format. This request must include at least the following fields: device_id (unique device identifier), timestamp, version (protocol version number), and optional signature information for preventing replay attacks and verifying integrity. This request is sent to the specified binding port on the server via TCP or a security-enhanced TLS channel, triggering the server-side access authentication process.

[0118] The server-side process involves verifying the device identifier against a pre-defined list of authorized devices upon receiving a binding request. This is achieved by parsing the `device_id` field in the request and checking if the identifier exists in the set of authorized devices in a local database or memory cache. The list of authorized devices can be updated synchronously via a local configuration file, encrypted storage, or a remote management platform. If a match fails, the server returns an "Unauthorized Device" error code and logs it. If a match is successful, the process proceeds to the next stage of the binding protocol execution. This verification process can be further enhanced with timeliness controls (such as limiting the request time window) and frequency limits (to prevent brute-force attacks).

[0119] Binding with the client according to a preset binding protocol refers to both parties following a standardized handshake process to complete identity verification and state synchronization. This protocol can be implemented based on a custom binary protocol or HTTP+JSON, and a typical process includes: the server generating a session token, the client confirming receipt, and the server persisting the binding relationship (e.g., writing to an SQLite database or SharedPreferences). After successful binding, the server generates a unique remote communication interface for the client instance. This interface can be represented as an AIDL (Android Interface Definition Language) interface object, a Binder reference, or a gRPC stub instance, possessing uniqueness and isolation to ensure that communication between different clients does not interfere with each other.

[0120] The generation of a dedicated remote communication interface and its feedback to the client refers to the server sending back the created remote interface proxy object through the current communication link. In the Android system, this process can pass IBinder references across processes via the Parcel mechanism; in cross-device scenarios, it can be achieved by serializing interface metadata (such as method signatures and supported operation types) and transmitting it through a secure channel, allowing the client to reconstruct its local stub object. This interface typically encapsulates the method call entry points required for subsequent communication, such as sendRenderData() and onResultReceived(), laying the foundation for subsequent bidirectional communication.

[0121] Upon receiving the remote communication interface, the client successfully obtains the remote interface reference returned by the server and saves it in its local context or singleton manager for subsequent rendering business calls. After the interface acquisition is complete, the client can trigger an initialization callback to notify the upper-layer application that the service is ready, entering a normal communication state. The entire binding process supports exception handling mechanisms, such as network interruption retry and interface acquisition timeout detection, ensuring robustness in complex environments.

[0122] The synergistic effect among the various technical features is manifested in the following ways: the front-end service ensures the long-term survival of the server and avoids connection interruption due to system recycling; fixed ports provide a stable access point and simplify client connection logic; dual verification of port access permissions and device identification constitutes a multi-layer defense system, realizing secure access control from the network layer to the application layer; binding protocols ensure that the interaction process is orderly and reliable; and dedicated remote communication interfaces realize connection isolation and independent resource allocation, improving system concurrency and security.

[0123] Through the above steps, this application enables the server to automatically establish a high-priority foreground service and open a controlled communication port after startup. The client initiates a secure binding request based on device identity, and the server completes the binding and distributes an independent communication interface after confirming the legitimacy through a multi-factor authentication mechanism. Because of the introduction of a foreground service keep-alive mechanism and port access control policy, the problems of data leakage and resource abuse caused by unauthorized devices potentially accessing the server are solved, thus achieving the technical effect of improving system stability and communication security. This implementation method is applicable to smart terminal systems that require cross-process and cross-device 3D rendering collaboration, and can also be extended to technical fields with strict requirements for secure access, such as IoT device management and remote desktop control.

[0124] Example 6: Based on the above examples, this example further provides: after the client initiates a binding request, it sets a response timeout threshold and a retry interval. If no binding response is received from the server or a binding failure feedback is received after the timeout, and the number of retries has not reached the preset limit, the binding request is resent after the retry interval until the binding is successful or the number of retries reaches the limit. If the binding still fails after the number of retries reaches the limit, a binding error message is output to the client.

[0125] This technical solution involves several key technical features, including "initiation of binding requests," "setting of response timeout thresholds," "configuration of retry interval duration," "detection mechanism for binding responses," "retry logic control conditions," and "output of exception prompts." The following sections explain each of these technical features and clarify their synergistic effects and implementation methods.

[0126] First, "client-initiated binding request" refers to the client proactively sending a data packet containing its own device identifier and other necessary authentication information to the server during the process of attempting to establish a communication connection, in order to initiate the binding process. This binding request is typically transmitted to the server via a preset fixed port through the TCP / IP protocol stack, ensuring that the server can recognize and process the access intent from a legitimate client. In actual implementation, the binding request can be encapsulated in a structured message format (such as JSON or Protobuf), carrying fields such as the device's unique identifier (such as IMEI, MAC address hash value), application version number, and security token, for subsequent identity verification by the server.

[0127] Secondly, the "response timeout threshold setting" refers to the upper limit of the time the client sets for waiting for the server to return a binding response. This threshold can be dynamically adjusted according to the network environment; for example, it can be set to 3 seconds in a Wi-Fi environment and extended to 8 seconds in a mobile cellular network to adapt to different transmission latency characteristics. The timeout mechanism is implemented by an internal timer on the client. Once the binding request is initiated, the timer is triggered. If no valid response (whether success or failure feedback) is received within the set time, it is determined that a timeout event has occurred. This design avoids indefinite blocking caused by server processing delays or network packet loss, ensuring the controllability of the program flow.

[0128] Secondly, the "Retry Interval Configuration" defines the minimum time interval between two consecutive binding requests. This parameter prevents network congestion or server resource exhaustion caused by frequent retries, while also providing the system with a recovery window. In a typical embodiment, the retry interval can be set to 1-5 seconds and supports an exponential backoff strategy, which doubles the interval after each retry, for example, 1 second the first time, 2 seconds the second time, 4 seconds the third time, and so on, until the maximum interval limit is reached. This strategy is particularly suitable for short-lived failure scenarios, such as when the server process is starting but has not yet completed port listening.

[0129] Regarding the "binding response detection mechanism," the client needs to have the ability to parse the server's returned messages to determine whether they are valid binding success signals or explicit failure feedback. Successful responses typically include data such as the remote communication interface handle, session ID, and encryption key seed; failure feedback may carry error codes (such as "device unauthorized," "service busy," etc.). The client manages the state transitions of the binding process using a state machine model: initial state → request sent → waiting for response → receiving result → decision branch (success / failure / timeout). For unsuccessful states, the client determines whether to proceed to the next retry round based on the current number of retries.

[0130] The "retry logic control conditions" include two core judgments: first, whether the current number of retries is lower than the preset limit (e.g., a maximum of 5 attempts); and second, whether the result of the previous attempt was a failure or timeout. Only when both conditions are met is the next resend allowed. This logic can be implemented using a loop + conditional judgment structure, or it can leverage asynchronous task scheduling frameworks (such as Android HandlerThread or Java ScheduledExecutorService) to decouple the main thread's workload. Furthermore, context consistency should be maintained during the retry process to ensure that the content of each binding request remains unchanged, unless the server explicitly requests an update to the credentials.

[0131] Finally, the "output of error messages" is the final action taken after all retries have failed, notifying the user or upper-layer application of a connection failure. The message can be presented in several ways: a Toast or Dialog in the graphical interface displaying "Unable to connect to the 3D rendering service, please check your network or try again later"; a detailed error stack and timestamp recorded in the log system for easy troubleshooting by operations and maintenance; or a callback interface notifying the business module to execute a degradation strategy (such as switching to local lightweight rendering mode). This mechanism improves system observability and user experience, preventing users from mistakenly believing the application is frozen due to a lack of feedback.

[0132] The aforementioned technical features are closely interdependent: the issuance of the binding request is the starting point of the entire mechanism; the timeout threshold and retry interval constitute the time benchmark for elastic retry; response detection provides the basis for decision-making; the retry logic enables automated retrying; and finally, exception prompts complete the closed-loop feedback. Through the above steps, this application achieves the ability to automatically maintain multiple connection attempt opportunities even under network fluctuations or temporary server unavailability, significantly improving the success rate of cross-process binding; at the same time, limiting the number of retries prevents resource abuse and ensures system stability; and clear exception prompts enhance user perception and maintenance convenience.

[0133] Example 7: Based on the above examples, this example further provides the following: When the server receives a communication interface registration request, it extracts the protocol type, transmission specifications, and data compatibility format parameters of the communication interface carried in the request, compares them with its own preset communication adaptation standard, and if the parameters match completely, it determines that the verification is successful, completes the client communication interface registration, generates a 3D view communication identifier, and feeds it back to the client; After the client receives the 3D view communication identifier, it verifies the validity of the identifier, and if the verification is successful, it confirms that the interface registration is complete.

[0134] The technical solution involves the server performing standardized verification of the communication interface parameters contained in the received client registration request, and deciding whether to complete the communication interface registration based on the verification result. At the same time, it achieves state synchronization by generating and feeding back a "3D view communicable identifier". Finally, the client performs reverse verification of the identifier to ensure the consistency and reliability of the two-end communication preparation.

[0135] Step 1: When the server receives the communication interface registration request, it extracts the protocol type, transmission specifications, and data compatibility format parameters of the communication interface carried in the request, compares them with its own preset communication adaptation standards, and determines that the verification is successful when the parameters match completely, thus completing the client communication interface registration.

[0136] "When the server receives the communication interface registration request" means that, assuming the client has successfully established a binding relationship with the server and initiated a registration operation through the remote communication interface, the server enters the processing stage of the interface registration process. This registration request serves as a communication initialization signal initiated by the client, signifying its intention to expose its message receiving capabilities to the server in order to subsequently receive rendering feedback or control commands from the server.

[0137] "Extracting the protocol type, transmission specification, and data compatibility format parameters of the communication interface carried in the request" refers to parsing key metadata describing the characteristics of the communication interface provided by the client from the message body of the registration request. These parameters include, but are not limited to:

[0138] Protocol type: Specifies the types of communication protocols supported by the client, such as IPC protocol based on the Binder mechanism, AIDL (Android Interface Definition Language) interface protocol, Socket communication protocol, etc., which are used to determine the basic communication framework for interaction between the two ends;

[0139] Transmission specifications include performance-related parameters such as maximum message length, single transmission bandwidth limit, flow control strategy, and retransmission mechanism, which are used to evaluate the stability of the interface under high load scenarios.

[0140] Data compatibility format parameter: Defines the data structure format that the client can parse, such as JSON, Protobuf, XML, etc., to ensure that the information returned by the server can be correctly decoded.

[0141] The above parameters together constitute the "interface feature fingerprint" of the client's communication capabilities, which is an important basis for the server to determine whether secure access is possible.

[0142] "Compare with its own preset communication compatibility standards" means that the server compares its internally configured set of communication compatibility rules with the received client parameters one by one. These preset standards are typically set by the system developers based on the target platform's capabilities, security policies, and historical compatibility test results, and are stored in the server's local configuration file or constant table. For example, on the Android platform, if the server only supports the AIDL+Protobuf combination, any interface request using HTTP+JSON will be considered incompatible.

[0143] The requirement that "verification passes when all parameters match" emphasizes that all fields to be compared must be strictly consistent for registration to be considered legitimate. This full-match mechanism avoids hidden errors caused by partial compatibility issues, such as protocol version mismatches or missing fields. If any parameter is found to be non-compliant, the server will refuse registration and return an error code, prompting the client to adjust or reinitialize.

[0144] "Completing client communication interface registration" means that the server creates and maintains a persistent communication proxy object in memory for the client. This object encapsulates the call handle of the client interface and its context information, allowing the server to directly call the methods provided by the client during its lifecycle, thereby establishing reverse communication capabilities.

[0145] Step 2: Generate a 3D view communicable identifier and send it back to the client.

[0146] The "Generate 3D View Communication Capability Identifier" refers to the server assigning a unique status credential to the successfully registered client after successful verification. This identifier can be a UUID string, a timestamp hash value, or an auto-incrementing ID, and is used to mark that the client is qualified to participate in 3D rendering business interactions. This identifier not only serves as a confirmation signal for successful registration but can also be used for subsequent session management, permission tracking, and anomaly diagnosis.

[0147] "Feedback to the client" refers to sending the identifier back to the client asynchronously via the established remote communication interface. The transmission process follows a lightweight messaging protocol to ensure low-latency delivery. This operation completes the registration loop on the server side.

[0148] Step 3: After receiving the 3D view communication identifier, the client verifies the validity of the identifier. If the verification passes, the interface registration is confirmed to be complete.

[0149] Among them, "receive 3D view communicable identifier" means that the client obtains the response message from the server through the listening channel provided during its registration and extracts the identifier content from it.

[0150] "Verifying the validity of the identifier" is the process by which the client verifies the integrity and legitimacy of the received identifier. Specifically, this includes checking whether the identifier format meets expectations (e.g., length, character set), whether a signature or checksum (e.g., HMAC-SHA256) exists, and whether it is within its validity period. For example, if the server issues identifiers in JWT (JSON Web Token) format, the client needs to use a shared key to verify its digital signature to prevent forgery.

[0151] "Verification passed, interface registration is confirmed" indicates that after the client completes local verification, it switches its internal state machine to the "registered" state and triggers a callback to notify the upper-layer application module (such as the UI thread) that the communication link is ready and can start sending rendering business data.

[0152] A two-way closed-loop verification logic is formed among the various technical features: the server ensures the technical compliance of the client interface through parameter comparison, and the client ensures the authenticity of the server response through identifier verification. The two work together to build a secure registration mechanism in a trustless environment.

[0153] Through the above steps, this application achieves server-side capability verification and access control of the client's communication interface, as well as client-side verification of the authenticity of information returned by the server. By introducing a dual-end mutual verification mechanism, it resolves issues such as registration failure, communication interruption, or data leakage that may result from inconsistent communication interface parameters or forged identifiers, thereby improving the stability and security of the cross-process 3D rendering system in complex operating environments. This mechanism is particularly suitable for distributed rendering scenarios with multiple clients concurrently accessing and devices dynamically joining / leaving, enhancing the system's scalability and fault tolerance.

[0154] Example 8: Based on the above examples, this example further provides: the client and server negotiate a temporary encrypted transmission key based on the registered communication interface, and establish a two-way encrypted data transmission link after the key negotiation is successful; the client analyzes the 3D rendering business requirements, extracts rendering business data such as rendering scene, model parameters, and effect parameters, encapsulates it according to the link adaptation format, and sends it to the server through the encrypted data transmission link; the server receives the rendering business data, decrypts and parses it, performs business adaptation rendering based on its own 3D rendering engine, integrates the rendering results after rendering is completed, encrypts it, and sends it back to the client through the encrypted data transmission link; the client decrypts it and receives the rendering results.

[0155] Negotiating a temporary encrypted transmission key refers to the process by which the client and server, after registering their communication interface, dynamically generate a symmetric encryption key for the current session or rendering task using a standard or custom key negotiation protocol (such as Diffie-Hellman key exchange, ECDH elliptic curve key exchange, or a pre-shared key mechanism based on the TLS handshake process). This key is temporary, one-time, or has a limited lifespan, avoiding the security risks associated with using the same key for an extended period. For example, in some implementation scenarios, RSA asymmetric encryption can be used for initial authentication, and an AES-256 symmetric encryption key can be negotiated as the encryption key for data transmission. Alternatively, a session key can be generated by combining a timestamp and a random number to ensure the uniqueness of the key for each communication. This process can be implemented within the secure communication framework provided by the operating system, such as the Binder mechanism on the Android platform with SSL / TLS layer extensions, or through a separate Security Module to complete the key negotiation process.

[0156] Establishing a bidirectional encrypted data transmission link refers to the process where, after successful key negotiation, both the client and server configure encryption components and enable data encryption and decryption capabilities based on symmetric encryption algorithms, forming a secure communication channel that supports bidirectional data flow. This link not only ensures the security of request data from the client to the server but also ensures that the rendering results returned by the server are not stolen or tampered with by intermediate nodes. During the link establishment process, both parties need to synchronize the encryption algorithm type (e.g., AES, SM4), working mode (e.g., CBC, GCM), and padding rules to ensure encryption and decryption consistency. Furthermore, this link can integrate integrity verification mechanisms (e.g., HMAC or AEAD authentication encryption) to prevent data replay or injection attacks. In practical implementation, a secure channel can be built by overlaying an SSL / TLS protocol stack through a Socket connection, or cross-process secure communication can be achieved using system-level IPC mechanisms (e.g., AIDL + Parceler encryption encapsulation).

[0157] Analyzing 3D rendering business requirements is the process by which the client identifies and organizes the 3D rendering tasks to be executed based on the current user actions or application logic. This process includes determining whether actions such as model loading, scene switching, lighting adjustment, animation playback, and special effects overlay are involved, and transforming these high-level semantics into a structured set of rendering instructions. For example, when a user triggers the "View product 3D display" function, the client needs to determine information such as the target model ID, initial viewpoint position, background environment settings, and interaction control methods, and then generate a complete description of the rendering requirements.

[0158] Extracting rendering business data, such as rendering scene, model parameters, and effect parameters, refers to extracting a set of key parameters from the aforementioned business requirements that can be used to directly drive the 3D rendering engine on the server side. "Rendering scene" includes scene graph structure, camera configuration, light source layout, and environment texture paths; "model parameters" cover model file identifiers, scaling ratios, rotation angles, translation coordinates, and material mapping relationships; and "effect parameters" include particle system settings, shadow quality levels, anti-aliasing modes, and post-processing filters (such as Bloom and DOF) for visual enhancement. These parameters typically originate from local configuration files, data distributed from remote servers, or real-time user input, and all require unified normalization processing for subsequent encapsulation.

[0159] Encapsulation according to the link adaptation format means converting the extracted rendering business data into a data structure and encoding format suitable for encrypted link transmission. This format should have good readability, extensibility, and compatibility. Common forms include lightweight serialization formats such as JSON (JavaScript Object Notation), Protocol Buffers, or MessagePack. Taking JSON as an example, the parameter fields are organized according to predefined key names, such as `"scene": {"camera": {...}, "lighting": {...}}`, and a version number field (such as `"version": "1.0"`) is added to support future protocol upgrades. Metadata, such as request ID, timestamp, and priority markers, can also be added during the encapsulation process to assist server-side scheduling and debugging. For binary resources (such as texture images and audio clips), Base64 encoding can be used to embed a text structure, or resource handles and data streams can be sent separately through a chunked transmission mechanism.

[0160] Sending data to the server via an encrypted data transmission link refers to the client calling the underlying communication interface (such as TCPSocket, Unix Domain Socket, or system Binder service) to push the encapsulated and encrypted data packet to the server. Before sending, the entire data body must be encrypted using a negotiated temporary key to ensure that the original content cannot be recovered even if the transmission channel is intercepted. The sending action can be executed synchronously or asynchronously, choosing to block and wait for a response or immediately return to continue other operations depending on the urgency of the task. In weak network environments, optimization strategies such as breakpoint resumption, traffic compression, and QoS classification can be introduced to improve transmission efficiency.

[0161] After receiving the rendering business data, the server decrypts and parses it. This indicates that the server has received the encrypted data stream from the client through a listening port or remote interface. First, it performs a decryption operation using the same temporary key to recover the original data content. Then, it performs syntax and semantic checks on the data structure according to the agreed data format (such as JSON Schema), verifying field integrity, type correctness, and logical rationality. If any missing key parameters or format errors are found, a structured error code is returned to the client, terminating the current rendering process.

[0162] Leveraging its own 3D rendering engine to perform business-adaptive rendering refers to the server injecting the parsed rendering parameters into its built-in 3D graphics engine (such as Unity Engine, Unreal Engine, OGRE, or a self-developed rendering framework) and starting the corresponding rendering pipeline to execute image generation tasks. This process includes multiple stages such as resource loading (retrieving models, textures, and animations from local cache or resource servers), scene building, view frustum clipping, geometry processing, shading calculations, and rasterization output. The server can dynamically adjust the rendering resolution, frame rate cap, or LOD (Level of Detail) level based on device performance to balance image quality and response speed. Furthermore, it supports multi-task queue management, allowing multiple client requests to be queued and processed according to priority, preventing a single high-load request from impacting the overall service quality.

[0163] After rendering is complete, integrating the rendering results refers to the server packaging the final generated one or more frames of image data (such as RGBA bitmaps, video stream clips), status feedback information (such as rendering time, GPU utilization), and event notifications (such as animation end, collision detection trigger) into a unified result data package. For continuous animation scenes, timestamp sequences and interpolation information may also be included to facilitate smooth playback on the client side. The result integration process must maintain contextual association with the original request to ensure that the response accurately matches the initiator.

[0164] After encryption, the data is transmitted back to the client via an encrypted data transmission link. This indicates that the server has re-encrypted the integrated rendering result using the same or a different encryption key and then transmitted it back to the client via the established bidirectional encrypted link. The transmission method can be streaming (suitable for video or large images) or sending the entire packet (suitable for static images). To improve reliability, an ACK confirmation mechanism or ARQ retransmission strategy can be used to ensure complete delivery of the result.

[0165] After receiving the encrypted response data, the client decrypts and receives the rendering result. This means that after receiving the encrypted response data, the client uses the corresponding decryption key to restore the original rendered output content and performs format parsing and validity verification. Upon successful decryption, the image data is displayed on the front-end interface (such as TextureView or SurfaceView controls), or status information is fed back to the business logic layer for subsequent interaction decisions. If decryption fails or verification fails, an exception handling process is triggered, such as requesting a retransmission, downgrading to displaying the default screen, or indicating a network error.

[0166] The above-mentioned technical links work closely together: key negotiation provides a security foundation for the encrypted link, the link establishment supports an efficient and reliable data interaction channel; accurate extraction and standardized encapsulation of business data improves transmission efficiency and parsing success rate; centralized server-side rendering reduces the resource consumption of terminal devices; and the encrypted return mechanism provides closed-loop protection for data security throughout the entire process.

[0167] Through the above steps, this application achieves the following: With the client and server having completed communication interface registration, a temporary encryption key is generated through negotiation, and a bidirectional encrypted data transmission link is established, enabling efficient transmission of business data required for 3D rendering through a secure channel. The client focuses on organizing business requirements and encapsulating data, while the server focuses on executing high-quality 3D rendering tasks, resulting in a clear separation of responsibilities. The rendering results are encrypted and then decrypted by the client, forming a complete "request-rendering-feedback" closed-loop mechanism. The use of encrypted transmission effectively prevents data leakage and tampering risks in cross-process communication, meeting privacy protection and compliance requirements. Structured data encapsulation improves compatibility and maintainability between different clients and servers. Centralized rendering on the server avoids memory waste caused by multiple processes repeatedly loading the 3D engine, significantly reducing overall system resource consumption. Support for bidirectional communication enables real-time interactive 3D applications (such as remote control, collaborative design, and cloud gaming), expanding the boundaries of application scenarios.

[0168] Example 9: Based on the above examples, this example further provides the following: When the client encapsulates rendering business data, it calls a preset data encapsulation method to define data fields in JSON format, fills in the rendering business data, and adds a data verification code to complete the data encapsulation; after receiving the rendering business data, the server verifies the data verification code to confirm that the data is complete and unaltered before parsing; when the server sends back the rendering result, it encapsulates the rendering result in JSON format and adds a result verification identifier. After receiving the result verification identifier, the client verifies the result verification identifier. If the verification passes, the client confirms that the rendering result is valid and receives it; if the verification fails, the client sends a retransmission request for the rendering result to the server.

[0169] The phrase "when the client encapsulates rendering business data, it calls a preset data encapsulation method to define data fields in JSON format" refers to the client calling a built-in data serialization module before sending a 3D rendering task. This module uses JavaScript Object Notation (JSON), a lightweight, language-independent data exchange format, to structure the rendering instructions. JSON offers excellent readability and cross-platform compatibility, making it suitable for communication between heterogeneous systems. This format allows data to be organized in key-value pairs; for example, "scene_type": "indoor" indicates the rendering scene type, and "model_path": " / assets / car.glb" specifies the model resource path. By uniformly using JSON as the data carrier, the server can accurately parse requests from different clients, while also facilitating the later addition of new fields (such as lighting parameters and animation control logic) without modifying the underlying communication protocol.

[0170] As an alternative implementation, clients can also use other structured data formats instead of JSON, such as Protocol Buffers (Protobuf) or XML, to achieve the same functionality while ensuring consistency in the mapping of data structures between the front-end and back-end. Furthermore, to improve transmission efficiency, data packets can be compressed using compression algorithms such as GZIP after JSON encapsulation, which is particularly suitable for complex rendering tasks containing large amounts of vertex data or texture configuration information.

[0171] "Inputting rendering business data" includes, but is not limited to: the topological description of the 3D rendering scene, the loading path and instantiation parameters of the 3D model, material texture configuration, lighting settings, camera view parameters, animation playback control commands, and special effects overlay rules. These data collectively constitute a complete expression of the rendering intent. For example, in an in-vehicle AR navigation application, rendering business data may include road model loading commands, real-time positioning coordinate injection, dynamic arrow guidance effect parameters, and environmental lighting adaptation strategies. All data is organized according to a predefined JSON Schema to ensure standardized field naming, clear hierarchy, and explicit semantics.

[0172] "Adding a data checksum" refers to the client further calculating the integrity check value of the entire data packet after data encapsulation and embedding it as an independent field in the JSON object. Common checksum generation methods include Cyclic Redundancy Check (CRC32), message digest algorithms (such as MD5, SHA-256), or key-based message authentication codes (HMAC). For example, in one embodiment, after generating the JSON string, the client calls the SHA-256 hash function to perform a one-way hash operation on the string, obtaining a fixed-length checksum, which is then appended to the end of the data in the form "checksum": "a1b2c3...". This mechanism can be used to detect data corruption that may occur outside the encrypted transmission link, such as truncation due to network packet loss, intermediate node caching errors, or bit flipping caused by storage media failures.

[0173] As a variant, the checksum can also be applied to the byte stream after binary serialization rather than the original JSON text, thus more closely resembling the actual transmission format; alternatively, a segmented checksum mechanism can be used to generate checksums for different logical modules of large data packets, improving the accuracy of anomaly detection. Furthermore, if the system has high security requirements, a digital signature mechanism can be introduced, using asymmetric encryption algorithms (such as RSA or ECDSA) to sign the data digest, achieving dual protection of authentication and tamper-proofing.

[0174] "After receiving the rendering business data, the server verifies the data checksum to confirm the data is complete and unaltered before parsing." This means that after receiving and decrypting the encrypted data from the client, the server first extracts the data checksum field. Then, it re-executes the same verification algorithm on the main data, comparing the locally calculated checksum with the received checksum. Only when they match perfectly is the data considered unaltered and undamaged, and subsequent syntax parsing and semantic processing begins. If the verification fails, the processing is immediately interrupted, an error log is recorded, and an error code may be selectively returned to the client, prompting them to resend the request.

[0175] This mechanism effectively prevents invalid rendering calls caused by network jitter, buffer overflows, or malicious attacks, avoiding the waste of valuable server GPU resources by executing incorrect instructions. For example, in a weak network environment, some TCP segments may be lost or reassembled out of order, resulting in syntax breaks in JSON strings. In this case, pre-validation can quickly identify and reject such illegal requests, improving system robustness.

[0176] "When the server sends back the rendering results, it encapsulates the rendering results in JSON format and adds a result verification identifier." This means that after completing the 3D rendering task, the server organizes the generated image data metadata (such as frame number, timestamp, resolution, encoding format), rendering status code (success / failure / timeout), texture resource reference address, or Base64-encoded lightweight preview image, also in JSON format, and attaches an identifier field to verify the integrity of the result. This result verification identifier can be a simple CRC check value or a message digest containing a timestamp and device fingerprint, used to prevent man-in-the-middle tampering or replay attacks.

[0177] In one optional embodiment, the server writes the rendered video frames to a temporary file using H.264 encoding and provides a download link and ETag verification tag in the JSON response body. The client can resume interrupted downloads via HTTP Range requests and verify resource consistency using ETag. For scenarios with high real-time requirements, the server can also directly embed small-sized rendered images into the JSON, such as transmitting them inline in the form of "data:image / png;base64,...", combined with result verification tags to ensure data credibility.

[0178] The statement "After receiving the data, the client verifies the verification result and identifier. If the verification passes, the rendering result is confirmed as valid and accepted; if the verification fails, a retransmission request for the rendering result is sent to the server" indicates that after receiving the data returned by the server, the client will not directly display or use the rendering result, but will first perform an integrity verification. Specifically, the client parses the JSON response, extracts the result data body and verification identifier, recalculates the local verification value, and compares them. If they match, the communication is considered successful, and the rendering result is handed over to the UI thread for display or cache processing; if they do not match, the retransmission mechanism is triggered, a new retrieval request is constructed and sent to the server, carrying the original task ID so that the server can quickly locate and resend the corresponding result.

[0179] This retransmission mechanism allows setting a maximum number of attempts (e.g., 3) and an exponential backoff delay strategy to avoid resource waste when the network remains unstable. Simultaneously, the client can display a "Loading..." message on the user interface and pop up an error notification after consecutive retransmission failures, guiding the user to check the network connection or restart the service.

[0180] A closed-loop control logic is formed between each technical link: the data encapsulation stage establishes standardized expression and integrity anchor points, pre-transmission verification prevents invalid instruction execution, the result feedback stage continues the same principle to ensure output reliability, and communication continuity is restored through retransmission in abnormal situations. This fault-tolerant architecture of "send-verify-feedback-retry" significantly improves the stability and reliability of cross-process 3D rendering systems.

[0181] Through the above steps, this application achieves end-to-end integrity assurance for cross-process rendering data. By employing a structured JSON data format and a two-way verification mechanism, it solves the problem of rendering failures or abnormal visuals caused by data loss and tampering in complex network environments. This improves the delivery rate and accuracy of rendering results, enhances the consistency of user experience, and strengthens the overall robustness of the system.

[0182] In one embodiment, such as Figure 2 As shown, based on the same technical concept, this invention also provides a cross-process 3D effect rendering system. This system uses the client as the execution entity for layout, thereby achieving cross-process 3D effect rendering. The system specifically includes:

[0183] The view creation module 210 is used to perform initialization operations after the client starts, load and verify 3D related libraries, and create a 3D view adapted to server rendering after the verification is passed.

[0184] The process status detection module 220 is used to send an operation request to the server based on the 3D view and detect the server process status. If the server has not started, the server process will be started.

[0185] Binding module 230 is used to establish a binding with the server through the binding port opened by the server and obtain the remote communication interface generated by the server;

[0186] The interface registration module 240 is used to send a communication interface registration request to the server through the remote communication interface. After the server verifies the registration, the client will complete the registration and synchronously obtain the 3D view communication identifier fed back by the server.

[0187] The rendering data transmission module 250 is used to establish an encrypted data transmission link with the server based on the registered communication interface, send rendering business data to the server through the link, and receive the rendering results returned by the server.

[0188] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A cross-process 3D effect rendering method, characterized in that, The method includes: After the client starts, it performs initialization operations, loads and verifies 3D-related libraries, and creates a 3D view adapted for server-side rendering after the verification is successful. Based on the 3D view, an operation request is sent to the server, and the server process status is detected. If the server is not started, the server process is started. By establishing a binding with the server through the binding port opened by the server, the remote communication interface generated by the server can be obtained; The client sends a communication interface registration request to the server through the remote communication interface. After the server verifies the registration, the client completes the registration and synchronously obtains the 3D view communication identifier fed back by the server. An encrypted data transmission link is established with the server based on the registered communication interface. Rendering business data is sent to the server through the link, and the rendering results are received back from the server.

2. The method according to claim 1, characterized in that, The process of creating a 3D view adapted for server-side rendering after successful verification includes: traversing the local 3D-related library storage path by calling a preset initialization mechanism, loading all 3D-related library files, and verifying the compatibility of the library file version with the client system and the file integrity one by one; after all library files have passed verification, the 3D-related library initialization is completed, and a view creation tool is called to generate a 3D view containing server-side rendering adaptation parameters; the communicability attributes of the 3D view are verified, and if the verification is successful, a 3D view adapted for server-side rendering is obtained.

3. The method according to claim 2, characterized in that, The loading of all 3D-related library files also includes: if a library file is detected to be missing or corrupted during the loading process, the corresponding missing or corrupted library file is downloaded from a preset resource server, and the 3D-related library loading and verification operation is re-executed after the replacement is completed until the verification passes.

4. The method according to claim 1, characterized in that, The detection of the server process status includes: after sending an operation request to the server, calling the process status query interface to detect in real time whether the server process PID exists. If the PID exists, it is determined that the server process has started, the process detection is stopped and the next step is entered; if the PID does not exist, it is determined that the server process has not started, a server process start command is generated, the process startup program under the server installation path is triggered, the server process is started and the PID generation status is continuously detected until the PID exists.

5. The method according to claim 1, characterized in that, The process of establishing a binding with the server through the binding port opened by the server and obtaining the remote communication interface generated by the server includes: After the server process starts, the foreground service is started automatically. The foreground service is configured to run at a certain priority and a fixed bound port is opened. At the same time, port access permissions are set so that only authorized devices are allowed to access the server. The client obtains the binding port opened by the server, generates a binding request containing its own device identifier, and sends it to the server through the port. After receiving the binding request, the server verifies the matching of the device identifier with the preset authorized device list. If they match, the server completes the binding with the client according to the preset binding protocol. After successful binding, the server generates a remote communication interface and sends it back to the client. After receiving the remote communication interface, the client completes the acquisition of the remote communication interface.

6. The method according to claim 1, characterized in that, The method further includes: after the client initiates a binding request, setting a response timeout threshold and a retry interval; if no binding response is received from the server or a binding failure feedback is received after the timeout, and the number of retries has not reached the preset limit, the binding request is resent at the retry interval until the binding is successful or the number of retries reaches the limit; if the binding still fails after the number of retries reaches the limit, a binding error message is output to the client.

7. The method according to claim 1, characterized in that, The step of sending a communication interface registration request to the server via a remote communication interface and completing the registration after the server verifies the request includes: when the server receives the communication interface registration request, it extracts the communication interface protocol type, transmission specification, and data compatibility format parameters carried in the request, compares them with its own preset communication adaptation standard, and determines that the verification is successful when the parameters match completely, completes the client communication interface registration, generates a 3D view communication identifier and feeds it back to the client. After receiving the 3D view communication identifier, the client verifies the validity of the identifier. If the verification passes, the interface registration is confirmed to be complete.

8. The method according to claim 1, characterized in that, The establishment of an encrypted data transmission link between the registered communication interface and the server, the sending of rendering business data to the server through the link, and the receiving of rendering results from the server include: the client and the server negotiating a temporary encrypted transmission key based on the registered communication interface, and establishing a two-way encrypted data transmission link after the key negotiation is successful. Analyze 3D rendering business requirements and extract rendering business data; wherein, the rendering business data includes: rendering scene, model parameters, and effect parameters; The rendering service data is encapsulated according to the link adaptation format and sent to the server through the encrypted data transmission link. The server also receives encrypted data back through the encrypted data transmission link. By decrypting the returned encrypted data, the server obtains the rendering result of rendering and integrating the decrypted rendering business data based on its own 3D rendering engine. The rendering result includes the result verification identifier corresponding to the rendering result. After receiving the data, the client verifies the verification result and identifier. If the verification passes, the client confirms the validity of the rendering result and accepts it. If the verification fails, the client sends a retransmission request for the rendering result to the server.

9. The method according to claim 8, characterized in that, The process of encapsulating rendering business data according to the link adaptation format includes: calling a preset data encapsulation method to define data fields in JSON format, filling in the rendering business data and adding a data verification code to complete the data encapsulation.

10. A cross-process 3D effect rendering system, characterized in that, The system includes: The view creation module is used to perform initialization operations after the client starts, load and verify 3D related libraries, and create a 3D view adapted to server-side rendering after the verification is passed; The process status detection module is used to send operation requests to the server based on the 3D view and detect the server process status. If the server is not started, the server process will be started. The binding module is used to establish a binding with the server through the binding port opened by the server and obtain the remote communication interface generated by the server. The interface registration module is used to send a communication interface registration request to the server through the remote communication interface. After the server verifies the registration, the client will complete the registration and synchronously obtain the 3D view communication identifier fed back by the server. The rendering data transmission module is used to establish an encrypted data transmission link with the server based on the registered communication interface, send rendering business data to the server through the link, and receive the rendering results returned by the server.

Images