Unified model-based web3d zero-code interaction design platform and method

Abstract

The application belongs to the technical field of codeless development, and particularly relates to a Web3D zero-code interaction design platform and method based on a unified model, which comprises: a unified business logic model (UBLM), a platform-independent, self-describing and structured data container, which is used for completely defining all behavior logic in a 3D interaction application, including events, conditions, actions, parameters, variables and flow relationships; a dual-mode editor, which comprises a form editor and a blueprint editor, and can completely create, edit and visualize the same UBLM, and realize real-time state synchronization; and an interpretive rule execution engine (IREE), a lightweight engine running in a browser JavaScript environment, which is responsible for parsing the UBLM at runtime, and converting the declarative logic into executable instructions in a 3D scene through a rule matching and function registration mechanism. The application can improve development and collaboration efficiency, and simplify the iteration and maintenance process.

Description

Technical Field

[0001] This invention belongs to the field of no-code development technology, specifically relating to a Web3D zero-code interactive design platform and method based on a unified model. Background Technology

[0002] Currently, the following technical paths and inherent defects exist in the development of 3D content creation and interaction logic on the browser side: Path A: Pure code development (such as Three.js / Babylon.js programming): High flexibility, but high technical threshold and long iteration cycle, which does not conform to the no-code trend. Path B: Single form configuration tools: Commonly found in simple 3D display editors, they only support object property (position, material) configuration and cannot define complex condition judgments, event response sequences, and flow control logic, resulting in weak functionality. Path C: Client-side ported node editors (such as web versions based on Rete.js): Provide visual programming capabilities, but have two major problems: editing state (node ​​position, view zoom) is usually stored separately from logical data, leading to data redundancy and synchronization risks; it is not user-friendly for non-professional users, and the mental transition cost is high. Path D: Traditional no-code game engines (such as Construct3's event table): Adopt a form-like event-driven model, which is easy to learn, but when expressing complex, multi-branch parallel or nested logic, the interface becomes lengthy and unintuitive, making it difficult to conduct macro-level process review and optimization. General performance bottleneck: As the number of logical rules increases, many script systems based on dynamic interpretation or per-frame traversal are prone to causing a significant drop in browser runtime performance (frame rate), affecting the interactive experience of complex projects.

[0003] As can be seen from the above technical approaches and their inherent defects, existing technical solutions have irreconcilable contradictions among the flexibility (ease of use and power) of the editing interface, the uniformity of logical data (single source of facts) and the performance of runtime (complexity scalability), and lack a systematic architecture that can take all three into account at the same time. Summary of the Invention

[0004] In view of the shortcomings of the prior art, the purpose of this invention is to provide a Web3D zero-code interactive design platform and method based on a unified model. With a unified business logic model as support, it significantly reduces the threshold for 3D business logic development through a browser-side no-code editing mode, realizes the reuse of logic modules, improves development and collaboration efficiency, simplifies the iteration and maintenance process, and helps 3D business to be quickly implemented and scaled up.

[0005] To achieve the above objectives, this invention provides a Web3D zero-code interactive design platform based on a unified model, comprising:

[0006] The Unified Business Logic Model (UBLM) is a platform-independent, self-describing, structured data container used to fully define all behavioral logic in 3D interactive applications, including events, conditions, actions, parameters, variables, and process relationships.

[0007] The dual-mode editor DMAE includes a form-based editor and a blueprint-based editor. Both editors can fully create, edit, and visualize the same UBLM and achieve real-time state synchronization. DMAE includes the MDIR rendering engine, and the editing interface dynamically generates views based on the current UBLM data. Any user interface operation is directly translated into modification instructions for the underlying UBLM.

[0008] IREE is an interpreted rule execution engine, a lightweight engine that runs in the browser's JavaScript environment. It is responsible for parsing UBLM at runtime and converting declarative logic into executable instructions in the 3D scene through rule matching and function registration mechanisms.

[0009] As a preferred embodiment of the present invention, in UBLM, a UBLM document is logically a complete logical definition of a project, serialized and exchanged using JSON format, and the root structure of the UBLM document contains the following parts:

[0010] The metadata area contains the UBLM version number, project name, unique identifier, and creation and modification timestamps;

[0011] The global resource declaration area includes a variable pool and an object reference mapping table: The variable pool defines one or more global variables, each of which contains a name, data type, initial value, and optional descriptive information, where the data type includes integer, boolean, and string; The object reference mapping table maintains a set of mapping relationships from logical identifiers to specific object instance IDs in the actual 3D scene;

[0012] The core rules collection area is an array that contains all the business logic rules in the project. Each rule is an independent "event-condition-action" logical unit.

[0013] As a preferred embodiment of the present invention, the detailed structure of the "event-condition-action" logic unit in the core rule set area is as follows:

[0014] Rule identifiers and metadata, including a unique rule ID, a user-defined readable name, group labels, and enable / disable switches;

[0015] The event descriptor contains the event type enumeration value rule.event.type, the event target object rule.event.target, and the event-specific parameter object rule.event.parameters, where rule.event.target references the logical identifier in the mapping table;

[0016] The execution condition set is an array of conditional expressions that defines all the prerequisites that must be met for an action to be executed after a rule is triggered. All conditions are connected by an "AND" relationship by default. Each condition is an object that contains a condition type (rule.conditions.type), operators (Operators), operands (Operands), and a boolean value (negated), where negated indicates whether the condition result is negated.

[0017] An action sequence is an array of action description objects that defines a series of operations to be executed in sequence when an event is triggered and all conditions are met. Each action object contains an action type (rule.action.type), a reference to the target object to which the action is applied (rule.action.target), specific action parameters (rule.action.parameters), and a floating-point number (delay), where delay represents the delay time for the action to be executed relative to the triggering of the rule or the completion of the previous action.

[0018] As a preferred embodiment of the present invention, in DMAE, the form-based editor provides a linear interface suitable for quickly entering and modifying rule details. The working mechanism of the form-based editor includes view generation and user interaction processing.

[0019] View generation: When the user enters form mode, iterates through the core rule set area of ​​UBLM, creating a collapsible rule card for each rule. Within the rule card:

[0020] For the event descriptor, based on the value of rule.event.type, render a non-editable static label or icon to display the event type. Next to the static label or icon is an object selector control whose list of possible values ​​comes from an object reference map, and the currently selected item is bound to rule.event.target.

[0021] For each set of execution conditions, render a row for each condition object. The row contains: a variable / property selector that binds to the left operand of the condition, an operator dropdown that binds to Operators, a value input control that binds to the right operand, and an "Add Condition" button that allows inserting new empty condition objects to the end of the array.

[0022] For each action sequence, an area is rendered for each action object, including: an action type dropdown bound to rule.action.type, a target selector bound to rule.action.target, an "Add Action" button and a "Move Up / Move Down" button for managing the action sequence, and a dynamic parameter panel. The dynamic parameter panel dynamically renders the required input controls based on the currently selected action type, including numeric input boxes, resource selectors, color selectors, text input boxes, and custom attribute selectors. Each input control is precisely bound to the corresponding field in the rule.action.parameters object.

[0023] User interaction processing: When a user makes a modification to any input box or dropdown box, the displayed value of the UI will not be changed directly. Instead, an update event with precise path information will be triggered.

[0024] As a preferred embodiment of the present invention, in DMAE, the blueprint-based editor provides a graphical canvas based on nodes and connections, suitable for visualizing logical flows and macro-level architecture. The working mechanism of the blueprint editor also includes view generation and user interaction processing.

[0025] View generation: When a user enters Blueprint mode, a transformation from UBLM to a node diagram is performed, including:

[0026] Node mapping: Each rule is mapped to a composite node, or split into event nodes, condition judgment node groups, and action sequence nodes according to the configuration. Each node has its position information on the canvas.

[0027] Port generation: Event nodes have an "output" port; condition judgment nodes have both "input" and "output" ports; action sequence nodes have an "input" port;

[0028] Connection generation: Based on the inherent logical order of the rules, connections are generated between the corresponding node ports, and the connections represent the transmission of control flow;

[0029] User interaction processing: User actions on the blueprint are translated into structured modifications to the UBLM, including dragging and dropping connections, deleting connections, and modifying nodes in the properties panel.

[0030] As a preferred embodiment of the present invention, the real-time synchronization of the states of the form-based editor and the blueprint-based editor is achieved as follows:

[0031] Establish a central event bus and a UBLM manager. The UBLM manager holds the current version of the UBLM data and is responsible for processing all legitimate update events.

[0032] When a user performs an operation on a form or blueprint, a "patch" instruction describing the data change is generated and submitted to the UBLM manager via the central event bus.

[0033] After receiving a "patch", the UBLM manager applies the received "patch" to the current UBLM in an immutable data update manner, generating a brand new UBLM data snapshot with an incrementing version number; then, the UBLM manager broadcasts a "model updated" notification through the central event bus, which carries the change path information and a comparison of the old and new values;

[0034] Perform interface subscription and incremental updates, including:

[0035] Both the form-based editor and the blueprint-based editor act as subscribers, listening for "model updated" notifications;

[0036] For both active and inactive / background interfaces, after receiving a notification, the form-based editor's internal rendering engine precisely locates the UI components that need updating based on the change path; after receiving a notification, the blueprint-based editor's internal rendering engine performs the following operations:

[0037] Data mapping recalculation: Based on the new UBLM, the logical relationships of nodes, ports, and connections are recalculated; Topology update: If the change involves the addition or deletion of rules or changes in logical relationships, the rendering engine automatically adds or deletes nodes or removes invalid connections; Layout optimization: The rendering engine triggers a lightweight automatic layout algorithm to adjust the positions of affected node areas to avoid node overlap. The final position of the nodes is saved as the view state and is separated from the UBLM.

[0038] Because both the form-based editor and the blueprint-based editor render based on the same up-to-date UBLM data, they maintain strict consistency at the data level.

[0039] As a preferred embodiment of the present invention, the goal of IREE is to transform declarative UBLM into business logic code that runs directly in the browser. IREE adopts a pre-compiled architecture combined with an event-driven approach, decoupling the logical complexity from the calculations performed in each frame at runtime. The execution flow of IREE includes:

[0040] Phase 1, Initialization Phase: Pre-compilation and registration are performed. When the user clicks the "Run" or "Preview" button set in the global common operation area of ​​DMAE, IREE starts working and executes the following steps:

[0041] Model loading and parsing: IREE reads the project's UBLM JSON from persistent storage and parses it into an in-memory object;

[0042] Create runtime context: Initialize a RuntimeContext object, which contains copies of the values ​​of all current global variables, scene object access interfaces, and an event emitter for cross-rule communication;

[0043] Rule traversal and functionalization: IREE traverses each enabled rule in the core rule set area. For the set of execution conditions, it compiles it into a pure JavaScript function. For the action sequence, IREE creates a closure function for each action that knows how to execute the action, and wraps the closure function into a schedulable action chain function according to the order and delay parameters.

[0044] Rule wrapper creation: Package the pure JavaScript function and action chain function together with the description information of the triggering event of the rule to create a rule processor object;

[0045] Establishing an event-rule index: IREE registers rule processor objects into a multi-level hash map table based on each rule's rule.event.type and rule.event.target.

[0046] Phase Two, Runtime Phase: During this phase, the runtime loop begins. IREE works in conjunction with the 3D rendering engine to execute the following steps:

[0047] Event injection: When the 3D rendering engine detects an interactive event during its own update cycle, it normalizes the event and passes it to IREE through a predefined interface;

[0048] Event routing and rule retrieval: IREE's event listeners receive standardized event objects and use the event type and target ID as keys to query the event-rule index mapping table;

[0049] Synchronous condition validation: IREE synchronously and sequentially calls the pure JavaScript function of each rule processor in the list, passing in the current RuntimeContext object;

[0050] Asynchronous scheduling of actions: For rules that return true for all conditions, IREE introduces a time-based scheduler to begin processing its action chain;

[0051] Action execution and state update: The action closure being executed contains code that calls the 3D rendering engine API. These calls directly affect the rendering tree and produce visual or auditory feedback.

[0052] Looping and Cleanup: The steps described above in the runtime phase continue throughout the application's lifecycle. When the scene changes or the application stops, IREE unregisters all event listeners, clears the scheduling queue and index table, and releases resources.

[0053] As a preferred embodiment of the present invention, IREE introduces a time-based scheduler for processing action chains of rules that return true, specifically:

[0054] For each action closure with delay in the action chain, IREE calculates its absolute execution time.

[0055] IREE encapsulates these action closures and their absolute execution times into scheduling tasks and inserts them into a priority queue sorted by execution time.

[0056] The priority queue is driven by the browser's requestAnimationFrame. Before each frame is rendered, IREE checks the head of the queue. If the current time has reached or exceeded the execution time of a task, the task is dequeued and its action closure is executed in the current frame.

[0057] The Web3D zero-code interaction design method based on a unified model, using the aforementioned platform, includes the following steps:

[0058] S1. Project creation and environment initialization: The user logs into the platform, creates a new 3D interactive application project, initializes an empty UBLM structure, and loads the default 3D scene template or the scene resources uploaded by the user. The editor interface is ready.

[0059] S2. The dual-mode visual definition of business logic, including:

[0060] S2.1 When the user selects a form mode, a blank form is rendered based on the current empty UBLM. The user can fill in the events, conditions and actions in the form by clicking "Add Rule" to define the first interaction logic, that is, to define the rule. Each input is converted into an update of the UBLM in real time.

[0061] S2.2 The user switches to Blueprint mode to view a graphical representation of the logic; DMAE immediately renders the rules defined in the form into a logic diagram consisting of event nodes, condition decision nodes, and action sequence nodes connected by lines; allowing the user to continue editing in the Blueprint interface;

[0062] S2.3 When a user selects a new node in the blueprint, they can configure specific buttons and actions in the node properties panel; at the same time, a corresponding rule row is automatically added to the form interface, and the content is completely synchronized.

[0063] S3. Real-time verification and iteration: During the editing process, users can click the "Instant Preview" button at any time. When clicked, the UBLM data currently being edited is instantly transmitted to IREE. IREE executes the compilation process of the initialization phase in an isolated preview context, and then starts a lightweight preview scene, allowing users to interact with the scene immediately and test whether the defined rules work as expected.

[0064] If a problem is found, make adjustments directly in the current editing interface. Changes to UBLM will be synchronized to all views via a "Model Updated" notification.

[0065] S4. Project Building and Final Release: After completing all logical design, the user executes the "Release" command.

[0066] S4.1 Perform final verification and optimization of UBLM;

[0067] S4.2 Front-end construction: Package UBLM, 3D scene resources, the IREE core library stripped from the editor runtime, and a lightweight 3D renderer shell together into a static web application.

[0068] S5. Terminal operation: The end user accesses the published web application through a browser. After loading, the IREE inside the application executes the initialization pre-compilation process, and then enters the runtime phase and enters the running loop.

[0069] As a preferred embodiment of the present invention, after S4.2, it further includes:

[0070] S4.3 If the logic includes actions that require server-side interfaces, automatically generate the corresponding API call code snippets according to the definitions in UBLM and integrate them into the packaged artifacts, or provide interface documentation.

[0071] The beneficial effects of this invention are:

[0072] This invention significantly lowers the development threshold for 3D business logic by constructing a unified business logic model and combining it with a browser-based no-code editing mode. No technical personnel are required to master underlying technology frameworks such as WebGL and Three.js; business personnel without technical backgrounds can directly build 3D business logic that meets their needs through visual operations, greatly expanding the scope of development participants. At the same time, the unified business logic model provides standardized logical support for different business scenarios, enabling direct reuse of logic modules across projects, effectively reducing redundant development work, and significantly improving the development efficiency and deployment speed of 3D business logic.

[0073] This invention optimizes the iteration and maintenance process of 3D business logic, and is deeply adapted to no-code editing solutions. The editing process eliminates the need for complex code writing, compilation, and deployment, supports real-time debugging and rapid modification, and can quickly respond to frequent changes in business requirements, shortening the iteration cycle. Simultaneously, standardized editing tools and a unified model architecture reduce logical vulnerabilities caused by human error, improve code (logic) readability and scalability, and lower later maintenance costs. In cross-team collaboration, standardized operations and logical expressions also reduce communication disagreements, improve collaboration efficiency, and provide strong support for the large-scale deployment of browser-based 3D services. Attached Figure Description

[0074] Figure 1 This is a schematic diagram of the overall three-layer architecture of the platform of this invention;

[0075] Figure 2 This is a flowchart illustrating the real-time synchronization of the status of the form-based editor and the blueprint-based editor in the platform of this invention.

[0076] Figure 3 This is a schematic diagram of the editing interface of the form-based editor of the platform of this invention;

[0077] Figure 4 This is a schematic diagram of the editing interface of the blueprint-based editor of the platform of this invention;

[0078] Figure 5 This is a flowchart illustrating the method of the present invention. Detailed Implementation

[0079] The embodiments of the present invention will be further described below with reference to the accompanying drawings:

[0080] Example 1: As Figure 1 As shown, the Web3D zero-code interactive design platform based on a unified model includes:

[0081] The Unified Business Logic Model (UBLM) is a platform-independent, self-describing, structured data container used to fully define all behavioral logic in 3D interactive applications, including events, conditions, actions, parameters, variables, and process relationships.

[0082] The dual-mode editor DMAE includes a form-based editor and a blueprint / node-based editor. Both editors can fully create, edit, and visualize the same UBLM and achieve real-time state synchronization. DMAE includes the MDIR rendering engine, and the editing interface dynamically generates views based on the current UBLM data. Any user interface operation is directly translated into modification instructions for the underlying UBLM.

[0083] IREE, an interpreted rule execution engine, is a lightweight engine that runs in a browser JavaScript environment. It is responsible for parsing UBLM at runtime and converting declarative logic into executable instructions in the 3D scene through rule matching and function registration mechanism (a programming technique used to dynamically register functions at runtime and call these functions when needed).

[0084] DMAE enables two visual editing experiences for the same UBLM. Its core is a mechanism called "Model-Driven Interface Rendering (MDIR): the editing interface is not static, but a dynamically generated "view" based on the current UBLM data; any user interface operation is directly translated into modification instructions for the underlying UBLM. The editing interface (whether it's form input fields or blueprint nodes and connections) is dynamically "back-engineered" from the current UBLM data, eliminating the need to maintain independent interface state data and ensuring "what you see is what you get."

[0085] Figure 1 In this embodiment, the core structure and flow of the platform are as follows:

[0086] Presentation layer: Includes a dual-mode editor (form-based / blueprint-based) and an MDIR rendering engine. Users modify logic through the editor → update UBLM → the MDIR rendering engine detects the changes → drives the two editor interfaces to refresh in real time, forming an editing loop.

[0087] Data Layer: The Unified Business Logic Model (UBLM), as the platform's sole source of JSON facts, is located at the very center of the architecture, connecting all data read and write operations between the editing and runtime phases.

[0088] Execution Layer: Rule Execution Engine (IREE) and 3D Scene Runtime (WebGL). The platform loads UBLM → IREE performs pre-compilation and function registration → the runtime receives events and triggers actions → real-time 3D rendering and interaction are achieved through WebGL. In the 3D scene runtime, real-time rendering of 3D content is achieved using WebGL, a JavaScript API that can render high-performance interactive 3D and 2D graphics in any compatible web browser without the need for plugins.

[0089] The main data flow of the platform in this embodiment is:

[0090] Editing phase: User modifications → UBLM ←→ MDIR ←→ Editor (real-time two-way synchronization);

[0091] Execution phase: UBLM → IREE → WebGL (Event-driven execution);

[0092] Scene state feedback: WebGL→UBLM (variable update, state change write-back).

[0093] UBLM serves as the single source of truth for data exchange, UI rendering, and logic execution within the platform. It stores rules by "describing what the logic is" rather than "specifying how the execution steps are," which forms the basis for enabling cross-modal editing and efficient interpretation.

[0094] This embodiment systematically solves the technical challenge of current browser-based 3D no-code development tools in balancing editing flexibility, data consistency, development efficiency, and runtime performance by constructing a centralized, declarative data model (UBLM) and designing an editing interface capable of bidirectional real-time synchronization and a high-performance execution engine decoupled from the rendering frame rate. The core innovative architecture can be summarized as "one core, two facets, one engine." "One core" refers to the unified business logic model (UBLM) as the single source of facts; "two facets" refer to the two interactive interfaces—a form-based editor and a blueprint-based editor—driven by the same core and capable of real-time synchronization; and "one engine" refers to the interpreted rule execution engine (IREE) that efficiently transforms the declarative model into runtime instructions. These three elements work together to form a complete closed loop from visual design to efficient execution.

[0095] In UBLM, a UBLM document is logically a complete logical definition of a project. It is serialized and exchanged using JSON format. The root structure of a UBLM document contains the following parts:

[0096] The metadata area contains management information such as UBLM version number, project name, unique identifier, creation and modification timestamps, which are used to ensure version compatibility and project management.

[0097] The global resource declaration area includes a variable pool and an object reference mapping table: The variable pool defines one or more global variables, each containing a name, data type (such as integer, boolean, string), initial value, and optional descriptive information. These variables can be shared and modified between different rules and are used to record game state, score, on / off status, etc. The object reference mapping table maintains a mapping relationship from logical identifiers (such as "player", "door_01") to specific object instance IDs in the actual 3D scene. This decouples the logic layer from the rendering layer, allowing scene resources to be changed without modifying the logic rules.

[0098] The core rules collection area is an array that contains all the business logic rules in the project. Each rule is an independent "event-condition-action" logical unit.

[0099] The detailed structure of the "Event-Condition-Action" logic unit in the core rule set area is as follows:

[0100] Rule identifiers and metadata, including a unique rule ID, a user-defined readable name, group labels, and enable / disable switches;

[0101] The event descriptor body contains:

[0102] The event type enumeration value is rule.event.type, such as OBJECT_CLICK (object click), COLLISION_ENTER (collision start), TIMER_EVENT (timed trigger), VARIABLE_CHANGED (variable change), etc.

[0103] The target object of the event is rule.event.target, which is a logical identifier in the object reference mapping table. For events without a specific target (such as global timers), this field can be empty.

[0104] And event-specific parameter objects rule.event.parameters, for example, for KEYBOARD_EVENT, the parameter might be {"keyCode":32} representing a space key; for COLLISION_ENTER, the parameter might contain a reference to the object that collides with the other party.

[0105] The execution condition set is an array of conditional expressions that defines all the prerequisites that must be met for an action to be executed after a rule is triggered. All conditions are related by default using an AND operation. Each condition is an object containing:

[0106] The condition type is rule.conditions.type, such as VARIABLE_COMPARE (variable comparison), OBJECT_PROPERTY_CHECK (object attribute check), and SCENE_STATE_QUERY (scenario status query).

[0107] Operators and operands: depending on their type, operands can be variable references, object property paths, or literal values; operators are ==, >, <=, contains, isVisible, etc.

[0108] The Boolean value `negated` indicates whether the condition result is negated.

[0109] An action sequence is an array of action description objects that defines a series of operations to be executed sequentially when an event is triggered and all conditions are met. Each action object contains:

[0110] Action type rule.action.type, such as TRANSLATE_OBJECT (move an object), ROTATE_OBJECT (rotate an object), PLAY_ANIMATION (play an animation), SET_VARIABLE (set a variable), SHOW_MESSAGE (display UI information), CREATE_OBJECT (dynamically create an object), etc.

[0111] The target object to which the action is applied is referenced as rule.action.target;

[0112] The specific parameters of an action, `rule.action.parameters`, are highly dependent on the action type. For example, parameters for a movement action might include target coordinates, movement duration, and easing function type; parameters for a play sound action might include sound effect resource ID, volume, and whether to loop.

[0113] A floating-point number delay, where delay represents the delay time (in seconds) between the triggering of the rule and the completion of the previous action, is used to orchestrate complex timing logic.

[0114] The UBLM structure is entirely defined by JSON Schema, ensuring the rigor and verifiability of the data, and serving as the sole authoritative data source for all module read and write operations within the platform.

[0115] In DMAE, the form-based editor provides a linear interface similar to a table or attribute list, suitable for quickly entering and modifying rule details. The working mechanism of the form-based editor includes view generation and user interaction processing:

[0116] View generation: When the user enters form mode, iterates through the core rule set area of ​​UBLM, creating a collapsible rule card for each rule. Within the rule card:

[0117] For the event descriptor, based on the value of rule.event.type, render a non-editable static label or icon to display the event type. Next to the static label or icon is an object selector control whose list of possible values ​​comes from an object reference map, and the currently selected item is bound to rule.event.target.

[0118] For each set of execution conditions, render a row for each condition object. The row contains: a variable / property selector that binds to the left operand of the condition, an operator dropdown that binds to Operators, a value input control that binds to the right operand, and an "Add Condition" button that allows inserting new empty condition objects to the end of the array.

[0119] For each action sequence, an area is rendered for each action object, including: an action type dropdown bound to rule.action.type, a target selector bound to rule.action.target, an "Add Action" button and a "Move Up / Move Down" button for managing the action sequence, and a dynamic parameter panel. The dynamic parameter panel dynamically renders the required input controls based on the currently selected action type, including numeric input boxes, resource selectors, color selectors, text input boxes, and custom attribute selectors. Each input control is precisely bound to the corresponding field in the rule.action.parameters object.

[0120] User interaction handling: User modifications to any input box or dropdown will not directly change the displayed values ​​in the UI. Instead, they will trigger an update event with precise path information. For example, if a user modifies the X-coordinate parameter of the first action under the first rule, the platform will generate an event: {operation:'UPDATE',path:'rules[0].actions[0].parameters.x',value:newValue}.

[0121] The Blueprint editor provides a node- and connection-based graphical canvas, suitable for visualizing logical flows and macro-level architectures. The Blueprint editor's working mechanism also includes view generation and user interaction handling.

[0122] View generation: When a user enters Blueprint mode, a transformation from UBLM to a node diagram is performed, including:

[0123] Node mapping: Each rule is mapped to a composite node, or split into event nodes, condition judgment node groups, and action sequence nodes according to the configuration. Each node has its position information on the canvas (this information is stored separately as view state and is not part of UBLM).

[0124] Port generation: Event nodes have "output" ports; condition judgment nodes have "input" and "output" ports; action sequence nodes have "input" ports. These ports represent the execution flow of the logic.

[0125] Connection generation: Based on the inherent logical order of the rules (checking conditions after an event is triggered, and executing actions after the conditions are met), connections are generated between the corresponding node ports, and the connections represent the transmission of control flow;

[0126] User interaction processing: User actions on the Blueprint are translated into structured modifications to the UBLM, including dragging and dropping connections, deleting connections, and modifying nodes in the Attributes panel.

[0127] Drag and drop connections: Dragging a connection from the output port of one node to the input port of another node may mean creating a new logical dependency. The platform needs to determine the legality of the operation (e.g., it is not permissible to connect the output of an action node to the input of an event node), and then generate an update event for the UBLM, such as adding a new condition check to the condition of a rule, or establishing a variable dependency between two rules.

[0128] Deleting a connection means removing a logical dependency, which corresponds to deleting a condition or action parameter in UBLM.

[0129] Modifying in the properties panel is completely equivalent to modifying in the form, generating the same path update event.

[0130] like Figure 2 As shown, the real-time synchronization of the states of the form-based editor and the blueprint-based editor is achieved as follows:

[0131] Central Event Bus and Model Manager: A central event bus and a UBLM manager are established. The UBLM manager holds the current version of the UBLM data and is responsible for processing all legitimate update events.

[0132] Submitting an update: When a user performs an action on a form or blueprint, a "patch" instruction describing the data change is generated and submitted to the UBLM manager via the central event bus;

[0133] Atomized model update: After receiving a "patch", the UBLM manager applies the received "patch" to the current UBLM in an immutable data update manner, generating a brand new UBLM data snapshot with an incrementing version number; then, the UBLM manager broadcasts a "model updated" notification through the central event bus, which carries the change path information and a comparison of the old and new values;

[0134] Perform interface subscription and incremental updates, including:

[0135] Both the form-based editor and the blueprint-based editor act as subscribers, listening for "model updated" notifications;

[0136] For both active interfaces (e.g., users interacting with a form) and inactive / background interfaces (e.g., the Blueprint editor is in another browser tab or minimized), upon receiving a notification, the form editor's internal rendering engine precisely locates the UI components that need updating based on the changed path. It doesn't re-render the entire form, but only updates the value of that specific coordinate input box, resulting in a high-performance incremental update. Upon receiving a notification, the Blueprint editor's internal rendering engine performs the following operations:

[0137] Data mapping recalculation: Based on the new UBLM, the logical relationships of nodes, ports, and connections are recalculated; Topology update: If the change involves the addition or deletion of rules or a significant change in logical relationships (such as the removal of a condition causing a connection to become meaningless), the rendering engine automatically adds or deletes nodes or removes invalid connections; Layout optimization: To maintain a clean visualization, the rendering engine triggers a lightweight automatic layout algorithm (such as iterative force-directed layout) to adjust the positions of affected node areas, avoiding node overlap. The final node position is saved as the view state, separated from the UBLM;

[0138] Because both the form-based and blueprint-based editors render based on the same up-to-date UBLM data, they maintain strict consistency at the data level. Users experience a seamless transition when switching views; the entire process typically takes only a few hundred milliseconds and is imperceptible to the user.

[0139] Figure 2 In the current active editing mode (form mode or blueprint mode), users can perform any data modification operation (such as changing condition parameters, adding / deleting actions, adjusting rule order, dragging and dropping lines, etc.). Regardless of whether the operation occurs in a form-based editor or a blueprint-based editor, the platform translates user interactions into unified, clearly defined "data patch" instructions, for example:

[0140] operation:'UPDATE',path:'rules[2].actions[1].parameters.x',value:45.0}).

