Method and device for processing particle special effect parameters, electronic equipment and medium

Abstract

The application discloses a particle special effect parameter processing method and device, electronic equipment and medium, loads a target particle system, obtains characteristic data of each particle emitter; utilizes a preset AI intelligent agent to perform semantic analysis on the characteristic data of each particle emitter, and obtains a semantic recognition result; determines a corresponding color parameter group of each particle emitter according to the brightness level of each particle emitter in the semantic recognition result, and generates parameter injection configuration information according to the corresponding color parameter group of each particle emitter and a corresponding color binding path of each color parameter group; and generates a target special effect template according to the parameter injection configuration information and the target particle system. The technical scheme can effectively improve the creation efficiency of a special effect preset template.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, specifically to a method, apparatus, electronic device, and medium for processing particle effect parameters. Background Technology

[0002] In modern game development, the creation of visual effects assets is a highly specialized task. A typical particle effects system usually contains 5 to 20 emitters, each consisting of dozens of functional modules. When a project requires a large number of effect variations with consistent style but different attributes (e.g., the same sword light needs different elemental versions such as fire, ice, and lightning), the original effects need to be converted into parameterizable effect preset templates so that non-technical personnel can quickly derive new effects with consistent style but different details. Existing effect preset templates are all manually created by visual effects artists based on their personal experience. The creation process requires manual identification of particle emitter brightness levels, matching color parameters, binding module paths, and other operations, making the process of creating effect preset templates tedious and repetitive, resulting in low efficiency in the creation of effect preset templates. Summary of the Invention

[0003] This application provides a method, apparatus, electronic device, and medium for processing particle effect parameters, which can effectively improve the creation efficiency of preset effect templates.

[0004] In a first aspect, embodiments of this application provide a method for processing particle effect parameters, including: Load the target particle system and obtain the feature data of each particle emitter. The feature data includes at least the position and brightness value of the target color module. The target particle system includes multiple particle emitters. The semantic recognition result is obtained by using a preset AI agent to perform semantic analysis on the feature data of each particle emitter. The semantic recognition result includes the brightness level of each particle emitter. The AI ​​agent is injected with the domain knowledge of the particle system. The domain knowledge includes brightness stratification rules for stratifying the particle emitters based on brightness values. The brightness stratification rules are used to divide the particle emitters into at least two brightness levels according to a preset brightness threshold. Based on the brightness level of each particle emitter, determine the color parameter group corresponding to each particle emitter, and generate the parameter injection configuration information based on the color parameter group corresponding to each particle emitter and the color binding path corresponding to each color parameter group. Based on the parameter injection configuration information and the target particle system, a target special effects template is generated.

[0005] Secondly, embodiments of this application provide a processing apparatus for particle effect parameters, comprising: A loading module is used to load the target particle system and obtain the feature data of each particle emitter. The feature data includes at least the position and brightness value of the target color module. The target particle system includes multiple particle emitters. The semantic analysis module is used to perform semantic analysis on the feature data of each particle emitter using a preset AI agent to obtain semantic recognition results. The semantic recognition results include the brightness level of each particle emitter. The AI ​​agent is injected with domain knowledge of the particle system. The domain knowledge includes brightness stratification rules for stratifying the particle emitters based on brightness values. The brightness stratification rules are used to divide the particle emitters into at least two brightness levels according to a preset brightness threshold. The configuration information generation module is used to determine the color parameter group corresponding to each particle emitter based on the brightness level of each particle emitter, and to generate the parameter injection configuration information based on the color parameter group corresponding to each particle emitter and the color binding path corresponding to each color parameter group. The template generation module is used to generate a target special effects template based on the configuration information injected by the parameters and the target particle system.

[0006] Thirdly, embodiments of this application also provide an electronic device, including a memory storing multiple instructions; a processor loads instructions from the memory to execute the steps of any of the particle effect parameter processing methods provided in embodiments of this application.

[0007] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a plurality of instructions adapted for loading by a processor to execute the steps of any of the particle effect parameter processing methods provided in embodiments of this application.

[0008] Fifthly, embodiments of this application also provide a computer program product, including a computer program or instructions, which, when executed by a processor, implement the steps in the particle effect parameter processing method provided in embodiments of this application.

[0009] The solution adopted in this application embodiment, after detecting the feature data of each particle emitter, uses an AI agent to perform semantic analysis on the detected feature data to obtain the brightness level of each particle emitter. Then, based on the brightness level of each particle emitter, it determines the corresponding color parameter group and the color binding path corresponding to each color parameter group, generates the parameter injection configuration information, and automatically generates the target special effect template based on the parameter injection configuration information. In this way, the parameter injection configuration information can be automatically obtained by the machine without manual operation. Compared with the existing technology of manually creating special effect templates, it can significantly shorten the creation time of special effect templates and thus improve the creation efficiency of special effect templates. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a schematic diagram of an embodiment of the particle effect parameter processing method provided in this application. Figure 2 This is a schematic diagram of another embodiment of the particle effect parameter processing method provided in the embodiments of this application; Figure 3 This is a schematic diagram of the structure of the particle effect parameter processing device provided in the embodiments of this application; Figure 4 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0012] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. At the same time, in the description of the embodiments of this application, the terms "first," "second," etc., are only used to distinguish descriptions and should not be construed as indicating or implying relative importance. Thus, features defined with "first" and "second" may explicitly or implicitly include one or more features. In the description of the embodiments of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0013] This application provides a method, apparatus, electronic device, and computer-readable storage medium for processing particle effect parameters.

[0014] Specifically, this embodiment will be described from the perspective of a particle effect parameter processing device. This particle effect parameter processing device can be integrated into an electronic device, that is, the particle effect parameter processing method of this application embodiment can be executed by an electronic device. Optionally, the electronic device may include a terminal device. The terminal device may be a mobile phone, tablet computer, smart Bluetooth device, laptop computer, game console, or personal computer (PC), etc.

[0015] The following detailed description is provided in conjunction with the accompanying drawings. In this embodiment, the execution subject is a terminal device as an example. It should be noted that the order of description in the following embodiments is not intended to limit the preferred order of the embodiments. Although a logical order is shown in the flowcharts, in some cases, the steps shown or described may be performed in a different order than that shown in the accompanying drawings.

[0016] The related technology, the particle system used in game engines to simulate visual effects such as fire, smoke, and magic, consists of multiple particle emitters. Each particle emitter contains functional modules for stages such as generation (Spawn) and update, controlling the color, movement, and disappearance behavior of the particles. During game development, a large number of effect variations with consistent style but different attributes are often needed (e.g., a single sword strike requires fire, ice, and lightning element versions). To improve game development efficiency, the original effects are usually converted into parameterizable effect templates. However, converting original effects into parameterizable effect templates requires a high level of expertise, including knowledge of the differences in color, brightness, and color module execution stages within existing particle systems. This typically necessitates specialized visual effects artists to convert the original effects into parameterizable effect templates.

[0017] When creating effects templates, visual effects artists need to expand the module stack of each particle emitter one by one in the engine editor, manually find color modules, record color values ​​and HDR brightness, judge the visual role of the emitter based on experience, and then determine the parameter grouping scheme according to the role. Subsequently, user parameters are manually created at the top level of the system, and color module inputs are bound to the corresponding user parameters one by one. This makes the process of creating effects templates cumbersome and time-consuming, resulting in low efficiency in creating preset effects templates.

[0018] The particle effect parameter processing method of this application embodiment can perform semantic analysis on the detected feature data of each particle emitter using an AI agent after detecting the feature data of each particle emitter, thereby obtaining the brightness level of each particle emitter. Then, based on the brightness level of each particle emitter, the corresponding color parameter group and the color binding path corresponding to each color parameter group are determined, generating parameter injection configuration information. Finally, the effect template is automatically generated based on the parameter injection configuration information. In this way, the parameter injection configuration information can be automatically obtained by the machine without manual operation. Compared with the tedious operation steps of the existing technology where the special effects artist needs to manually identify the brightness level, match the color parameters, and bind the module path one by one, it can significantly shorten the creation time of the effect template, compressing the manual operation that originally required several hours to minutes or even less, and effectively improving the creation efficiency of the effect template.