[0141] This patch does not depend on any specific interface; it only describes the precise changes to the UBLM data model.

[0142] Changes are submitted via the Central Event Bus: All patch instructions are sent to the system's Central Event Bus, decoupling the editing interface from the core data management layer.

[0143] Atomic updates by the UBLM Manager: After receiving a patch, the UBLM Manager applies the changes using immutable data, generating a complete snapshot of the UBLM data with the new version number. This step ensures the atomicity, consistency, and traceability of data modifications.

[0144] Broadcast "Model Updated" notification: The manager broadcasts the model update event to all subscribers (including the currently active editor and the background editor) via the event bus. The notification carries the specific path of the change and the comparison information between the old and new values, which makes it easy for the recipient to perform an efficient partial refresh.

[0145] The editor responds differently based on its own state:

[0146] For the current activity mode (current activity interface): Upon receiving a notification, only incremental updates are performed on the affected UI controls, such as refreshing a single input box or node property panel, to avoid full redrawing and ensure smooth operation.

[0147] For inactive mode (inactive interface) / background view: Perform a more comprehensive recalculation and rendering process, including: remapping nodes, ports and connection topology according to the latest UBLM; removing or adding graphical elements that have become invalid or added due to data changes; triggering a lightweight automatic layout algorithm to optimize the node positions in affected areas and prevent visual overlap or confusion.

[0148] After the above steps, the form-based and blueprint-based editing interfaces achieve strict consistency at the logical data level. Users can enjoy a seamless and imperceptible continuous editing experience when switching views at any time.

[0149] IREE aims to transform declarative UBLM into business logic code that runs directly in the browser. IREE employs a pre-compiled architecture combined with event-driven principles, decoupling logical complexity from runtime calculations per frame. The execution flow of IREE includes:

[0150] Phase 1, Initialization Phase: Pre-compilation and registration are performed. When the user clicks the "Run" or "Preview" button set in the global common operation area of ​​DMAE, IREE starts working and executes the following steps:

[0151] Model loading and parsing: IREE reads the project's UBLM JSON from persistent storage and parses it into an in-memory object;

[0152] Create runtime context: Initialize a RuntimeContext object, which contains copies of the values ​​of all current global variables, scene object access interfaces, and an event emitter for cross-rule communication;

[0153] Rule traversal and functionization: This is the core "pre-compilation" process. IREE traverses each enabled rule in the core rule set area, and for each set of execution conditions, it compiles it into a pure JavaScript function. For example, a condition that checks if the variable `score` is greater than 100 and the object `enemy` is visible will be compiled into a function similar to the following:

[0154] JavaScript

[0155] function conditionCheck_rule001(context) {

[0156] return context.variables['score']>100&&

[0157] context.scene.getObject('enemy').visible === true;

[0158] }