[0019] Please refer to Figure 1The specific process for processing the particle effect parameters can be summarized in steps 101-104, where: Step 101: Load the target particle system and obtain the feature data of each particle emitter. The feature data includes at least the position and brightness value of the target color module. The target particle system includes multiple particle emitters.

[0020] In some embodiments, the particle system corresponding to the effect template to be created can first be identified as the target particle system, and then loaded through the engine bridging interface. For example, in Unreal Engine, the loading interface of NiagaraSystem is called to obtain the object handle of the target particle system. Subsequently, using the reflection or traversal interface provided by Unreal Engine, all particle emitters in the target particle system are enumerated to obtain a list of particle emitters. For each particle emitter in the list, each functional module in that particle emitter is probed to obtain the probe dataset corresponding to each particle emitter; then, based on the probe dataset corresponding to each particle emitter, the feature data of each particle emitter is obtained.

[0021] In some embodiments, the functional modules of the particle emitter may include, in addition to the color module, one or more of the following: rendering module, emission and generation module, shape module, lifecycle attribute module, physics and motion module, and texture animation module.

[0022] Specifically, since each particle emitter's functional modules include at least a color module, the detection dataset must include at least the target color module information for each particle emitter. Thus, the position and brightness value of the target color module for each particle emitter can be obtained based on this information. Specifically, for each particle emitter, a color module can be randomly selected as the target color module. When obtaining the brightness value of the target color module, the color value corresponding to the target color module is first obtained from the target color module information. This color value could be, for example, a High Dynamic Range (HDR) color value or an RGB color value. Then, based on the color value corresponding to the target color module, the brightness value is determined. This can be achieved by using the largest color component among the color values ​​corresponding to the target color module, or by multiplying the largest color component by a set weight.

[0023] Taking HDR color values ​​as an example, the color value of the target color module is an HDR color value. The format of an HDR color value is usually a (R, G, B, A) quadruple, where each component can be a floating-point number greater than 1.0. The brightness value of the target color module can be the maximum color component in the HDR color value, denoted as max(R, G, B). In this way, the brightness value of each color module in each particle emitter can be obtained.

[0024] In some embodiments, a target particle system is loaded, and the renderer type, color module, and material texture in each particle emitter are detected to obtain renderer type information, color module information, and texture resource information for each particle emitter. The color module information includes the position and brightness value of the target color module. Then, based on the renderer type information, color module information, and texture resource information of each particle emitter, feature data for each particle emitter is obtained. The feature data includes renderer type information, the position and brightness value of the target color module, and texture resource information.

[0025] Specifically, after loading the target particle system through the engine bridging interface, all particle emitters in the system are first enumerated. For each particle emitter, three detection steps are performed: renderer type identification, color module detection, and material texture overwrite extraction, to obtain complete feature data.

[0026] In some embodiments, when performing renderer type detection, a virtual engine interface (e.g., list_renderers(system, emitter_index)) can be invoked to obtain a list of renderers associated with each particle emitter. Specifically, each particle emitter typically includes at least one renderer. The type field is extracted and parsed from the renderer list returned by the interface; the renderer type includes bulletin board particles (Sprite), mesh particles (Mesh), ribbon particles (Ribbon), etc. The parsed type is stored as renderer type information, thereby allowing the type of each renderer in each particle emitter to be obtained.

[0027] In some embodiments, when probing color modules, a traversal approach can be used to probe each color module in each particle emitter, reading module information such as the storage path, corresponding particle execution stage, module name, and color value of each color module. The location of the color module is its storage path, and the particle execution stage can include a particle generation (ParticleSpawn) stage and a particle update (ParticleUpdate) stage. Furthermore, after probing each color module in each particle emitter using the traversal approach, for each particle emitter, the module information of any color module in that particle emitter can be used as the target color module information for that particle emitter.

[0028] In some embodiments, when performing material texture detection, the path of the material asset bound to the corresponding emitter can be located based on the obtained renderer type information, such as an example path like / Game / Effects / Materials / M_Default; the engine material parsing interface is called to load the target material resource, extract the parent material name corresponding to the material, and parse the texture overrides configured in the material instance to obtain texture resource information, which includes one or more of the following: basecolor map, normal map, emissive map, etc.

[0029] In this way, by performing renderer type detection, color module detection, and material texture detection on each particle emitter, the feature data of each particle emitter can be obtained. This eliminates the need for VFX artists to search through the functional module stack of each particle emitter one by one, thereby effectively shortening the time to obtain the feature data of all particle emitters and improving the extraction efficiency of the feature data of all particle emitters.

[0030] In some embodiments, when performing color module detection, for each particle emitter, the color modules in the particle emitter can be detected according to a preset color module detection order, the target color module can be determined from the color modules of the particle emitter, and the module information of the target color module can be obtained, and the module information of the target color module can be used as the target color module information of the particle emitter.

[0031] In some embodiments, the color module detection order can be set according to actual conditions. For example, the color module detection order can be to detect color modules in the particle generation stage first, and then detect color modules in the particle update stage, or to detect color modules in the particle update stage first, and then detect color modules in the particle generation stage. The color module with position and color value detected for the first time can be used as the target color module, and the module information of the target color module can be used as the target color module information of the particle emitter. The following is a specific example of detecting color modules in the particle update stage first, and then detecting color modules in the particle generation stage.

[0032] In some embodiments, to achieve accurate detection of target color modules, a candidate list of color modules is first constructed according to the module detection order. This candidate list contains two types of color modules in descending order of priority. The first priority color module is the Color dynamic color module located in the ParticleUpdate stage, whose color input parameter name is Color; the second priority color module is the InitializeParticle module located in the ParticleSpawn stage, whose color input parameter name is Color. Furthermore, a traversal matching mechanism is used during the detection process. For each particle emitter in the target particle system, the corresponding module and input parameter are retrieved sequentially according to the above priority order. The specific logic is as follows: For the current candidate module (module name mod_name, runtime usage, input parameter name input_name), the engine interaction interface get_module_input_value is called to read the value of the specified input parameter of the module. If the returned result is empty or contains an identifier such as "not found" indicating that the module was not found, the current candidate is skipped, and the traversal of the next priority color module continues. If a valid parameter result is found, the retrieved color module is used as the target color module. The returned data is parsed, the color parameter field is extracted, and default null values ​​are removed. The extracted color value string is decomposed (usually in the format (R, G, B, A)), and each component is converted into a floating-point number to obtain the normalized color channel values ​​[R, G, B, A]. The maximum value of the three channels R, G, and B is taken as the HDR brightness value of the particle emitter, i.e., brightness = max(R, G, B). Finally, the target color module information of the particle emitter is output: module name, running stage, input parameter name, color value (color), and brightness value (brightness), and the detection of subsequent candidates is terminated. If no valid color parameter is found after traversing all candidate modules, it is determined that the particle emitter has no valid color control module, and a null value result is returned.

[0033] As an example, the above detection process can be implemented using the following code: def detect_color_module(system, emitter_index): "Automatic detection of multiple candidate priority color modules" for mod_name, usage, input_name in COLOR_MODULE_CANDIDATES: result = bridge.get_module_input_value( system, emitter_index, mod_name, input_name) if not result or "not found" in result.lower(): continue parsed = json.loads(result) val_str = parsed.get("value", "") if val_str and val_str != "(default)": parts = val_str.strip("()").split(",") color = [float(p.strip()) for p in parts] brightness = max(color[:3]) # HDR brightness return mod_name, usage, input_name, color, brightness return None, None, None, None, None.

[0034] In this way, by detecting the color modules in sequence, the color modules at different particle execution stages can be traversed in order, ensuring that the target color module information of each particle emitter is unique, reducing the problem of multiple target color module information of particle emitters causing brightness stratification errors in subsequent brightness stratification rules.