[0159] This function is created once during initialization, and every subsequent check directly calls this efficient function, avoiding repeated parsing and traversal of JSON.

[0160] For action sequences, IREE creates a closure function for each action that knows how to execute the action, and then wraps the closure function into a schedulable action chain function according to the sequence and delay parameters; this function knows how to interact with the 3D engine API.

[0161] Rule wrapper creation: Package the pure JavaScript function and action chain function together with the description information of the triggering event of the rule to create a rule processor object;

[0162] Establishing an event-rule index: IREE registers rule processor objects into a multi-level hash map table based on the `rule.event.type` and `rule.event.target` of each rule; for example, `Map<'OBJECT_CLICK', Map<'cube_red', [ruleProcessor1, ruleProcessor2] >>`. This establishes a direct index from scene events to rules to be processed, which is key to achieving efficient runtime retrieval.

[0163] Phase Two, Runtime Phase (Event-Driven and Scheduled Execution): Entering the runtime loop, IREE and the 3D rendering engine work together to execute the following steps:

[0164] Event Injection: When the 3D rendering engine detects an interactive event (mouse click, collision, etc.) in its own update loop, it does not directly process the logic. Instead, it standardizes the event and passes it to IREE through a predefined interface; for example: {type:'objectClick',targetId:'cube_red',coordinates:{x,y}}.

[0165] Event routing and rule retrieval: IREE's event listeners receive standardized event objects and use the event type and target ID as keys to query the event-rule index mapping table. In constant time, they can obtain a list of all rule processor objects that have subscribed to this specific event, avoiding traversing all rules.

[0166] Synchronous condition validation: IREE synchronously and sequentially calls the pure JavaScript function of each rule processor in the list, passing in the current RuntimeContext object; the condition check is calculated in pure JavaScript, which is extremely fast.

[0167] Asynchronous scheduling of actions: For rules that return true for all conditions, IREE introduces a time-based scheduler to begin processing its action chain, specifically:

[0168] For each action closure with delay in the action chain, IREE calculates its absolute execution time (current time + delay).

[0169] IREE encapsulates these action closures and their absolute execution times into scheduling tasks and inserts them into a priority queue (min-heap) sorted by execution time.

[0170] The priority queue is driven by the browser's requestAnimationFrame. Before each frame is rendered, IREE checks the head of the queue. If the current time has reached or exceeded the execution time of a task, the task is dequeued and its action closure is executed in the current frame.

[0171] Action execution and state update: The action closure being executed contains code that calls the 3D rendering engine API. These calls directly affect the rendering tree, producing visual or auditory feedback. At the same time, actions like SET_VARIABLE modify the values ​​of variables in the RuntimeContext. This modification takes effect immediately and may affect the condition judgment of other rules in the future.

[0172] Looping and Cleanup: The steps described above in the runtime phase continue throughout the application's lifecycle. When the scene changes or the application stops, IREE unregisters all event listeners, clears the scheduling queue and index table, and releases resources.

[0173] The core of IREE's performance design includes:

[0174] Startup overhead: complexity O(N), where N is the number of rules, occurs during loading, and is acceptable to the user.

[0175] Runtime overhead: The overhead per frame mainly depends on: a) the number of events E triggered in that frame; b) the number of rules M associated with each event; and c) the number of tasks that have expired in the scheduling queue K. The overhead is approximately O(E*M+K). This is independent of the total number of rules N. Even with thousands of rules, as long as no events are triggered or only a few events are triggered in the current frame, the runtime overhead is extremely low, thus ensuring a smooth rendering frame rate.

[0176] No interpretation overhead: It completely avoids parsing JSON or performing complex AST traversal in runtime loops; all logic is compiled into functions that can be executed directly.

[0177] This platform is particularly suitable for scenarios requiring rapid development, iteration, and deployment of business logic for 3D interactive applications (such as games, virtual simulations, digital twins, and interactive teaching resources) in a browser environment. It can provide two (or more) editing interfaces with distinct interaction paradigms but equivalent functionality, achieving zero-loss, real-time bidirectional synchronization between them to meet the needs of users with different skill levels. A self-contained, declarative logical description model is designed, serving as the sole data source for rendering and execution engine parsing of all editing interfaces, thereby eliminating the complexity of state synchronization and simplifying the platform architecture. An execution mechanism is designed so that the complexity of business logic primarily affects the initial loading time of the project, without placing linear pressure on the rendering performance (FPS) of each frame during runtime, thus ensuring smooth interaction in complex scenes. The entire editing, previewing, and debugging process can be built into a standard browser environment without plugins or clients, supporting cross-platform instant access and collaboration.