[0035] In some embodiments, during the loading of the target particle system, asset path backtracking can also be performed to fully collect the characteristics of associated resources. Specifically, starting from the target particle system's own asset storage path, the search can proceed upwards level by level until the root directory of the asset package of the current special effects project is located. After locating the root directory, all subdirectories under the root directory are traversed, and the corresponding resource types are identified according to the directory naming rules to accurately match associated resources. Specifically, texture resources corresponding to common texture class subdirectories such as Texture, Textures, and TeX can be identified, as well as mesh resources corresponding to common mesh class subdirectories such as Meshes, Mesh, StaticMeshes, and SM. Furthermore, after completing the probing of each subdirectory, all the texture resources and mesh resources obtained can be uniformly organized and incorporated into the feature data of the corresponding particle emitter, enriching the full-dimensional feature information of the particle system and providing complete resource-dimensional data support for the subsequent AI agent to accurately identify the visual performance of particle special effects and match suitable color parameter groups.

[0036] In some embodiments, after acquiring the feature data of each particle emitter, the feature data of all particle emitters can be combined into a structured data set for output. The structured data can be in formats such as JSON or XML. By outputting unified structured data, subsequent AI agents can directly parse standardized data fields for semantic analysis and decision-making without needing to concern themselves with the specific interface differences of the underlying engine. This decouples the feature extraction module from the intelligent decision-making module, improving the system's scalability and cross-platform adaptability.

[0037] Step 102: Use a pre-set AI agent to perform semantic analysis on the feature data of each particle emitter to obtain semantic recognition results.

[0038] The semantic recognition results include the brightness level of each particle emitter. The AI ​​agent is injected with the domain knowledge of the particle system. The domain knowledge includes brightness stratification rules for stratifying particle emitters based on brightness values. The brightness stratification rules are used to divide the particle emitters into at least two brightness levels according to a preset brightness threshold.

[0039] In some embodiments, after obtaining the feature data of each particle emitter through step 101, the feature data of all particle emitters can be converted into structured data, and then the structured data can be input into an artificial intelligence (AI) agent. The AI ​​agent is a large language model agent, pre-injected with the professional knowledge system of the particle system, including but not limited to: brightness layering rules based on brightness values, color multiplication rules, module execution phase rules, and color configuration mode inference rules.

[0040] In some embodiments, the AI ​​agent can analyze the feature data of each particle emitter and perform brightness stratification on each particle emitter according to the brightness value of the target color module in each particle emitter and the brightness stratification rules.

[0041] Specifically, brightness stratification rules and the corresponding brightness values ​​of each particle emitter can be used to perform brightness stratification, resulting in a brightness level for each particle emitter. Based on the brightness level of each particle emitter, semantic recognition results are obtained. Since the semantic recognition results include the brightness level of each particle emitter, the AI ​​agent can perform the division of brightness levels for each particle emitter without requiring manual division by special effects artists based on personal experience, effectively improving the efficiency and accuracy of brightness level division for particle emitters.

[0042] In some embodiments, to ensure data integrity and accuracy, before performing semantic analysis using an AI agent, the AI ​​agent can call pre-registered utility functions (such as ExportSystemSpec and GetModuleInputs) to verify the feature data of each particle emitter. This verifies that key information such as module name and input parameter name are consistent with the actual asset, avoiding incorrect judgments due to outdated scan data or engine version differences. Semantic analysis is then performed after the feature data of each particle emitter has been verified.

[0043] In some embodiments, the preset brightness threshold can be set according to actual conditions. The preset brightness threshold may include one or more preset brightness values. Thus, the brightness of each particle emitter can be layered according to one or more preset brightness values. When the preset brightness threshold includes multiple preset brightness values, each preset brightness value is different.

[0044] In some embodiments, the preset brightness threshold may include only one preset brightness value, which can be used to divide the particle emitters into two brightness levels. For example, particle emitters with brightness values ​​greater than the preset brightness value are classified into one brightness level, and particle emitters with brightness values ​​not greater than the preset brightness value are classified into another brightness level. Furthermore, when the preset brightness threshold includes multiple preset brightness values, the preset brightness threshold may include a first preset brightness value, a second preset brightness value, and a third preset brightness value, wherein the first preset brightness value > the second preset brightness value > the third preset brightness value, or the first preset brightness value < the second preset brightness value < the third preset brightness value. Of course, the preset brightness threshold may also include four or more preset brightness values. The following example illustrates a preset brightness threshold including a first preset brightness value and a second preset brightness value.

[0045] Specifically, if the preset brightness threshold includes a first preset brightness value and a second preset brightness value, then according to the brightness stratification rules, particle emitters with brightness values ​​greater than the first preset brightness value can be classified into the first brightness layer, particle emitters with brightness values ​​between the first and second preset brightness values ​​can be classified into the second brightness layer, and particle emitters with brightness values ​​less than the second preset brightness value can be classified into the third brightness layer.

[0046] Specifically, for each particle emitter, the brightness value of the target color module in the particle emitter can be used as the brightness value corresponding to the particle emitter. Then, the brightness value corresponding to each particle emitter is compared with the first preset brightness value and the second preset brightness value respectively. Based on the comparison results, each particle emitter is divided into brightness levels.

[0047] In some embodiments, the first preset brightness value and the second preset brightness value can be set according to implementation requirements. For example, the first preset brightness value can be 4 or 5, and the second preset brightness value can be 2 or 3, wherein the first preset brightness value is greater than the second preset brightness value.

[0048] Specifically, the first brightness layer can be a glow layer, where the particle emitters produce a strong floodlight effect and are the main luminous part of the special effect; the second brightness layer can be a luminous layer, where the particle emitters produce luminous effects such as trails and sparks; the third brightness layer can be an atmosphere layer, where the particle emitters produce soft, non-luminous effects such as smoke and dust. For example, with a first preset brightness value of 5 and a second preset brightness value of 2, if the brightness value of particle emitter A1 is detected to be 6, since 6 > 5, A1 is classified as a glow layer; if the brightness value of particle emitter A2 is detected to be 4, since 2 < 4 < 5, A2 is classified as a luminous layer; if the brightness value of particle emitter A3 is detected to be 1, since 1 < 2, A3 is classified as an atmosphere layer. In this way, the AI ​​agent records the brightness level of each particle emitter in the semantic recognition results.

[0049] In this way, by using AI intelligent agents to automatically classify the brightness levels of each particle emitter based on brightness stratification rules, the problems of traditional manual judgment of brightness levels relying on personal experience, inconsistent judgment standards, and large deviations in stratification can be avoided, which can effectively improve the accuracy of brightness stratification of particle emitters.

[0050] In some embodiments, domain knowledge includes color multiplication rules. In this case, the color multiplication rules can also be used to perform constraint detection on the target color module of each particle emitter, obtaining the color constraint result for each particle emitter. The color multiplication rules include the correspondence between the final particle color, the initial color, and the scaled color. Based on the color constraint result of each particle emitter and the brightness level of each particle emitter, a semantic recognition result is obtained. Thus, injecting color multiplication rules into the AI ​​agent allows the AI ​​agent to automatically perform constraint detection on the target color module of each particle emitter without manual memorization or investigation, shortening the constraint detection time and improving the efficiency of creating special effects templates.

[0051] Specifically, color multiplication rules can be pre-injected into the AI ​​agent. These rules include the calculation rules for the final color, such as final color = initial color × scaled color × scaled transparency. The initial color is typically set by the InitializeParticle module during the particle generation stage, while the scaled color is controlled by the ScaleColor module during the particle update stage to achieve dynamic hue gradation.

[0052] Specifically, when the AI ​​agent performs semantic analysis on the feature data of each particle emitter, in addition to determining the brightness level, it also invokes the color multiplication rule to perform constraint detection on the target color module. First, it obtains the target color module in each particle emitter, along with its module information, including the module name and the corresponding particle execution stage. For each particle emitter, after obtaining the module information, it detects whether the target color module is used for color scaling and whether it is used for hue gradation. If it detects that a target color module of a particle emitter is used for both color scaling and hue gradation, it generates a color constraint result that sets the initial color of the particle emitter to white. Specifically, if the target color module is a ScaleColor module, it is determined that the target color module is used for color scaling; conversely, if no ScaleColor module is detected, or if a ScaleColor module is detected but not used for hue gradation, the color constraint result for that particle emitter is determined to be unconstrained. Thus, after obtaining the color constraint results for each particle emitter, the brightness level of each emitter can be merged with the color constraint results to form a complete semantic recognition result, which can be used when generating configuration information for subsequent parameters.

[0053] For a given particle emitter, analyzing its feature data reveals that the target color module is the ScaleColor module. The input color curve of this module exhibits a gradient from red to yellow. According to the color multiplication rule, if the initial color module has a zero channel in its RGB values, that channel will always be zero after multiplication, causing an anomaly of black in the hue gradient. Therefore, the AI ​​agent generates a constraint, setting the InitializeParticle.Color value of the particle emitter to white, i.e., (1.0, 1.0, 1.0, 1.0). Thus, when the AI ​​agent can identify the ScaleColor module and recognize its use for hue gradients, it forces the initial color to be white, fundamentally eliminating the problem of zero channels turning black due to color multiplication and ensuring the accuracy of the effect after color change.

[0054] In some embodiments, the domain knowledge also includes module execution phase rules. In this case, the module execution phase rules can also be used to identify the execution phase of the target color module of each particle emitter to obtain the particle phase information of the target color module of each particle emitter. The module execution phase rules are used to indicate the behavioral characteristics of different execution phase modules in the target particle system. Based on the particle phase information of the target color module of each particle emitter, the color constraint result of each particle emitter, and the brightness level of each particle emitter, the semantic recognition result is obtained.

[0055] Specifically, module execution phase rules can be pre-injected into the AI ​​agent. The module execution phase rules define the behavioral characteristics of modules in different execution phases. If the color module is in the ParticleSpawn phase, the color module will only be executed once when the particle is generated, which is suitable for setting static initial values ​​(such as initial color and initial size). If the color module is in the ParticleUpdate phase, the color module will be executed in every frame when the particle is alive, which is suitable for setting dynamic changes (such as color gradient and curve-driven motion).

[0056] In some embodiments, when the AI ​​agent performs semantic analysis on the feature data of each particle emitter, after, before or simultaneously with the completion of brightness level determination and color constraint detection, it can also use the module execution stage rules to identify the execution stage of the target color module of each emitter.

[0057] Specifically, for each particle emitter, the stage information of the target color module can be obtained. Specifically, the execution stage field (usage) corresponding to the target color module can be obtained from the feature data of the particle emitter. This field value may be ParticleSpawn or ParticleUpdate. If the execution stage field of the target color module is ParticleSpawn, then the particle stage information corresponding to the particle emitter is determined to be the particle generation stage. If the execution stage field of the target color module is ParticleUpdate, then the particle stage information corresponding to the particle emitter is determined to be the particle update stage.

[0058] In some embodiments, since different particle stage information directly affects the selection of binding paths in subsequent parameter injection configuration information, for color modules whose particle stage information is the particle generation stage, since it is a static initial value, after binding user parameters, the color-changing effect will apply to the color at the particle's birth, suitable for overall tone adjustment. For color modules whose particle stage information is the particle update stage, since it changes dynamically every frame, after binding user parameters, the color-changing effect will apply in real time to the entire lifecycle of the particle, suitable for achieving dynamic color effects. This allows the AI ​​agent to automatically select the correct binding path based on the identified particle stage information, avoiding animation anomalies caused by incorrect particle stage information (such as binding dynamic curves to static modules), reducing the probability of errors in creating special effects templates, and improving the efficiency of special effects template creation.

[0059] In some embodiments, the brightness level, color constraint result, and particle stage information of each transmitter can be merged to form a complete semantic recognition result, such that the semantic recognition result includes brightness level, color constraint result, and particle stage information, which can enable the generation of parameter injection configuration information based on the brightness level, color constraint result, and particle stage information.

[0060] Step 103: Determine the color parameter group corresponding to each particle emitter based on the brightness level of each particle emitter, and generate parameter injection configuration information based on the color parameter group corresponding to each particle emitter and the color binding path corresponding to each color parameter group.

[0061] In some embodiments, after the AI ​​agent recognizes the semantic analysis results, since the semantic analysis results include the brightness level of each particle emitter, the AI ​​agent can also perform step 103.

[0062] Specifically, after the AI ​​agent completes semantic analysis and obtains the brightness level of each particle emitter (first brightness layer / glowing layer, second brightness layer / luminous layer, third brightness layer / ambient layer), it generates parameter injection configuration information.

[0063] In some embodiments, the AI ​​agent can group particle emitters belonging to the same brightness level into the same color parameter group. Specifically, all particle emitters belonging to the first brightness level can be grouped into the first color parameter group, all particle emitters belonging to the second brightness level into the second color parameter group, and all particle emitters belonging to the third brightness level into the third color parameter group. For example, all particle emitters with brightness values ​​greater than 5.0 are assigned to the parameter group named "Color_Core"; all particle emitters with brightness values ​​between 2.0 and 5.0 are assigned to the "Color_Spark" parameter group; and particle emitters with brightness values ​​less than 2.0 are assigned to the "Color_Smoke" parameter group.

[0064] Specifically, for each color parameter group, the AI ​​agent needs to determine the color binding path for each particle emitter. This binding path consists of three parts: the particle emitter index, the execution phase of the target color module (ParticleSpawn or ParticleUpdate), the module name (e.g., InitializeParticle, Color, or Color001), and the input parameter name (usually Color). These elements together constitute the color binding path for each particle emitter. For example, the color binding path for a particle emitter can be represented as: (emitter_index=3, usage="ParticleUpdate", module="Color001", input="Color"). After determining the color binding path for each particle emitter, the AI ​​agent combines the color parameter group definition with the color binding path to generate structured parameter injection configuration information. This configuration information includes at least the target particle system path, the storage path and name of the particle system copy corresponding to the effect template, a list of user parameters to be created (parameter name, type, default value), and a binding relationship list (the color binding path and corresponding user parameter name for each particle emitter).

[0065] In some embodiments, during the generation of parameter injection configuration information, the color configuration mode of the target particle system can be determined based on whether the target particle system already has a first user parameter of color class; then, parameter injection configuration information is generated based on the color configuration mode, the color parameter group corresponding to each particle emitter, and the color binding path corresponding to each color parameter group.

[0066] Specifically, before generating the parameter injection configuration information, the AI ​​agent can also detect whether a first user parameter of color type exists in the top-level user parameters of the target particle system. The AI ​​agent can iterate through the detected list of top-level user parameters, checking each parameter's type for color (such as LinearColor or Color). If at least one user parameter of color type exists, it is determined that a first user parameter already exists; otherwise, it is determined that a first user parameter does not exist. If a first user parameter already exists, the AI ​​agent sets the color configuration mode to hue-shift mode, which reuses the first user parameter. Specifically, in hue-shift mode, there is no need to create new user parameters; instead, existing first user parameters are reused. When changing colors, only the value of the first user parameter needs to be modified. The colors of all particle emitters bound to the first user parameter are automatically updated, and the brightness ratio between the original colors is preserved.

[0067] Furthermore, if the first user parameter does not exist, the AI ​​agent sets the color configuration mode to color derivation mode. In color derivation mode, a second user parameter for the color class needs to be created, and the target color module of each particle emitter is bound to the second user parameter. When changing colors, starting from the hue and saturation of the theme color, hierarchical colors are generated according to different brightness multipliers. Additionally, the AI ​​agent records the determined color configuration mode (hue offset mode or color derivation mode) as a field in the parameter injection configuration information for use during subsequent injection. In this way, user parameters do not need to be created in hue offset mode, avoiding bloated asset packages due to repeated creation.

[0068] In some embodiments, if the target particle system already has a first user parameter, the color configuration mode is determined to be a hue offset mode; if the target particle system does not have a first user parameter, the color configuration mode is determined to be a color derivation mode, wherein the color derivation mode is used to indicate the second user parameter of the newly created color class and bind the second user parameter to the target color module of each particle emitter.

[0069] Specifically, when the first user parameter does not exist, an instruction to create a second user parameter can be received, and then the instruction can be responded to to create a second user parameter. The newly created second user parameter includes a parameter name (e.g., Color_Core), a parameter type (LinearColor), and a default value (usually the original HDR color value of one of the emitters in the parameter group, e.g., (8.0, 6.5, 4.2, 1.0)). Then, the target color module input of each particle emitter can be linked to the second user parameter through a binding list.