[0178] An example of a form-based editor's editing interface is as follows: Figure 3 As shown, Figure 3 In the middle, on the left is the management list of rule groups, used to classify different logics. It can be grouped and managed, supporting multiple groups such as "Rule Group 1, 2, 3", and also allows for quick operations. Each group is equipped with "Copy" and "Delete" buttons, making it convenient for users to quickly reuse existing rule configurations.

[0179] The main panel on the right is the rule list, which is the core area of ​​the form-style editor. It uses a hierarchical structure (tree-like collapse) to display the specific rule logic, including basic rule information, triggering and judgment logic, and specific actions.

[0180] Basic rule information includes:

[0181] Collapse / Expand: Clicking the header allows you to expand or collapse complex rules to save space;

[0182] Copy / Delete: Full cloning or removal can be performed at the rule level;

[0183] The triggering and judgment logic includes:

[0184] Listening type: Currently displayed as "Variable Listening", which means that the system will monitor changes in specific data in real time;

[0185] Triggering condition: The initial action of the startup rule (e.g., when variable 1 changes);

[0186] Judgment conditions: Supports logical operators (AND / OR); supports multi-dimensional filtering. Figure 3 The text demonstrates the evaluation of "variables" and "labels"; the conditional expression uses a combination of "object + operator (equal to) + number / label value".

[0187] The specific actions are the preset behaviors that the platform executes when the above conditions are met, including:

[0188] Action group: for example Figure 3 The display shows "camera events"; specific actions include "teleportation"; parameter configuration allows for detailed settings of the object (free camera) performing the action and the target coordinates (position: 0,0,0).

[0189] An example blueprint-based editor's editing interface is as follows: Figure 4 As shown, Figure 4 In the middle, the resource / function category area on the left provides usable functional module categories, including Mesh (model), GUI (interface), camera, audio, etc., supporting single-object and multi-object logical configuration, making it easy to quickly locate the required functions.

[0190] The top operation bar contains function buttons such as save, refresh, node query, import group, and preset template, which are used to manage the currently edited logic configuration and support quick reuse of preset logic or import of saved logic groups.

[0191] The logic orchestration area on the right implements logic through combinations of nodes and connections, including:

[0192] Monitor variable changes: As a trigger source, multiple "mandatory judgment (or)" conditions can be set. When a variable meets any of the conditions, subsequent logic is triggered.

[0193] Variable evaluation: Perform a conditional evaluation on a specified variable (such as "variable 1") (e.g., equal to 1), and execute subsequent logic based on the result.

[0194] Arc-shaped rotating camera: The controlled camera node.

[0195] Instant camera movement: The camera jumps directly to the target coordinates (e.g., (0,0,0)) based on the specific parameters of the action.

[0196] Example 2:Figure 5 As shown, the Web3D zero-code interaction design method based on a unified model, using the platform in Example 1, includes the following steps:

[0197] S1. Project creation and environment initialization: The user logs into the platform, creates a new 3D interactive application project, initializes an empty UBLM structure, and loads the default 3D scene template or the scene resources uploaded by the user. The editor interface is ready.

[0198] S2. The dual-mode visual definition of business logic, including:

[0199] S2.1 When the user selects a form mode, a blank form is rendered based on the current empty UBLM. The user can fill in the events, conditions and actions in the form by clicking "Add Rule" to define the first interaction logic, that is, to define the rule. Each input is converted into an update of the UBLM in real time.

[0200] S2.2 The user switches to Blueprint mode to view a graphical representation of the logic; DMAE immediately renders the rules defined in the form into a logic diagram consisting of event nodes, condition nodes, and action sequence nodes connected by lines; allowing the user to continue editing in the Blueprint interface; for example, creating a new "keyboard press" event node from the node library onto the canvas, which will create an empty shell of a new rule in UBLM.

[0201] S2.3 When a user selects a new node in the blueprint, they configure specific buttons and actions in the node properties panel (isomorphic to the form). This configuration process, just like editing in the form, continuously updates the UBLM. Simultaneously, a corresponding rule row is automatically added to the form interface, with completely synchronized content.

[0202] S3. Real-time verification and iteration: During the editing process, users can click the "Instant Preview" button at any time. When clicked, the UBLM data currently being edited is instantly transmitted to IREE. IREE executes the compilation process of the initialization phase in an isolated preview context, and then starts a lightweight preview scene, allowing users to interact with the scene immediately and test whether the defined rules work as expected.

[0203] If a problem is found, adjustments can be made directly in the current editing interface. Changes to UBLM will be synchronized to all views via a "Model Updated" notification. The preview scene may also be partially updated through a hot reload mechanism, enabling a fast edit-verification cycle.

[0204] S4. Project Building and Final Release: After completing all logical design, the user executes the "Release" command.

[0205] S4.1 Perform final verification and optimization of UBLM;

[0206] S4.2 Front-end construction: Package UBLM, 3D scene resources, the IREE core library stripped from the editor runtime, and a lightweight 3D renderer shell together into a static web application (HTML + JS + resource files).

[0207] S4.3 If the logic includes actions that require server-side interfaces (such as saving scores or synchronizing multiple users), the corresponding API call code snippets will be automatically generated according to the relevant definitions in UBLM and integrated into the packaged artifacts, or an interface documentation will be provided.

[0208] S5. Terminal operation: End users access the published web application through a browser. After loading, the application's internal IREE executes the initialization pre-compilation process, and then enters the runtime phase, entering the running loop. All interaction logic runs accurately and efficiently according to the UBLM defined by the designer in the no-code editor, providing users with a complete 3D interactive experience.

[0209] Compared with existing technologies (such as Construct3 event tables + Rete.js node editor concatenation), the method of this embodiment is:

[0210] In terms of data modeling, existing technologies use two sets of data: event table data and node graph data (including layout information), which need to be converted and synchronized. The method in this embodiment is a single UBLM, which is both the storage format and the source for editing and execution, simplifying the architecture by more than 60%.

[0211] In terms of mode switching, existing technologies require data conversion, which may result in information loss or delay, and non-real-time synchronization. The method in this embodiment can switch seamlessly in real time, based on the MDIR mechanism, with a switching latency of less than 100ms and 100% data consistency.

[0212] In terms of user experience and efficiency, existing technologies require users to switch between different tools, resulting in a steep learning curve and fragmented context. This embodiment's method is adaptable to different user habits; beginners can quickly get started with forms, while experts can optimize the process using blueprints. Overall editing efficiency is estimated to improve by over 40%.

[0213] In terms of runtime performance, the increased logic complexity of existing technologies directly leads to increased script interpretation overhead per frame, resulting in a significant drop in frame rate. This embodiment decouples complexity from frame rate; tests show that under 100+ rules, the frame rate remains stable above 59fps, with a performance degradation of less than 3%.

[0214] In terms of deployment and collaboration, existing technologies may rely on specific plugins or clients, making the collaboration process complex. This embodiment offers a pure browser solution that supports cross-platform instant access and real-time collaboration (based on WebSocket synchronous UBLM).

[0215] Two application examples based on the method of this embodiment are as follows:

[0216] Example 1: Creation and execution of an "move to a specified location" interactive logic;

[0217] Scenario: The user needs to implement the following: "When the cube is clicked, if variable BL1 equals 5, then after 5 units of time, it moves 10 units in the direction (0,1,1).

[0218] Step 1 (Creating a Form):

[0219] a. In the form editor, click "Add Rule".