[0070] Step 104: Generate the target effect template based on the parameter injection configuration information and target particle system.

[0071] In some embodiments, after the AI ​​agent generates parameter injection configuration information, a particle system copy can be created by first replicating the source system, and then a target effect template can be generated based on the parameter injection configuration information and the particle system copy. Specifically, the engine asset operation interface can be called to copy a new particle system asset as a particle system replica based on the source particle system path (source) in the parameter injection configuration information. The storage path and name of the particle system replica are specified by `dest_path` in the parameter injection configuration information. If an asset with the same name already exists at the target path, it is first deleted or backed up to ensure the particle system replica is brand new. Furthermore, when the color configuration mode is color derivation mode, the `user_params_to_create` list in the configuration information is traversed, and engine interfaces (such as `add_user_parameter`) are called to add the second user parameter sequentially at the top level of the particle system replica, setting the parameter type (such as `LinearColor`) and default value. When the color configuration mode is hue offset mode, there is no need to create a new user parameter; the existing user parameters specified in the configuration information are used directly. Then, the `bindings` list in the parameter injection configuration information is traversed, and for each binding record, engine interfaces (such as `link_user_parameter_to_module_input`) are called to link the specified user parameter to the target color module input of the corresponding particle emitter. After all bindings are complete, the engine compilation interface (such as `compile_system`) is invoked to compile the particle system copy, checking for errors such as type mismatches and circular dependencies. Once compilation is successful, the compiled particle system copy is used as an effects template, which can be stored in a storage device. Simultaneously, the parameter injection configuration information is saved as a JSON file for later reuse and auditing. In this way, by generating a particle system copy from the target particle system, all modifications are made on the particle system copy, ensuring the target particle system remains unchanged and avoiding damage to the original asset due to configuration errors. It also supports multiple iterative generation. Furthermore, saving the parameter injection configuration information as a JSON file not only facilitates tracing the AI's decision-making process but also serves as a migration template for similar assets, enabling cross-asset reuse of knowledge.

[0072] In some embodiments, after creating a copy of the particle system, an initial special effects template can be generated based on the parameter injection configuration information and the copy of the particle system; then, the initial special effects template is verified at multiple levels by an AI agent; if any level of verification fails, the parameter injection configuration information is corrected using the AI ​​agent to obtain the corrected parameter injection configuration information; and a target special effects template is generated based on the corrected parameter injection configuration information and the copy of the particle system.

[0073] Specifically, after generating the initial special effects template, the initial special effects template is subjected to multi-level verification. The verification process is implemented by calling the pre-registered tool interface. The multi-level verification can include at least two of the following: structural verification, binding verification, and compilation verification.

[0074] In some embodiments, if multi-level verification includes structural verification, the ExportSystemSpec tool can be invoked, the asset path of the particle system replica can be input, and the complete structural information of the particle system replica (including all particle emitters, modules, user parameters, etc.) can be re-exported. Then, an AI agent is used to parse the returned structural data and check it one by one. The checks can include whether each user parameter required to be created (or reused) in the parameter injection configuration information exists in the top-level user parameter list of the replica; whether the type of the user parameter is consistent with the type in the configuration information (e.g., both are LinearColor); whether the default value of the user parameter is set correctly, etc. If all checks pass, the structural verification is determined to be successful; otherwise, the structural verification is determined to be unsuccessful.

[0075] In some embodiments, if multi-level verification includes binding verification, for each binding relationship in the parameter injection configuration information, the GetModuleInputs tool can be called, passing in the system handle of the particle system replica, the emitter index, and the target color module name, to accurately read all the input parameter information of the corresponding color module. Subsequently, the AI ​​agent verifies the current parameter status of the target input port of the color module. This verification checks whether the input parameter of the color module is a fixed hard-coded constant color value. If it is not a fixed hard-coded constant color value, the verification passes; otherwise, it fails, ensuring that the color module has been freed from fixed parameter constraints and completed dynamic parameter association configuration. This verification also verifies that the user parameter name linked to the current color module port is completely consistent with the preset target parameter name in the parameter injection configuration information. If each of the above verification checks passes, the binding verification is considered successful; otherwise, the binding verification is considered unsuccessful. Because the above verification can employ dual verification, it can accurately determine whether the parameter binding operation is valid and the configuration is effective, ensuring the standardization and accuracy of parameter binding for the particle system replica.

[0076] In some embodiments, if multi-level verification includes compilation verification, the engine compilation interface (such as compile_system) can be called to compile the particle system copy. Then, the AI ​​agent can obtain the compiler's output information. If the compilation is successful and there are no error messages, the compilation verification is determined to be successful. If there are errors (such as type mismatch, missing referenced parameters, circular dependencies, etc.), the compilation verification is determined to be unsuccessful, and the error details are recorded for subsequent analysis.

[0077] In some embodiments, if multi-level verification may include structural verification, binding verification, and compilation verification, then these three verifications can be performed sequentially. If any verification fails, subsequent verifications will immediately stop. The AI ​​agent records the failure level and specific reason, and writes the verification results to the operation log. If all verifications pass, the generated special effects template will be used as the final special effects template.

[0078] In some embodiments, when any verification fails, the parameter injection configuration information using the AI ​​agent is corrected based on the error information returned by the verification. Then, a target effect template is generated based on the corrected parameter injection configuration information and the particle system copy, wherein all multi-level verifications corresponding to the target effect template have passed.

[0079] In practical applications, multiple iterations can be used to obtain the corrected parameter injection configuration information until all generated special effects templates pass multi-level verification. Then, the special effects template that has passed multi-level verification will be used as the target special effects template.

[0080] In practical applications, such as Figure 2 As shown, step 201 is first executed to scan and extract features from the target particle system. Specifically, the target particle system can be loaded through the engine bridging interface, all particle emitters are enumerated, and for each particle emitter, three detections are performed sequentially: renderer type identification, color control module detection (analyzing HDR color RGBA components and calculating brightness), and material texture overlay extraction. Simultaneously, the asset path of the target particle system is traced back upwards to locate the root directory of the asset package, sequentially attempting to find texture resources by adaptively using common subdirectory names such as Texture, Textures, and Tex, and mesh resources by using subdirectory names such as Meshes, Mesh, StaticMeshes, and SM. The scan also checks whether a LinearColor type color parameter already exists in the top-level User Parameter of the target particle system, serving as input for subsequent color configuration mode inference. All the data obtained above is used as scan data and output as structured JSON.

[0081] Then, step 202 is executed, where the AI ​​agent performs semantic analysis on the scanned data. Specifically, the structured JSON output from step 201 can be input into the AI ​​agent. The AI ​​agent's System Prompt has pre-injected particle system domain knowledge (color multiplication rules, HDR brightness three-level stratification standard (brightness stratification rules), module stage rules, and color configuration mode inference logic). The AI ​​agent first verifies the integrity of the scanned data by calling ExportSystemSpec and GetModuleInputs, confirming the accuracy of the module name and input name. Then, according to the HDR brightness three-level stratification standard (>5.0 is the glow layer, 2.0-5.0 is the luminous layer, <2.0 is the ambient layer), each particle emitter is classified into a visual role. Next, particle emitters with the same visual role are grouped into a shared color parameter group. For example, two emitters with brightness of 8.0 and 6.5 are grouped into the core light group sharing the Color_Core parameter, and emitters with brightness of 3.5 and 2.8 are grouped into the spark group sharing the Color_Spark parameter. Finally, the color-changing strategy is determined based on the color configuration mode inference results, and the correct module binding path is selected for each parameter group.

[0082] In some embodiments, taking a magic sword light effect with 12 emitters as an example, the injection parameter configuration information generated by the AI ​​agent based on the scanning results can be implemented using the following code: inject_config = { "source": " / Game / VFX_Pack / VFX / NS_MagicSlash", "dest_dir": " / Game / FX / Presets", "dest_name": "NS_MagicSlash_Preset", "user_params": [ # Agent judgment: emitter 3 (brightness 8.0), emitter 8 (brightness 6.5) # All > 5.0 → Glow layer, grouped into the same group {"name": "Color_Core", "type": "color", "default": "6.0,7.2,6.8,1.0"}, # Agent judgment: emitter 5 (brightness 3.5), emitter 7 (brightness 2.8) # All within the range of 2.0~5.0 → Emissive layer, grouped into the same group {"name": "Color_Spark", "type": "color", "default": "3.5,4.0,3.8,1.0"}, # Agent judgment: emitter 0 (brightness 0.8), emitter 9 (brightness 1.2) # All < 2.0 → Atmosphere layer, grouped together {"name": "Color_Smoke", "type": "color", "default": "1.0,1.2,1.3,1.0"}, ], "bindings": [ # Glow group binding (Color001, ParticleUpdate phase) {"emitter_index": 3, "module": "Color001", "usage": "ParticleUpdate", "input": "Color", "param": "Color_Core", "type_hint": "color"}, {"emitter_index": 8, "module": "Color001", "usage": "ParticleUpdate", "input": "Color", "param": "Color_Core", "type_hint": "color"}, # Light Group Binding {"emitter_index": 5, "module": "InitializeParticle", "usage": "ParticleSpawn", "input": "Color", "param": "Color_Spark", "type_hint": "color"}, {"emitter_index": 7, "module": "InitializeParticle", "usage": "ParticleSpawn", "input": "Color", "param": "Color_Spark", "type_hint": "color"}, # Atmosphere layer binding (similar structures omitted) ] } After obtaining the parameter injection configuration information (configuration JSON) through the AI ​​agent, step 203, parameter injection, is executed. Specifically, after receiving the configuration JSON generated by the AI ​​agent, the injection script automatically performs the following operations: First, it checks whether an asset with the same name already exists in the target path of the target particle system. If not, it copies a preset copy (particle system copy) from the target particle system. Then, it iterates through the user_params list in the configuration JSON and adds User Parameters (supporting types such as color, float, bool, and vector) to the top level of the preset copy system one by one through the engine bridging interface. Next, it iterates through the bindings list and links each User Parameter to the module input of the corresponding emitter, establishing a parameter-driven relationship. Finally, it calls the compile and save interface to persist the modifications to disk and saves the injected configuration as a JSON file for subsequent reuse and auditing. The parameter injection can be implemented using the following code: def inject(config): source = config["source"] dest_dir = config["dest_dir"] dest_name = config["dest_name"] dest_path = f"{dest_dir} / {dest_name}" # Copy the source system to a preset copy (or load an existing copy). if EditorAssetLibrary.does_asset_exist(dest_path): system = bridge.load_niagara_system(dest_path) else: system = bridge.duplicate_niagara_system( source, dest_dir, dest_name) # Add User Parameter for p in config["user_params"]: bridge.add_user_parameter( system, p["name"], p["type"], p["default"]) # Establish binding relationship for b in config["bindings"]: bridge.link_user_parameter_to_module_input( system b["emitter_index"], b["usage"], b["module"], b["input"], b["param"], b["type_hint"], ) # Compile and save bridge.compile_and_save_system(system) # Persistent configuration for later reuse config_file = f"{CONFIG_DIR} / {dest_name}_config.json" save_json(config, config_file) Finally, step 204, closed-loop verification and iterative correction, is executed. Specifically, after parameter injection, the AI ​​agent proactively verifies the newly created preset copy. The AI ​​agent uses the tool to call ExportSystemSpec to re-export the complete structure of the preset copy, checking one by one whether each User Parameter has been created and is of the correct type; then, it uses GetModuleInputs to traverse the module inputs of each target transmitter to confirm that the binding relationship has taken effect (the module input has been linked to the corresponding User Parameter rather than a hard-coded value); finally, it performs compilation verification to ensure there are no compilation errors such as type mismatches or circular dependencies. If any check fails, the agent analyzes the specific reason (such as variations in module names in different asset packages, incompatible input types, etc.), automatically adjusts the configuration scheme, and re-executes injection and verification to form a closed loop. The operation log accumulates with each verification iteration and is injected back into the agent's context window to ensure the consistency of the state between multiple rounds of correction.

[0083] Specifically, the AI ​​agent's verification and iterative correction of the preset copy can be implemented using the following code: # 1. Export the structure of a preset copy (target path, not the source system) preset_path = f"{config['dest_dir']} / {config['dest_name']}" spec = agent.call_tool("bridge_call", { "function": "ExportSystemSpec", "system_path": preset_path }) # 2. Verify User Parameter Creation for param in config["user_params"]: found = any( p["name"] == param["name"] for p in spec["user_parameters"] ) if not found: agent.log(f"UP {param['name']} Not created, retry") agent.retry_add_parameter(param) # 3. Verify binding relationship for binding in config["bindings"]: inputs = agent.call_tool("bridge_call", { "function": "GetModuleInputs", "emitter_index": binding["emitter_index"], "module_name": binding["module"] }) if not is_linked(inputs, binding["input"], binding["param"]): agent.log(f"Emitter[{binding['emitter_index']}]" "binding not working, trying an alternative module path") # 4. Compilation and Verification result = agent.call_tool("compile_system", {}) if not result["success"]: agent.analyze_and_retry(result["errors"]) # 5. Operation Log Reinjection agent.append_operation_log("verify_preset", { "params_ok": all_params_found, "bindings_ok": all_bindings_linked, "compile_ok": result["success"] }) Thus, the above code can be used to verify and iteratively correct the generated special effects template, ultimately obtaining the target special effects template that has passed verification.

[0084] This embodiment also provides a particle effect parameter processing device, which can be integrated into a terminal device. For example, such as... Figure 3As shown, the device for processing the particle effect parameters may include: Loading module 301 is used to load the target particle system and obtain the feature data of each particle emitter. The feature data includes at least the position and brightness value of the target color module. The target particle system includes multiple particle emitters. The semantic analysis module 302 is used to perform semantic analysis on the feature data of each particle emitter using a preset AI agent to obtain semantic recognition results. The semantic recognition results include the brightness level of each particle emitter. The AI ​​agent is injected with the domain knowledge of the particle system. The domain knowledge includes brightness stratification rules for stratifying particle emitters based on brightness values. The brightness stratification rules are used to divide the particle emitters into at least two brightness levels according to a preset brightness threshold. The configuration information generation module 303 is used to determine the color parameter group corresponding to each particle emitter according to the brightness level of each particle emitter, and to generate parameter injection configuration information according to the color parameter group corresponding to each particle emitter and the color binding path corresponding to each color parameter group. Template generation module 304 is used to generate target effect templates based on parameter injection configuration information and target particle system.

[0085] In some embodiments, the semantic analysis module 302 is used to perform brightness stratification using brightness stratification rules and the brightness value corresponding to each particle emitter to obtain the brightness level of each particle emitter; and to obtain the semantic recognition result based on the brightness level of each particle emitter.

[0086] In some embodiments, the semantic analysis module 302 is configured to, when the preset brightness threshold includes a first preset brightness value and a second preset brightness value, classify particle emitters with brightness values ​​greater than the first preset brightness value into a first brightness layer, classify particle emitters with brightness values ​​between the first preset brightness value and the second preset brightness value into a second brightness layer, and classify particle emitters with brightness values ​​less than the second preset brightness value into a third brightness layer, according to brightness stratification rules.

[0087] In some embodiments, the semantic analysis module 302 is used to perform constraint detection on the target color module of each particle emitter using the color multiplication rule when the domain knowledge includes the color multiplication rule, to obtain the color constraint result of each particle emitter, wherein the color multiplication rule includes the correspondence between the final color, initial color and scaled color of the particle; and to obtain the semantic recognition result based on the color constraint result of each particle emitter and the brightness level of each particle emitter.

[0088] In some embodiments, the semantic analysis module 302 is used to identify the execution stage of the target color module of each particle emitter using the module execution stage rules when the domain knowledge also includes module execution stage rules, thereby obtaining particle stage information of the target color module of each particle emitter. The module execution stage rules are used to indicate the behavioral characteristics of modules at different execution stages in the target particle system. Based on the particle stage information of the target color module of each particle emitter, the color constraint results of each particle emitter, and the brightness level of each particle emitter, a semantic recognition result is obtained.

[0089] In some embodiments, the semantic analysis module 302 is used to determine the color configuration mode of the target particle system based on whether the target particle system already has a first user parameter of color class; and to generate parameter injection configuration information based on the color configuration mode, the color parameter group corresponding to each particle emitter, and the color binding path corresponding to each color parameter group.

[0090] In some embodiments, the semantic analysis module 302 is used to determine the color configuration mode as hue offset mode if the target particle system already has a first user parameter; and to determine the color configuration mode as color derivation mode if the target particle system does not have a first user parameter, wherein the color derivation mode is used to indicate the second user parameter of the newly created color class and bind the second user parameter to the target color module of each particle emitter.

[0091] In some embodiments, the loading module 301 is used to load the target particle system, detect the renderer type, color module, and material texture in each particle emitter, and obtain renderer type information, color module information, and texture resource information for each particle emitter, wherein the color module information includes the position and brightness value of the target color module; and obtain feature data for each particle emitter based on the renderer type information, color module information, and texture resource information of each particle emitter, wherein the feature data includes renderer type information, the position and brightness value of the target color module, and texture resource information.

[0092] In some embodiments, the loading module 301 is used to detect the color modules in each particle emitter according to a preset color module detection order, determine the target color module from the color modules of the particle emitter, obtain the module information of the target color module, and use the module information of the target color module as the target color module information of the particle emitter.

[0093] In some embodiments, the template generation module 304 is used to copy the target particle system and create a particle system copy; and to generate a target effect template based on the parameter injection configuration information and the particle system copy.

[0094] In some embodiments, the template generation module 304 is used to generate an initial special effects template based on parameter injection configuration information and a particle system copy; perform multi-level verification on the initial special effects template using an AI agent; if any level of verification fails, the parameter injection configuration information is corrected using the AI ​​agent to obtain corrected parameter injection configuration information; and generate a target special effects template based on the corrected parameter injection configuration information and the particle system copy.

[0095] Accordingly, this application also provides an electronic device, which can be a terminal, such as a smartphone, tablet computer, laptop computer, touch screen, game console, personal computer (PC), personal digital assistant (PDA), or other terminal device. Alternatively, the electronic device can be a server.

[0096] like Figure 4 As shown, Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device 1100 includes a processor 1101 with one or more processing cores, a memory 1102 with one or more computer-readable storage media, and a computer program stored on the memory 1102 and executable on the processor. The processor 1101 and the memory 1102 are electrically connected. Those skilled in the art will understand that the electronic device structure shown in the figure does not constitute a limitation on the electronic device, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0097] The processor 1101 is the control center of the electronic device 1100. It connects various parts of the electronic device 1100 via various interfaces and lines. By running or loading software programs and / or units stored in the memory 1102, and by calling data stored in the memory 1102, it executes various functions of the electronic device 1100 and processes data, thereby providing overall monitoring of the electronic device 1100. The processor 1101 can be a central processing unit (CPU), a graphics processing unit (GPU), a network processor (NP), etc., and can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application.

[0098] In this embodiment, the processor 1101 in the electronic device 1100 loads the instructions corresponding to the processes of one or more applications into the memory 1102 according to the following steps, and the processor 1101 runs the applications stored in the memory 1102 to realize various functions, such as: loading the target particle system to obtain the feature data of each particle emitter, the feature data including at least the position and brightness value of the target color module, the target particle system including multiple particle emitters; using a preset AI agent to perform semantic analysis on the feature data of each particle emitter to obtain semantic recognition results, wherein the semantic recognition results include the brightness level of each particle emitter, the AI ​​agent is injected with the domain knowledge of the particle system, the domain knowledge includes brightness layering rules for layering particle emitters based on brightness values, the brightness layering rules are used to divide the particle emitters into at least two brightness levels according to a preset brightness threshold; determining the color parameter group corresponding to each particle emitter according to the brightness level of each particle emitter, and generating parameter injection configuration information according to the color parameter group corresponding to each particle emitter and the color binding path corresponding to each color parameter group; generating a target special effect template according to the parameter injection configuration information and the target particle system.

[0099] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0100] Optional, such as Figure 4 As shown, the electronic device 1100 also includes: a touch display screen 1103, a radio frequency circuit 1104, an audio circuit 1105, an input unit 1106, and a power supply 1107. The processor 1101 is electrically connected to the touch display screen 1103, the radio frequency circuit 1104, the audio circuit 1105, the input unit 1106, and the power supply 1107. Those skilled in the art will understand that... Figure 4 The electronic device structure shown does not constitute a limitation on the electronic device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0101] The touch display screen 1103 can be used to display a graphical user interface (GUI) and receive operation commands generated by the user interacting with the GUI. The touch display screen 1103 may include a display panel and a touch panel. The display panel can be used to display information input by the user or information provided to the user, as well as various graphical user interfaces of the electronic device. These graphical user interfaces can be composed of graphics, text, icons, video, and any combination thereof. Optionally, the display panel can be configured using a liquid crystal display (LCD), organic light-emitting diode (OLED), or other similar technologies. The touch panel can be used to collect touch operations performed by the user on or near it (such as operations performed by the user using a finger, stylus, or any suitable object or accessory on or near the touch panel), generate corresponding operation commands, and execute the corresponding program according to the operation commands. Optionally, the touch panel may include a touch detection device and a touch controller. The touch detection device detects the user's touch location and the signal generated by the touch operation, transmitting the signal to the touch controller. The touch controller receives touch information from the touch detection device, converts it into touch point coordinates, and sends it to the processor 1101. It can also receive and execute commands from the processor 1101. The touch panel can cover the display panel. When the touch panel detects a touch operation on or near it, it transmits the information to the processor 1101 to determine the type of touch event. Subsequently, the processor 1101 provides corresponding visual output on the display panel based on the type of touch event. In this embodiment, the touch panel and the display panel can be integrated into the touch display screen 1103 to achieve input and output functions. However, in some embodiments, the touch panel and the touch display screen 1103 can be implemented as two independent components to achieve input and output functions. That is, the touch display screen 1103 can also be used as part of the input unit 1106 to achieve input functions.