[0220] b. Select OnMeshPick from the "Events" drop-down menu. The parameter panel will pop up automatically. Select the "Cube" in the scene as the mesh parameter.

[0221] c. In the "Conditions" section, click "Add Condition", enter BL1 as the variable name, select == as the operator, and enter 5 as the comparison value.

[0222] d. Select TranslateByDirection from the “Action” drop-down menu, and fill in distance:10, direction:(0,1,1).

[0223] e. In the "Advanced" settings, set delay:5.

[0224] At this point, all inputs have been updated to the underlying UBLM in real time.

[0225] Step 2 (Switch to Blueprint mode to view):

[0226] The user clicks the "Blueprint View" tab.

[0227] The reverse rendering engine works immediately: it reads the current UBLM, generates an OnMeshPick (cube) event node, a Condition(BL1==5) decision node, a Delay(5) delay node and a TranslateByDirection(10,(0,1,1)) action node on the canvas, and connects them in sequence with connecting lines.

[0228] Expert users can directly drag Delay nodes in the Blueprint view before the conditional statements to change the execution order. This change will also be immediately written back to UBLM and the rule order in the form view will be updated synchronously.

[0229] Step 3 (Running Process and Performance Monitoring):

[0230] Click "Run". IREE loads UBLM and registers a listener for the OnMeshPick event. This listener contains condition checks, delayed scheduling, and action execution functions.

[0231] The user clicks on the cube in the 3D view. An event is triggered, and IREE performs a check (BL1==5?). If it passes, it waits for 5 time units and then calls a pre-registered function to perform a translation transformation.

[0232] Performance monitoring: Even if there are hundreds of similar rules in the platform, due to IREE's pre-registration mechanism, the response time of the click event depends only on the number of rules that are triggered, and is not related to the total number of rules, thus maintaining a high frame rate.

[0233] Example 2: Complex branching logic in virtual teaching experiments;

[0234] Scenario: In chemical experiment simulation, it is required to trigger a variety of different reaction results and scores based on different user operation sequences and reagent dosages.

[0235] Application: Teachers can use the form mode to quickly build numerous "event-condition-action" rules and define various branches. During debugging, switching to blueprint mode allows for a macro-level review of the topology of all logical branches, identifying and optimizing redundant or conflicting conditional judgments, resulting in a more efficient logic diagram. This dual-mode collaboration significantly improves the efficiency of constructing and optimizing complex teaching scenarios.

[0236] Test data and performance verification: The test results for projects of different complexities are shown in Table 1 under Chrome 140+, Intel i5 / 16GB configuration.

[0237] Table 1 Test results for projects of different complexities

[0238]

[0239] Test data fully validates the core advantages of the method in this embodiment: the complexity of business logic is effectively stripped from the computational load of each frame at runtime and transferred to the loading and initialization phase. This allows developers to build highly complex interactions without worrying about runtime performance crashes, breaking through the capabilities of browser-based no-code 3D applications.

Claims

1. A Web3D zero-code interactive design platform based on a unified model, characterized in that, include: The Unified Business Logic Model (UBLM) is a platform-independent, self-describing, structured data container used to fully define all behavioral logic in 3D interactive applications, including events, conditions, actions, parameters, variables, and process relationships. The dual-mode editor DMAE includes a form-based editor and a blueprint-based editor. Both editors can fully create, edit, and visualize the same UBLM and achieve real-time state synchronization. DMAE includes the MDIR rendering engine, and the editing interface dynamically generates views based on the current UBLM data. Any user interface operation is directly translated into modification instructions for the underlying UBLM. A form-based editor provides a linear interface. The working mechanism of a form-based editor includes view generation and user interaction processing. Its user interaction processing means that the user's modification operation in any input box or drop-down box will not directly change the UI display value, but will trigger an update event with precise path information. The Blueprint Editor provides a graphical canvas based on nodes and connections. The working mechanism of the Blueprint Editor also includes view generation and user interaction processing. Its view generation is as follows: when the user enters Blueprint mode, a transformation from UBLM to node graph is performed, including node mapping, port generation and connection generation. The real-time synchronization of the states of form-based editors and blueprint-based editors is achieved as follows: Establish a central event bus and a UBLM manager. The UBLM manager holds the current version of the UBLM data and is responsible for processing all legitimate update events. When a user performs an operation on a form or blueprint, a "patch" instruction describing the data change is generated and submitted to the UBLM manager via the central event bus. After receiving a "patch", the UBLM manager applies the received "patch" to the current UBLM in an immutable data update manner, generating a brand new UBLM data snapshot with an incrementing version number; then, the UBLM manager broadcasts a "model updated" notification through the central event bus, which carries the change path information and a comparison of the old and new values; Perform interface subscription and incremental updates, including: Both the form-based editor and the blueprint-based editor act as subscribers, listening for "model updated" notifications; For both active and inactive / background interfaces, after receiving a notification, the form-based editor's internal rendering engine precisely locates the UI components that need updating based on the change path; after receiving a notification, the blueprint-based editor's internal rendering engine performs the following operations: Data mapping recalculation: Based on the new UBLM, the logical relationships of nodes, ports, and connections are recalculated; Topology update: If the change involves the addition or deletion of rules or changes in logical relationships, the rendering engine automatically adds or deletes nodes or removes invalid connections; Layout optimization: The rendering engine triggers a lightweight automatic layout algorithm to adjust the positions of affected node areas to avoid node overlap. The final position of the nodes is saved as the view state and is separated from the UBLM. Because both the form-based editor and the blueprint-based editor render based on the same up-to-date UBLM data, they maintain strict consistency at the data level. IREE is an interpreted rule execution engine, a lightweight engine that runs in the browser's JavaScript environment. It is responsible for parsing UBLM at runtime and converting declarative logic into executable instructions in the 3D scene through rule matching and function registration mechanisms.

2. The Web3D zero-code interactive design platform based on a unified model according to claim 1, characterized in that, In UBLM, a UBLM document is logically a complete logical definition of a project. It is serialized and exchanged using JSON format. The root structure of a UBLM document contains the following parts: The metadata area contains the UBLM version number, project name, unique identifier, and creation and modification timestamps; The global resource declaration area includes a variable pool and an object reference mapping table: The variable pool defines one or more global variables, each of which contains a name, data type, initial value, and optional descriptive information, where the data type includes integer, boolean, and string; The object reference mapping table maintains a set of mapping relationships from logical identifiers to specific object instance IDs in the actual 3D scene; The core rules collection area is an array that contains all the business logic rules in the project. Each rule is an independent "event-condition-action" logical unit.

3. The Web3D zero-code interactive design platform based on a unified model according to claim 2, characterized in that, The detailed structure of the "Event-Condition-Action" logic unit in the core rule set area is as follows: Rule identifiers and metadata, including a unique rule ID, a user-defined readable name, group labels, and enable / disable switches; The event descriptor contains the event type enumeration value rule.event.type, the event target object rule.event.target, and the event-specific parameter object rule.event.parameters, where rule.event.target references the logical identifier in the mapping table; The execution condition set is an array of conditional expressions that defines all the prerequisites that must be met for an action to be executed after a rule is triggered. All conditions are connected by an "AND" relationship by default. Each condition is an object that contains a condition type (rule.conditions.type), operators (Operators), operands (Operands), and a boolean value (negated), where negated indicates whether the condition result is negated. An action sequence is an array of action description objects that defines a series of operations to be executed in sequence when an event is triggered and all conditions are met. Each action object contains an action type (rule.action.type), a reference to the target object to which the action is applied (rule.action.target), specific action parameters (rule.action.parameters), and a floating-point number (delay), where delay represents the delay time for the action to be executed relative to the triggering of the rule or the completion of the previous action.