[0102] The radio frequency circuit 1104 can be used to transmit and receive radio frequency signals to establish wireless communication with network devices or other electronic devices, and to transmit and receive signals with network devices or other electronic devices.

[0103] Audio circuit 1105 can be used to provide an audio interface between a user and an electronic device via a speaker and a microphone. Audio circuit 1105 can convert received audio data into electrical signals and transmit them to the speaker, where the speaker converts them into sound signals for output. Conversely, the microphone converts collected sound signals into electrical signals, which are then received by audio circuit 1105, converted back into audio data, and then processed by processor 1101 before being transmitted via radio frequency circuit 1104 to, for example, another electronic device, or output to memory 1102 for further processing. Audio circuit 1105 may also include an earphone jack to provide communication between peripheral headphones and electronic devices.

[0104] The input unit 1106 can be used to receive input numbers, characters, or user characteristic information (such as fingerprints, iris, facial information, etc.), and to generate keyboard, mouse, joystick, optical, or trackball signal inputs related to user settings and function control.

[0105] Power supply 1107 is used to supply power to various components of electronic device 1100. Optionally, power supply 1107 can be logically connected to processor 1101 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. Power supply 1107 may also include one or more DC or AC power supplies, recharging systems, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0106] although Figure 4 As not shown in the diagram, the electronic device 1100 may also include a camera, sensor, wireless fidelity module, Bluetooth module, etc., which will not be described in detail here.

[0107] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0108] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0109] To this end, embodiments of this application provide a computer-readable storage medium storing multiple computer programs that can be loaded by a processor to execute any of the particle effect parameter processing methods provided in this application. The computer program can execute the following steps of the particle effect parameter processing method: loading a target particle system to obtain feature data for each particle emitter, the feature data including at least the position and brightness value of a target color module, the target particle system including multiple particle emitters; performing semantic analysis on the feature data of each particle emitter using a preset AI agent to obtain semantic recognition results, wherein the semantic recognition results include the brightness level of each particle emitter, the AI ​​agent injecting domain knowledge of the particle system, the domain knowledge including brightness layering rules for layering particle emitters based on brightness values, the brightness layering rules being used to divide particle emitters into at least two brightness levels according to a preset brightness threshold; determining the color parameter group corresponding to each particle emitter based on its brightness level, and generating parameter injection configuration information based on the color parameter group and the color binding path corresponding to each color parameter group; and generating a target effect template based on the parameter injection configuration information and the target particle system.

[0110] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0111] The computer-readable storage medium may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0112] Since the computer program stored in the computer-readable storage medium can execute any of the particle effect parameter processing methods provided in the embodiments of this application, it can achieve the beneficial effects that any of the particle effect parameter processing methods provided in the embodiments of this application can achieve, as detailed in the preceding embodiments, and will not be repeated here.

[0113] According to one aspect of this application, a computer program product or computer program is also provided, comprising computer instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the electronic device to perform the methods provided in the various optional implementations of the above embodiments.

[0114] In the above embodiments of the particle effect parameter processing apparatus, computer-readable storage medium, electronic device, and computer program product, the descriptions of each embodiment have different focuses. Parts not described in detail in a particular embodiment can be referred to in the relevant descriptions of other embodiments. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process and beneficial effects of the particle effect parameter processing apparatus, computer-readable storage medium, computer program product, electronic device, and their corresponding units described above can be referred to the description of the particle effect parameter processing method in the above embodiments, and will not be repeated here.

[0115] The foregoing has provided a detailed description of a method, apparatus, electronic device, computer-readable storage medium, and computer program product for processing particle effect parameters according to embodiments of this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for processing particle effect parameters, characterized in that, include: Load the target particle system and obtain the feature data of each particle emitter. The feature data includes at least the position and brightness value of the target color module. The target particle system includes multiple particle emitters. The semantic recognition result is obtained by using a preset AI agent to perform semantic analysis on the feature data of each particle emitter. The semantic recognition result includes the brightness level of each particle emitter. The AI ​​agent is injected with the domain knowledge of the particle system. The domain knowledge includes brightness stratification rules for stratifying the particle emitters based on brightness values. The brightness stratification rules are used to divide the particle emitters into at least two brightness levels according to a preset brightness threshold. Based on the brightness level of each particle emitter, determine the color parameter group corresponding to each particle emitter, and generate parameter injection configuration information based on the color parameter group corresponding to each particle emitter and the color binding path corresponding to each color parameter group. Based on the parameter injection configuration information and the target particle system, a target special effects template is generated.

2. The method as described in claim 1, characterized in that, The process of using a pre-set AI agent to perform semantic analysis on the feature data of each particle emitter to obtain semantic recognition results includes: Brightness stratification is performed using the brightness stratification rules and the brightness value corresponding to each particle emitter to obtain the brightness stratification level of each particle emitter. The semantic recognition result is obtained based on the brightness level of each particle emitter.

3. The method as described in claim 2, characterized in that, The preset brightness threshold includes a first preset brightness value and a second preset brightness value. The step of performing brightness stratification using the brightness stratification rules and the brightness value corresponding to each particle emitter to obtain the brightness level of each particle emitter includes: According to the brightness stratification rules, from the plurality of particle emitters, particle emitters with brightness values ​​greater than the first preset brightness value are classified into the first brightness layer, particle emitters with brightness values ​​between the first preset brightness value and the second preset brightness value are classified into the second brightness layer, and particle emitters with brightness values ​​less than the second preset brightness value are classified into the third brightness layer.

4. The method as described in claim 1, characterized in that, The domain knowledge includes color multiplication rules. The semantic analysis of the feature data of each particle emitter using a pre-set AI agent to obtain semantic recognition results includes: The target color module of each particle emitter is constrained using the color multiplication rule to obtain the color constraint result of each particle emitter. The color multiplication rule includes the correspondence between the final color, initial color, and scaled color of the particles. The semantic recognition result is obtained based on the color constraint result of each particle emitter and the brightness level of each particle emitter.

5. The method as described in claim 1, characterized in that, The domain knowledge also includes rules for the module execution phase, wherein the semantic analysis of the feature data of each particle emitter using a pre-set AI agent to obtain semantic recognition results includes: The execution phase of the target color module of each particle emitter is identified using the module execution phase rule to obtain the particle phase information of the target color module of each particle emitter. The module execution phase rule is used to indicate the behavioral characteristics of modules in different execution phases in the target particle system. The semantic recognition result is obtained based on the particle stage information of the target color module of each particle emitter, the color constraint result of each particle emitter, and the brightness level of each particle emitter.

6. The method as described in claim 1, characterized in that, The step of generating parameter injection configuration information based on the color parameter group corresponding to each particle emitter and the color binding path corresponding to each color parameter group includes: The color configuration mode of the target particle system is determined based on whether the target particle system already has a first user parameter of color class. The parameter injection configuration information is generated based on the color configuration mode, the color parameter group corresponding to each particle emitter, and the color binding path corresponding to each color parameter group.

7. The method as described in claim 6, characterized in that, The step of determining the color configuration mode of the target particle system based on whether the target particle system already has a first user parameter for a color class includes: If the target particle system already contains the first user parameter, then the color configuration mode is determined to be the hue shift mode; If the target particle system does not have the first user parameter, then the color configuration mode is determined to be the color derivation mode, wherein the color derivation mode is used to indicate the second user parameter for creating a new color class and bind the second user parameter to the target color module of each particle emitter.

8. The method as described in claim 1, characterized in that, The loaded target particle system obtains characteristic data for each particle emitter, including: The target particle system is loaded, and the renderer type, color module, and material texture in each particle emitter are detected to obtain renderer type information, color module information, and texture resource information for each particle emitter. The color module information includes the position and brightness value of the target color module. Based on the renderer type information, color module information, and texture resource information of each particle emitter, feature data for each particle emitter is obtained. The feature data includes renderer type information, the position and brightness value of the target color module, and texture resource information.

9. The method as described in claim 8, characterized in that, The step of detecting the color module in each particle emitter to obtain the target color module information for each particle emitter includes: For each particle emitter, the color modules in the particle emitter are detected according to a preset color module detection order. The target color module is determined from the color modules of the particle emitter, and the module information of the target color module is obtained. The module information of the target color module is used as the target color module information of the particle emitter.

10. The method according to any one of claims 1-9, characterized in that, The step of generating a target special effects template based on the injected configuration information and the target particle system includes: Copy the target particle system to create a copy of the particle system; Based on the parameter injection configuration information and the particle system copy, a target effect template is generated.

11. The method as described in claim 10, characterized in that, The step of generating a target special effects template based on the injected configuration information and the particle system copy includes: Based on the parameter injection configuration information and the particle system copy, an initial special effects template is generated; The AI ​​agent performs multi-level verification on the initial special effects template. If any level of verification fails, the AI ​​agent is used to correct the parameter injection configuration information to obtain the corrected parameter injection configuration information. The target effect template is generated based on the revised parameter injection configuration information and the particle system copy.

12. A device for processing particle effect parameters, characterized in that, include: A loading module is used to load the target particle system and obtain the feature data of each particle emitter. The feature data includes at least the position and brightness value of the target color module. The target particle system includes multiple particle emitters. The semantic analysis module is used to perform semantic analysis on the feature data of each particle emitter using a preset AI agent to obtain semantic recognition results. The semantic recognition results include the brightness level of each particle emitter. The AI ​​agent is injected with domain knowledge of the particle system. The domain knowledge includes brightness stratification rules for stratifying the particle emitters based on brightness values. The brightness stratification rules are used to divide the particle emitters into at least two brightness levels according to a preset brightness threshold. The configuration information generation module is used to determine the color parameter group corresponding to each particle emitter based on the brightness level of each particle emitter, and to generate parameter injection configuration information based on the color parameter group corresponding to each particle emitter and the color binding path corresponding to each color parameter group. The template generation module is used to generate a target special effects template based on the configuration information injected by the parameters and the target particle system.

13. An electronic device, characterized in that, The device includes a processor and a memory, the memory storing multiple instructions; the processor loads instructions from the memory to perform the steps of the particle effect parameter processing method as described in any one of claims 1 to 11.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a plurality of instructions adapted for loading by a processor to perform the steps of the particle effect parameter processing method as described in any one of claims 1 to 11.

Images