4. The Web3D zero-code interactive design platform based on a unified model according to claim 3, characterized in that, In DMAE, the form-based editor provides a linear interface suitable for quickly entering and modifying rule details. The working mechanism of the form-based editor includes view generation and user interaction processing: View generation: When the user enters form mode, iterates through the core rule set area of ​​UBLM, creating a collapsible rule card for each rule. Within the rule card: For the event descriptor, based on the value of rule.event.type, render a non-editable static label or icon to display the event type. Next to the static label or icon is an object selector control whose list of possible values ​​comes from an object reference map, and the currently selected item is bound to rule.event.target. For each set of execution conditions, render a row for each condition object. The row contains: a variable / property selector that binds to the left operand of the condition, an operator dropdown that binds to Operators, a value input control that binds to the right operand, and an "Add Condition" button that allows inserting new empty condition objects to the end of the array. For each action sequence, an area is rendered for each action object, containing: an action type dropdown bound to rule.action.type, a target selector bound to rule.action.target, an "Add Action" button and a "Move Up / Down" button for managing the action sequence, and a dynamic parameter panel. The dynamic parameter panel dynamically renders the required input controls based on the currently selected action type, including numeric input boxes, resource selectors, color selectors, text input boxes, and custom attribute selectors. Each input control is precisely bound to the corresponding field in the rule.action.parameters object.

5. The Web3D zero-code interactive design platform based on a unified model according to claim 4, characterized in that, In DMAE, the blueprint editor provides a graphical canvas based on nodes and connections, suitable for visualizing logical flows and macro-level architecture. The working mechanism of the blueprint editor also includes view generation and user interaction processing: View generation includes: Node mapping: Each rule is mapped to a composite node, or split into event nodes, condition judgment node groups, and action sequence nodes according to the configuration. Each node has its position information on the canvas. Port generation: Event nodes have an "output" port; condition judgment nodes have both "input" and "output" ports; action sequence nodes have an "input" port; Connection generation: Based on the inherent logical order of the rules, connections are generated between the corresponding node ports, and the connections represent the transmission of control flow; User interaction processing: User actions on the blueprint are translated into structured modifications to the UBLM, including dragging and dropping connections, deleting connections, and modifying nodes in the properties panel.

6. The Web3D zero-code interactive design platform based on a unified model according to claim 5, characterized in that, IREE aims to transform declarative UBLM into business logic code that runs directly in the browser. IREE employs a pre-compiled architecture combined with event-driven principles, decoupling logical complexity from runtime calculations per frame. The execution flow of IREE includes: Phase 1, Initialization Phase: Pre-compilation and registration are performed. When the user clicks the "Run" or "Preview" button set in the global common operation area of ​​DMAE, IREE starts working and executes the following steps: Model loading and parsing: IREE reads the project's UBLM JSON from persistent storage and parses it into an in-memory object; Create runtime context: Initialize a RuntimeContext object, which contains copies of the values ​​of all current global variables, scene object access interfaces, and an event emitter for cross-rule communication; Rule traversal and functionalization: IREE traverses each enabled rule in the core rule set area. For the set of execution conditions, it compiles it into a pure JavaScript function. For the action sequence, IREE creates a closure function for each action that knows how to execute the action, and wraps the closure function into a schedulable action chain function according to the order and delay parameters. Rule wrapper creation: Package the pure JavaScript function and action chain function together with the description information of the triggering event of the rule to create a rule processor object; Establishing an event-rule index: IREE registers rule processor objects into a multi-level hash map table based on each rule's rule.event.type and rule.event.target. Phase Two, Runtime Phase: During this phase, the runtime loop begins. IREE works in conjunction with the 3D rendering engine to execute the following steps: Event injection: When the 3D rendering engine detects an interactive event during its own update cycle, it normalizes the event and passes it to IREE through a predefined interface; Event routing and rule retrieval: IREE's event listeners receive standardized event objects and use the event type and target ID as keys to query the event-rule index mapping table; Synchronous condition validation: IREE synchronously and sequentially calls the pure JavaScript function of each rule processor in the list, passing in the current RuntimeContext object; Asynchronous scheduling of actions: For rules that return true for all conditions, IREE introduces a time-based scheduler to begin processing its action chain; Action execution and state update: The action closure being executed contains code that calls the 3D rendering engine API. These calls directly affect the rendering tree and produce visual or auditory feedback. Looping and Cleanup: The steps described above in the runtime phase continue throughout the application's lifecycle. When the scene changes or the application stops, IREE unregisters all event listeners, clears the scheduling queue and index table, and releases resources.

7. The Web3D zero-code interactive design platform based on a unified model according to claim 6, characterized in that, IREE introduces a time-based scheduler to handle action chains that return true, specifically: For each action closure with delay in the action chain, IREE calculates its absolute execution time. IREE encapsulates these action closures and their absolute execution times into scheduling tasks and inserts them into a priority queue sorted by execution time. The priority queue is driven by the browser's requestAnimationFrame. Before each frame is rendered, IREE checks the head of the queue. If the current time has reached or exceeded the execution time of a task, the task is dequeued and its action closure is executed in the current frame.

8. A Web3D zero-code interactive design method based on a unified model, based on the platform described in claim 6 or 7, characterized in that, Includes the following steps: S1. Project creation and environment initialization: The user logs into the platform, creates a new 3D interactive application project, initializes an empty UBLM structure, and loads the default 3D scene template or the scene resources uploaded by the user. The editor interface is ready. S2. The dual-mode visual definition of business logic, including: S2.1 When the user selects the form mode, a blank form is rendered based on the current empty UBLM. The user can fill in the events, conditions and actions in the form by clicking "Add Rule" to define the first interaction logic, that is, define the rule. Each input is converted into an update of the UBLM in real time. S2.2 The user switches to Blueprint mode to view a graphical representation of the logic; DMAE immediately renders the rules defined in the form into a logic diagram consisting of event nodes, condition decision nodes, and action sequence nodes connected by lines; allowing the user to continue editing in the Blueprint interface; S2.3 When a user selects a new node in the blueprint, they can configure specific buttons and actions in the node properties panel; at the same time, a corresponding rule row is automatically added to the form interface, and the content is completely synchronized. S3. Real-time verification and iteration: During the editing process, users can click the "Instant Preview" button at any time. When clicked, the UBLM data currently being edited is instantly transmitted to IREE. IREE executes the compilation process of the initialization phase in an isolated preview context, and then starts a lightweight preview scene, allowing users to interact with the scene immediately and test whether the defined rules work as expected. If a problem is found, make adjustments directly in the current editing interface. Changes to UBLM will be synchronized to all views via a "Model Updated" notification. S4. Project Building and Final Release: After completing all logical design, the user executes the "Release" command. S4.1 Perform final verification and optimization of UBLM; S4.2 Front-end construction: Package UBLM, 3D scene resources, the IREE core library stripped from the editor runtime, and a lightweight 3D renderer shell together into a static web application. S5. Terminal operation: The end user accesses the published web application through a browser. After loading, the IREE inside the application executes the initialization pre-compilation process, and then enters the runtime phase and enters the running loop.

9. The Web3D zero-code interactive design method based on a unified model according to claim 8, characterized in that, Following S4.2, it also includes: S4.3 If the logic includes actions that require server-side interfaces, automatically generate the corresponding API call code snippets according to the definitions in UBLM and integrate them into the packaged artifacts, or provide interface documentation.

Images