A declarative path and spline curve analysis method, system, device and medium

Abstract

The application discloses a declarative path and spline curve analysis method, system, device and medium, relates to the technical field of game engines and computer data processing, and comprises the following steps: acquiring a path reference, determining a curve abstraction of the path according to the path reference, and using the curve abstraction to at least obtain the position of a point along the curve arc length, the tangent direction along the curve arc length and the total arc length of the curve; and providing the curve abstraction to at least one path consumer end respectively, so that each path consumer end references the path in a consistent manner and completes the respective game functions. The application can make the path sampling completed by the built-in engine, avoid the inconsistency problem caused by the respective analysis of the paths by each consumer end, and make all game function modules depending on the curve converge into pure data configuration.

Description

Technical Field

[0001] This invention relates to the fields of game engines and computer data processing technology, specifically to a declarative path and spline curve parsing method, system, device, and medium. Background Technology

[0002] In game engines that are natively AI-driven and execute zero code at runtime, all game content is pure data configuration. Paths and spline curves are among the most mathematically dense data structures in 3D games. Unlike static meshes, which are used once generated, paths need to be continuously sampled, followed, distributed, and swept. Each consumption operation requires retrieving the point, tangent, normal, and arc length at a specific parameter from the curve. Therefore, to incorporate curves into a pure data engine, the sampling mathematics must be implemented as a built-in primitive, and a unified path resolution entry point must be provided, ensuring that all consumers reference the same curve in a completely consistent manner. Otherwise, the more consumers there are, the greater the inconsistencies and flaws in their individual resolution.

[0003] In existing technologies, Unity's Splines package provides spline data structures and the SplineUtility sampling application programming interface (API) for obtaining points, tangents, and up vectors. Cinemachine's dolly track allows the camera to move along the spline. Unreal Engine's Spline component stores spline points and provides sampling functions such as GetLocationAtDistanceAlongSpline, while the SplineMesh component deforms a section of mesh along the spline. In addition, there are numerous independent spline mathematics libraries that provide functions for evaluating, differentiating, and integrating arc lengths of Bézier curves, Catmull-Rom curves, and B-splines. In game development practice, the most common approach is to write a separate pathfinder script for each game, manually maintaining waypoint indices, manually calculating interpolations between waypoints, manually writing loop or stop logic after reaching the destination, and manually writing a loop to place an object every few meters.

[0004] The aforementioned existing solutions have the following drawbacks. In Unity's Splines package and Cinemachine track camera, sampling and following are both implemented by calling APIs via C# scripts. Application developers need to write code to obtain the position and write coroutines to move along the track. Artificial intelligence cannot write such scripts, nor is it allowed to execute these scripts at runtime. Bringing them into runtime would constitute a new instruction stream for runtime execution, which conflicts with the no-code execution architecture. Spline data, following logic, and distribution logic are each independent components and scripts, and there is no path parser architecture shared by following, distribution, connection, road, and sweep. There is no closed-set validation of the entire configuration during the loading period. In Unreal Engine's Spline component and SplineMesh, sampling and consumption are still handled by C++ or Blueprint calls. Blueprints are ultimately compiled into bytecode and executed by the virtual machine. Adding spline logic at runtime is part of the runtime instruction stream. SplineMesh, spline placement, and spline-driven cameras are all independent classes, not sharing a path resolution entry point that can be directly written using pure data configuration. Flattening terrain along splines requires manual manipulation within the editor using Landscape's spline tools, and the output is dead data baked into the level, which AI cannot declare on the spot. The independent spline math library provides a set of function-call-style mathematical interfaces that require code to call; it is not a pure data description that can be fully verified at load time. This library only answers the question of finding the value of a parameter given a control point, not the name of the path, which subsystems are consuming the path, or whether the consumption is legal. Furthermore, there is no concept of a path reference being uniformly resolved by multiple game subsystems or the existence of the path name being verified at load time. In handwritten pathfinders and game-by-game patrol and conveyor scripts, sampling, distribution, and sweeping do not share code. The form of path references varies in different scripts. Furthermore, the same logic of looping along a closed path and reporting an event once per loop is repeatedly implemented in each game and has its own defects.

[0005] In summary, existing technical solutions fail to meet the constraints of pure data description, load-time verification, runtime zero-code execution, and a single parser shared across multiple consumer ends. In traditional engines, path and spline curve sampling, arc length parameterization, and path following can only be accomplished by application developers writing separate runtime scripts for each game. Artificial intelligence (AI) cannot write or is not permitted to execute these scripts at runtime, directly conflicting with the AI-native, runtime zero-code execution engine architecture. Furthermore, if each consumer parses the same path in different ways, inconsistencies and repeated errors will occur, lacking a unified path parser. Road conforming to terrain, runtime polyline bearing, and sweep geometry also lack unified data solutions. Therefore, a new technical solution is needed, centered on a unified path parser, converging path definition, sampling mathematics, and all game function consumers that depend on curves into a load-time verifiable pure data configuration. This allows AI to describe paths and drive all game functions that depend on curves using only a declarative configuration without adding any new instruction streams at runtime. Summary of the Invention

[0006] To address at least some of the technical problems in the prior art, this invention provides a declarative path and spline curve analysis method, system, device, and medium. Specifically, this invention includes the following:

[0007] A first aspect of the present invention provides a declarative path and spline curve parsing method, the specific technical solution of which is as follows: Obtain a path reference, and determine the curve abstraction of the path based on the path reference. The curve abstraction is at least used to determine the position of the point along the curve arc length, the tangent direction along the curve arc length, and the total arc length of the curve. The curves are abstracted and provided to at least one path consumer, so that each path consumer references the path in a consistent manner and completes its respective game function.

[0008] The beneficial effects of the declarative path and spline curve analysis method provided by this invention are as follows: By obtaining path references and determining the path's curve abstraction based on these references, the engine handles mathematical operations such as path and spline curve sampling, arc length parameterization, and tangent determination internally. Application developers can obtain sampleable curve abstractions without writing runtime scripts, solving the technical problem in traditional engines where path sampling requires writing separate runtime scripts for each game, conflicting with the zero-code runtime architecture. By providing curve abstractions to at least one path consumer and ensuring that each consumer references paths in a consistent manner, all game functional modules that rely on curves, such as following, distribution, connection, roads, and sweeping, obtain data from the same curve abstraction. This avoids inconsistencies and silent errors caused by each path consumer resolving paths independently, resolving the technical problem of repeated errors between consumers due to the lack of a unified path resolver.

[0009] Furthermore, the path reference source includes at least one of named static paths and runtime-growing ordered point buffers; The named static path is constructed from a list of points according to curve types and identified by a path name; the runtime can grow an ordered point buffer, which is an ordered 3D point table named after the entity component, and points can be added one by one during runtime.

[0010] Furthermore, the path consumer includes a sampled value function consumer; The consumer provides the curve as a pure data value function that can be read. The pure data value function includes at least: a function for determining the position of a point along the arc length of the curve, a function for determining the tangent direction along the arc length of the curve, and a function for determining the total arc length of the curve.

[0011] Furthermore, the path consumer end includes a follower consumer end and a distributed consumer end; The following consumer terminal abstracts the position of the point from the curve to determine the advancing position, obtains the total arc length to determine whether the endpoint has been reached, and obtains the tangent direction to determine the orientation of the entity. The distributed consumer terminal obtains the position of the point from the curve abstraction to determine the placement position, obtains the side normal to determine the offset direction, obtains the tangent direction to determine the entity orientation, and places the entity along a preset interval of the total arc length; the side normal is determined by rotating within a preset plane according to the tangent provided by the curve abstraction.

[0012] Furthermore, the path consumer end includes the connected consumer end; The connected consumer end renders a thin line between the entity and the target entity and resolders it frame by frame as either end moves. The connected consumer terminal is also used to obtain a connecting corridor with a limited number of turns on the grid chessboard, and write the inflection points of the connecting corridor into the runtime growable ordered point buffer.

[0013] Furthermore, the path consumption end includes a road consumption end and a sweeping consumption end; The road consumer end obtains the location of the point from the curve to determine the height profile, obtains the total arc length to determine the flattening range, flattens the ground surface along the path and lays the road surface; The sweeping consumer end obtains the position of the point from the curve abstraction to determine the placement position of the cross section, obtains the tangent direction and the side normal to determine the orientation of the cross section, and gradually places the selected cross section along the curve and stitches it into a mesh; the side normal is determined by rotating in a preset plane according to the tangent provided by the curve abstraction.

[0014] Furthermore, the path and the path consumer are statically compiled closed sets, configured as pure data, and evaluated by reference at runtime, without generating any new instruction streams throughout the process; Before determining the curve abstraction of the path based on the path reference, the method further includes: validating the validity of the path reference, the validation including at least: Has the path already been declared? Does the configuration parameter of the path consumer meet the preset configuration conditions? Does the way the path consumer references the path meet the preset access conditions?

[0015] A second aspect of the present invention provides a declarative path and spline curve parsing system, the specific technical solution of which includes: a path parsing module and a curve distribution module; The path parsing module is used to obtain path references and determine the curve abstraction of the path based on the path references. The curve abstraction is used at least to determine the position of the point along the curve arc length, the tangent direction along the curve arc length, and the total arc length of the curve. The curve distribution module is used to abstract the curve and provide it to at least one path consumer, so that each path consumer can reference the path in a consistent manner and complete its respective game function.

[0016] Furthermore, the path reference source includes at least one of named static paths and runtime-growing ordered point buffers; The named static path is constructed from a list of points according to curve types and identified by a path name; the runtime can grow an ordered point buffer, which is an ordered 3D point table named after the entity component, and points can be added one by one during runtime.

[0017] Furthermore, the path consumer includes a sampled value function consumer; The consumer provides the curve as a pure data value function that can be read. The pure data value function includes at least: a function for determining the position of a point along the arc length of the curve, a function for determining the tangent direction along the arc length of the curve, and a function for determining the total arc length of the curve.

[0018] Furthermore, the path consumer end includes a follower consumer end and a distributed consumer end; The following consumer terminal abstracts the position of the point from the curve to determine the advancing position, obtains the total arc length to determine whether the endpoint has been reached, and obtains the tangent direction to determine the orientation of the entity. The distributed consumer terminal obtains the position of the point from the curve abstraction to determine the placement position, obtains the side normal to determine the offset direction, obtains the tangent direction to determine the entity orientation, and places the entity along a preset interval of the total arc length; the side normal is determined by rotating within a preset plane according to the tangent provided by the curve abstraction.

[0019] Furthermore, the path consumer end includes the connected consumer end; The connected consumer end renders a thin line between the entity and the target entity and resolders it frame by frame as either end moves. The connected consumer terminal is also used to obtain a connecting corridor with a limited number of turns on the grid chessboard, and write the inflection points of the connecting corridor into the runtime growable ordered point buffer.

[0020] Furthermore, the path consumption end includes a road consumption end and a sweeping consumption end; The road consumer end obtains the location of the point from the curve to determine the height profile, obtains the total arc length to determine the flattening range, flattens the ground surface along the path and lays the road surface; The sweeping consumer end obtains the position of the point from the curve abstraction to determine the placement position of the cross section, obtains the tangent direction and the side normal to determine the orientation of the cross section, and gradually places the selected cross section along the curve and stitches it into a mesh; the side normal is determined by rotating in a preset plane according to the tangent provided by the curve abstraction.

[0021] Furthermore, the path and the path consumer are statically compiled closed sets, configured as pure data, and evaluated by reference at runtime, without generating any new instruction streams throughout the process; Before determining the curve abstraction of the path based on the path reference, the method further includes: validating the validity of the path reference, the validation including at least: Has the path already been declared? Does the configuration parameter of the path consumer meet the preset configuration conditions? Does the way the path consumer references the path meet the preset access conditions?

[0022] A third aspect of the present invention provides a computer device including a processor coupled to a memory storing at least one computer program, the at least one computer program being loaded and executed by the processor to enable the computer device to perform any of the methods described above.

[0023] A fourth aspect of the present invention provides a computer-readable storage medium storing at least one computer program, the at least one computer program being loaded and executed by a processor to enable a computer to perform any of the methods described above.

[0024] It should be noted that the beneficial effects of the technical solutions of the second to fourth aspects of the present invention and their corresponding possible implementations can be found in the above description of the technical effects of the first aspect and its corresponding possible implementations, and will not be repeated here. Attached Figure Description

[0025] Figure 1 This is a schematic diagram of the overall architecture of a declarative path and spline curve parsing method according to an embodiment of the present invention; Figure 2 This is a schematic diagram illustrating the complete process from path definition to multiple consumer ends of a declarative path and spline curve parsing method according to an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of the present invention clearer, the embodiments of the present invention will be described in further detail below with reference to the accompanying drawings.

[0027] Figure 1 This is a schematic diagram of the overall architecture of the declarative path and spline curve parsing method provided in the embodiments of the present invention. Figure 1 In this context, path definitions are used to provide the source of path references, including named static paths from the load phase and runtime-growing ordered point buffers (corresponding to...). Figure 1 (Referring to the "runtime-growing polyline buffer" in the text). The unified path resolver receives path references from path definitions and produces curve abstractions. Each path consumer obtains the curve abstraction from the unified path resolver and references the path in a consistent manner. When the path reference originates from a named static path, such as... Figure 1 The load-time validator shown is connected by a dashed line to the path definition and the unified path resolver. It is used to perform pre-validation of the validity of path references during load time. When the path reference originates from a runtime growable ordered point buffer, a runtime validator also exists. Figure 1(Not shown in the diagram, but with the same function and connection as the "Loading Period Verifier") is connected to the path definition and unified path resolver to perform pre-validation of the validity of path references at runtime.

[0028] Figure 2 This is a schematic diagram illustrating the complete process from path definition to multiple consumer terminals provided in an embodiment of the present invention. Figure 2 In Chinese, path references (corresponding to) Figure 2 The phrase "a path reference" indicates the initial step in obtaining a path reference, which can be a named static path or a runtime-growing ordered point buffer. After validation, the path reference is input into the unified path resolver, which then produces a curve abstraction (corresponding to...). Figure 2 The "standard curve abstract node" provides the location of the point along the curve's arc length (corresponding to...). Figure 2 The "finding points by arc length" method and the method of determining the tangent direction along the arc length of the curve (corresponding to...) Figure 2 The "finding the tangent" and the calculation of the total arc length of the curve (corresponding to) Figure 2 The ability to "calculate the total length" in the text. Subsequently, the curve abstraction flows to multiple path consumer branches, namely the sampled value function consumer branch (corresponding to...). Figure 2 The "sample value function" in the text), and the consumer branch (corresponding to) Figure 2 The "follow" in the text), distributed consumer-side branches (corresponding to) Figure 2 The "distribution" in the text), connecting the consumer-side branches (corresponding to) Figure 2 The "connections and corridors" in the middle), and the road consumption end branches (corresponding to) Figure 2 The "roads" in the text) and the sweeping consumer-end branches (corresponding to Figure 2 (The "sweep" in the text). Multiple consumer-side branches ultimately converge on gameplay features (corresponding to...). Figure 2 (The "play method" in the text).

[0029] A declarative path and spline curve parsing method according to an embodiment of the present invention includes the following steps: S1, obtain the path reference, and determine the curve abstraction of the path based on the path reference. The curve abstraction is at least used to determine the position of the point along the curve arc length, the tangent direction along the curve arc length, and the total arc length of the curve. The specific implementation is as follows.

[0030] like Figure 1 as well as Figure 2 As shown, during the game engine's loading or runtime, path references are first obtained. A path reference is a name or handle used to identify and locate a path. After obtaining the path reference, it is input into the unified path resolver, which then retrieves path data from the corresponding data source based on the path reference and produces a curve abstraction.

[0031] In a preferred implementation, the path reference source includes at least one of named static paths and runtime-growing ordered point buffers. Specifically, the path reference can be the path name of a named static path or the buffer name of a runtime-growing ordered point buffer. The named static path is constructed by the application developer during loading from a series of points according to curve types, including straight lines or smooth curves, which can be marked as closed or open. It is fixed as an immutable curve during loading and uniquely identified by the path name. Subsequent path consumers reference this path using the path name. The runtime-growing ordered point buffer is a named, persistent, ordered 3D point table within entity components. New points can be added point by point during runtime, the entire table can be cleared, and a ring-shaped upper limit can be set. When the upper limit is exceeded, the oldest point is discarded. During consumption, the curve is reconstructed immediately using the current points, eliminating cache staleness issues. An entity component system (ECS) refers to a data-driven game object architecture where entities, components, and the system are separated, characterized by continuous data storage and batch processing.

[0032] This implementation scheme converges path reference sources and path sampling methods into a unified path resolver. The resolution implementation for any path reference form only appears within this unified path resolver. The unified path resolver's internal implementation consists of two parts: a canonical parsing function and a thin context adaptation layer. The canonical parsing function is responsible for the normalization of path references. Its internal process includes: receiving path references and performing source assignment and point table retrieval. When the path reference is a named static path, a two-level lookup is performed: first, the corresponding path definition is found based on the path name; then, point data is retrieved from the path definition, and the path's world offset, rotation, and scaling information are accumulated and reported accordingly. When the path reference is a runtime-growing ordered point buffer, the currently stored point data is directly retrieved from the buffer. The process then proceeds to the curve construction stage, where the point data is exported as corresponding handles based on the curve type. If the number of point data is insufficient, it degenerates into straight line processing. After curve construction, the arc length baking stage begins, where the curve is subdivided into smaller segments, the chord lengths of each segment are accumulated to obtain the total arc length, and a sampling table is established from the arc length to the normalized parameter t. After the arc length is baked, it is assembled into a curve abstraction. This curve abstraction provides the ability to obtain the position of a point along the curve's arc length, the direction of the tangent along the curve's arc length, and the total arc length of the curve. Point finding is achieved using a bisection method combined with segment interpolation, tangent finding is achieved by performing a central difference on the point finding results, and the conversion of the normalized parameter t to arc length is achieved by multiplying t by the total arc length. It also provides a horizontal plane nearest point lookup as an auxiliary capability. After the curve abstraction is assembled, it is synthesized with the world offset to output the final curve abstraction. The thin context adaptation layer refers to the semantic translation layer of each path consumer. Its "thinness" is verifiable by the following criteria: the thin context adaptation layer does not contain any of the five types of actions: name lookup, handle construction, arc length accumulation, sampling table bisection, and interpolation. Therefore, when adding a new path reference form, only the source assignment and point table acquisition stages in the specification parsing function need to be modified, and when adding a new curve interpolation family, only the curve construction stage in the specification parsing function needs to be modified. The thin context adaptation layers of the six path consumers do not need to be modified.

[0033] When a new path reference type needs to be added, such as a new reference method that automatically generates paths from endpoints, or a new reference method that accepts externally imported curve data, its parsing implementation is only implemented in the unified path resolver and can be shared by all path consumers without needing to be modified individually on each path consumer. The unified path resolver presents a curve abstraction: given a path reference, it produces a sampleable curve. This curve provides at least three capabilities: determining the position of a point along the curve's arc length, determining the tangent direction along the curve's arc length, and determining the total arc length of the curve; it also provides the ability to determine the side normal, which is determined by rotating the tangent within a preset plane. In the specific implementation, the preset plane is the horizontal plane, and the angle determined by the rotation is 90 degrees. Path references originate from a single parsing entry point and are unified.

[0034] When a path reference comes from a named static path, the unified path resolver searches for the corresponding path definition in the path data already constructed during loading, obtains the point sequence and curve type information of that path, and constructs the corresponding curve mathematical model. When a path reference comes from a runtime growable ordered point buffer, the unified path resolver retrieves all 3D points stored in the buffer at the current moment based on the buffer name, and reconstructs the curve in real time using these points. Regardless of the source of the path reference, the unified path resolver produces the same type of curve abstraction, so that each path consumer does not need to distinguish the source of the path reference. In specific implementation, the unified path resolver first needs to construct a complete continuous curve from the discrete point sequence through curve interpolation, and then establishes a curve abstraction based on this curve, providing the ability to obtain the position of points along the curve arc length, the tangent direction along the curve arc length, and the total arc length of the curve. Specifically, the curve interpolation methods include two types: straight lines and Catmull-Rom smoothing. When the curve type is specified as straight lines in the path definition, the unified path parser directly connects adjacent points with straight line segments, forming a continuous path composed of multiple straight line segments. When the curve type is specified as Catmull-Rom smoothing in the path definition, the unified path parser uses the point series as control points and employs the Catmull-Rom spline interpolation method to construct a smooth interpolation curve between adjacent points, resulting in a smooth and curved overall path. Regardless of whether straight lines or Catmull-Rom smoothing is used, the unified path parser produces the same type of curve abstraction.

[0035] In an alternative approach, path reference sources can also include references that are automatically generated by endpoints, such as paths directly formed by inflection points calculated from connecting corridor routes; or they can include externally imported curve data as a third source, such as Bézier curve data imported from external files or path data received from the network. In this alternative approach, the resolution of path reference sources is still completed at the unified path resolver, and the newly added sources are shared by all path consumers.

[0036] In alternative solutions, curve interpolation methods can also include at least one of Bézier curves, B-spline curves, or circular arcs. All interpolation methods expose the same curve abstraction through a unified path resolver, and each path consumer does not need to be aware of changes in the underlying interpolation method. In another alternative, curve interpolation can also use only straight lines, directly connecting adjacent points to form a path without any smoothing, thus abandoning the use of smooth curves. A Bézier curve is a smooth parametric curve defined by a set of control points. A B-spline curve is a generalization of the Bézier curve, defined piecewise by multiple control points, and possesses local support. A circular arc is a circular arc segment whose distance from the center to any point on the circumference is constant.

[0037] Curve abstraction refers to an abstract representation layer of the mathematical sampling capabilities of paths, providing at least three core mathematical capabilities: determining the position of a point along the curve's arc length, determining the tangent direction along the curve's arc length, and determining the total arc length of the curve. It may also provide the ability to determine the lateral normal. The lateral normal is not a necessary output capability of curve abstraction, but rather serves as auxiliary data that can be derived from the tangent direction, and can also be provided independently as one of the sampled value functions. In practical implementation, the total arc length of the curve can be calculated using numerical integration methods. For paths composed of straight line segments, the total arc length is the sum of the lengths of each line segment; for smooth paths constructed using Catmull-Rom spline interpolation, the total arc length can be obtained by piecewise numerical integration of the spline curve, for example, by accumulating the arc length infinitesimals of each spline curve segment using the Gauss-Legendre numerical integration method. The position of a point can be calculated by multiplying the normalized parameter t by the total arc length of the curve to obtain the target arc length. Starting from the starting point of the curve, the lengths of each segment are accumulated along the curve until the target arc length is reached. The spatial coordinates on the curve corresponding to this arc length are then determined and output as a vector. The tangent direction can be calculated using the finite difference method of adjacent point positions to obtain the unit tangent. That is, at the target point, two adjacent points on the curve before and after a small step are taken, the direction vector between the two points is calculated and normalized to a unit vector, and this vector is used as the tangent direction at that point.

[0038] In alternative solutions, the tangent direction can be directly obtained using the curve's analytical derivative, which involves a trade-off in accuracy; alternatively, it can be obtained by looking up a pre-baked tangent table by arc length, sacrificing storage space for runtime computation time. In these alternative solutions, the specific algorithm for determining the tangent direction does not affect the unified path parser's output on curve abstraction.

[0039] In a preferred embodiment, before determining the curve abstraction of the path based on the path reference, the method further includes: validating the validity of the path reference (corresponding to...). Figure 1 The "load period verifier" and Figure 2(The "illegal" branch flow in the context). Specifically, when a path reference originates from a named static path, the validity of the path reference is pre-validated during loading; when a path reference originates from a runtime growable ordered point buffer, the validity of the path reference is pre-validated during runtime. The validation includes at least the following validation items: whether the path has been declared, i.e., whether the referenced path name or buffer name has a corresponding path definition or buffer definition in the current world; whether the configuration parameters of the path consumer meet the preset configuration conditions, such as a positive width, a non-negative transition band, transparency within the range of zero to one, a positive tube radius in the cross-section parameters, and positive box width and height; whether the way the path consumer references the path meets the preset access conditions, such as the terrain corresponding to the path referenced by the road consumer must have height tiles, the distribution consumer and sweep consumer must reference declared paths, the rendering key referenced by polyline rendering must be a valid key value, the operation field value of the append action must be a valid value, and if the operation field of the append action is an unknown operation such as "pop-up", loading will be rejected. Any inconsistent path description is rejected before loading or runtime and does not enter the runtime. Only after successful validation does the unified path resolver produce curve abstractions based on path references. "This world" refers to the currently running or building game scene instance; path definitions are only valid within the game world instance in which they are declared. Path names referenced by application developers in their configurations must have already been declared in the current world's path definition set.

[0040] In the alternative approach, the content of the runtime-growing ordered point buffer does not yet exist during the loading phase. Therefore, a pre-validation of the path reference's validity is performed at runtime. This can be executed synchronously with the above validation items or as needed. Validation items include at least whether the buffer has been instantiated, whether the number of active points is not less than two, whether an upper limit overflow has been triggered, and whether it is a degradation curve. The above validation uses failure-safe semantics, meaning that if the validation fails, the current consumption is skipped without causing a crash or producing unfinished geometry. Consumption automatically resumes when the number of points in the next frame meets the conditions.

[0041] In addition, source consistency verification is included. This means that after the same path reference is processed by the unified path resolver, the curves read by each path consumer are consistent between the named static path and the runtime growable ordered point buffer. This consistency is enforced by guard tests. Guard tests, during load (or runtime) verification, enforce consistency by enumerating all combinations of path reference types and all path consumers and verifying whether the curves read by each combination are consistent.

[0042] In a preferred implementation, the paths and path consumers are statically compiled closed sets, configured as pure data, and evaluated by reference at runtime, without generating any new instruction streams. A closed set refers to paths, curves, value functions, consumer components, and actions being a finite set statically compiled during packaging, with no new types or logic added at runtime. Evaluation by reference means that each path consumer only writes the path name in its configuration. During loading, the engine establishes a mapping table from path name to path data based on this path name. At runtime, when a path consumer needs sampling, the engine looks up the corresponding curve abstraction in the mapping table based on the path name, and performs evaluation calculations based on the curve data corresponding to the curve abstraction, i.e., calculating the position of the point, the direction of the tangent (tangent), the total arc length, and other mathematical results. This process does not generate new instruction streams.

[0043] By obtaining path references and determining the curve abstraction of the path based on the path references, the mathematical operations such as path and spline curve sampling, arc length parameterization, and tangent determination are completed by the engine. Application developers can obtain sampleable curve abstractions without writing runtime scripts, which solves the technical problem in traditional engines that path sampling must rely on writing a separate runtime script for each game, which conflicts with the zero-code runtime execution architecture.

[0044] S2 abstracts the curves and provides them to at least one path consumer, enabling each path consumer to reference the path in a consistent manner and complete its respective game function. The specific implementation is as follows.

[0045] Path consumers refer to modules that use curve abstraction to complete specific game functions, including at least one of the following: sampled value function consumer, follower consumer, distributed consumer, connection consumer, road consumer, and sweep consumer. Each path consumer obtains data from the curve abstraction and references the same path in a completely consistent manner. That is, regardless of the type of consumer, when referencing the same path name, they all obtain the same curve abstraction from a unified path resolver and use the same set of sampling mathematics for evaluation.

[0046] In the implementation, the path consumer can reference a path by writing the path name in the configuration. During loading, the engine resolves the corresponding curve abstraction based on the path name and passes the curve abstraction to the path consumer at runtime. When the path consumer needs to retrieve data from the curve, the engine's built-in curve abstraction provides the calculation results for the position of the point along the curve's arc length, the tangent direction along the curve's arc length, and the total arc length of the curve. The configuration of the path consumer is completely separated from the curve evaluation logic inside the engine. The path consumer is only responsible for defining "which path to consume" and "how to consume," not for "how to obtain the path" or "how to evaluate it."

[0047] In an alternative approach, other types of consumers can be added, such as particle system consumers flowing along a path or camera consumers moving along an orbit. These newly added consumers still obtain curve abstractions from the same unified path resolver, referencing the path in a consistent manner. Alternatively, some of the six types of consumers—sampled-value function consumers, follower consumers, distributed consumers, connected consumers, road consumers, and sweeping consumers—can be omitted; adding or removing consumers does not affect the essence of the unified path resolver.

[0048] By abstracting curves and providing them to at least one path consumer, and making each path consumer reference paths in a consistent manner, all game function modules that rely on curves, such as following, distribution, connecting, roads, and sweeping, obtain data from the same curve abstraction. This avoids inconsistencies and silent errors caused by each path consumer resolving paths independently, and solves the technical problem of repeated errors between consumers due to the lack of a unified path resolver.

[0049] In a preferred embodiment, the path consumer includes a sampled value function consumer. For example... Figure 1 as well as Figure 2 As shown, the consumer side of the sampled value function (corresponding to) Figure 1 as well as Figure 2 The "sampled value function" obtains the curve abstraction from the unified path resolver. The sampled value function consumer provides the curve abstraction as readable pure data value functions, which include at least: a function for determining the position of a point along the curve's arc length, a function for determining the tangent direction along the curve's arc length, and a function for determining the total arc length of the curve. The pure data value functions also include a function for determining the side normal along the curve's arc length, which is derived by rotating the tangent direction 90 degrees in the horizontal plane.

[0050] Specifically, the sampled value function consumer exposes the three core mathematical capabilities of curve abstraction to application developers in the form of pure data-value functions. These pure data-value functions include at least the function for calculating the point position (path_point), the function for calculating the tangent direction (path_tangent), and the function for calculating the total arc length of the curve (path_length). In the specific implementation, it also includes the function for calculating the side normal (path_normal). The function for calculating the point position is used to find the position of a point on the path at a given normalization parameter t. The function for calculating the tangent direction is used to find the unit tangent direction on the path at a given normalization parameter t. The function for calculating the total arc length of the curve is used to find the total arc length of the path. The function for calculating the side normal is used to find the unit horizontal side normal direction on the path at a given normalization parameter t. The normalization parameter t ranges from 0 to 1 and is uniformly distributed according to the arc length. Internally, the engine multiplies the normalization parameter t by the total arc length of the curve to convert it into the original arc length for evaluation; application developers do not need to process the original arc length. Vector results support component sampling; for example, application developers can write expressions such as "X-axis component of the point at the one-quarter mark of the path" in the configuration. During sampling, start and end parameters can also be specified, meaning sampling is performed within the range between the start and end values ​​of the normalization parameter t, rather than necessarily the entire range from 0 to 1.

[0051] Through the sampled value function consumer, application developers can read curve data in any value expression and place any object relative to the curve, such as curbs, starting line angles, roadside props, and gates spaced at intervals, without writing any spline mathematical code. The positions and orientations of all objects derived from the curve can be plotted using the four value functions mentioned above (finding the point position, the tangent direction, the total arc length of the curve, and the side normal), eliminating the need to call spline APIs and write scripts one by one as in traditional solutions. The implementation process for some specific objects derived from the curve in terms of position and orientation is shown in the following implementation scheme.

[0052] In a preferred embodiment, the path consumer includes both follower consumers and distributed consumers. For example... Figure 1 as well as Figure 2 As shown, follow the consumer end (corresponding to) Figure 1 "Following the consumer end" and Figure 2 The "follow" in the text) and distributed consumer end (corresponding to Figure 1 "Distributed consumer end" and Figure 2 The “distribution” in the code obtains curve abstractions from the unified path resolver.

[0053] The follower consumer obtains the position of a point from the curve abstraction to determine the advancement position, obtains the total arc length to determine whether the endpoint has been reached, and obtains the tangent direction to determine the entity's orientation. Specifically, the follower consumer is a pure data component that allows an entity to advance at a constant speed along a named static path. Based on its configured speed value, the follower consumer accumulates the advancement distance by multiplying the speed by the frame duration, advancing along the arc length. After each advancement, it obtains the position of the point at the current advancement position from the curve abstraction to determine the entity's spatial position, obtains the tangent direction at the current advancement position to determine the entity's orientation, and obtains the total arc length of the curve to determine whether the current cumulative advancement distance has reached or exceeded the total arc length. The follower consumer outputs normalized progress, which is the ratio of the current cumulative advancement distance to the total arc length of the curve, with a value ranging from 0 to 1. When the entity reaches the endpoint, the follower consumer clamps the progress at the endpoint, sets a completion flag, routes the arrival event once, erases the event name, and freezes the progress after a single endpoint arrival. The following consumer also offers an optional loop mode. In loop mode, when an entity reaches the total arc length, it is no longer constrained. Instead, it subtracts one full arc length and continues to move forward with the remaining amount, making the speed at the seam continuous and without stuttering on each loop. At the same time, each loop route is a loop event and the event name is not erased, making the following consumer a loop counter. The progress attribute continues to report the normalized progress within each loop. Combined with the game's own loop count attribute, the total number of loops can be obtained.

[0054] Alternative solutions include a reciprocating mode where the entity returns along the path after reaching the destination; or a maximum number of loop iterations mode where the entity freezes after completing N loops. These alternative solutions all follow variations of the loop semantics on the consumer side and do not change the fundamental nature of the unified path resolver plus pure data components.

[0055] In some practical applications, the tracking of competitors and lap rankings in racing, endless loops in parkour, patrol loops, conveyor belt loops, and treadmill loops all fall under pure data configuration. Lap counting, ranking comparison, and lap determination are handled at the logic layer by standard event handling and aggregation selectors (e.g., counting and sorting by lap leader or progress leader within the same lap). The follower consumer is only responsible for constant-speed looping and routing one lap event per lap. The loop mode is an optional additive field; when disabled by default, it is consistent with the single-end freeze behavior byte-by-byte, and existing follower usage does not require modification.

[0056] The distributed consumer terminal obtains the position of points from the curve abstraction to determine the placement location, obtains the side normal to determine the offset direction, and obtains the tangent direction to determine the entity orientation. Entities are placed at preset intervals along the total arc length. The side normal is determined by rotating the tangent provided by the curve abstraction within a preset plane; specifically, the tangent direction is rotated 90 degrees in the horizontal plane to obtain the unit horizontal side normal. Specifically, the distributed consumer terminal is a distribution branch in the generation action, parallel to the existing disk scattering and mesh arrangement. The distributed consumer terminal is uniformly distributed along the total arc length or samples N points at fixed intervals. At each sampling point, it obtains the position, tangent direction, and side normal from the curve abstraction. At each sampling point, entities are placed according to the formula "point position + side normal × side × offset," ensuring the entities land on the road surface. Simultaneously, the yaw angle of the entities can be set to the tangent direction of the path, ensuring that doors, arrows, and angled props face along the path. When the path is a closed path, the distributed consumer terminal seamlessly connects at the seams, meaning the positions and orientations of the first and last sampling points are continuous. Each entity is a regular generated entity, inheriting the physics, geometry, and processor from its blueprint. Side offset refers to the left or right side identifier along the path's side normal direction, used to determine whether the entity is offset to the left or right relative to the path's centerline. This is directly specified by the application developer in the distributed consumer configuration. The distributed consumer can also specify start and end parameters, sampling and placing within the range between the path's start and end parameters, rather than necessarily from the path's start to end. At each sampling point, jitter can also be superimposed, adding random perturbations to the point's position and side normal offset, causing the placed entity to have random variations in position and orientation.

[0057] The distributed consumer replaces the source of transformation for each instance from disk scattering or grid layout to curve distribution. Application developers only need to add a curve-distributed sub-block configuration to the generation action. The failure mode is consistent with existing generation methods such as disk scattering and grid layout, for example, rejecting undeclared path names during validation. In some practical applications, the distributed consumer converges linear features such as road edges every few meters, ninety trees adjacent to the track, a gate facing the road every few meters, and fence posts along the wall into a cyclic configuration, which can be generalized to scenarios such as roads, rivers, fences, pipes, cables, and patrol soldiers.

[0058] By following the consumer end and distributing the consumer end, all game functions that depend on curves, such as patrol routes, conveyor belt loops, track laps and rankings, roadside props and road edges, are converged into pure data configuration. Application developers only need to configure a path plus follow or distribute configuration to achieve this, without having to write any state machine scripts or loop logic code.

[0059] In a preferred embodiment, the path consumer includes the connected consumer. For example... Figure 1 as well as Figure 2 As shown, connect to the consumer end (corresponding to) Figure 1"Connecting to the consumer end" and Figure 2 The "connections and corridors" in the code obtain curve abstractions from the unified path resolver. The connection consumer renders thin lines between the current entity and the target entity and re-welds them frame by frame as either end moves. The connection consumer is also used to obtain connection corridors with a limited number of turns on a grid chessboard and writes the inflection points of the connection corridors into a runtime-growing ordered point buffer.

[0060] Specifically, the connection consumer is a pure data component installed on the entity holding one end of the line. The connection consumer's configuration fields include target entity reference, line width, material, local offset, and target offset. The target entity reference specifies the entity the other end of the line connects to; the local offset specifies the local offset of the connection point on this entity relative to its position; and the target offset specifies the local offset of the connection point on the target entity relative to its position. At runtime, the connection consumer acquires the current positions of its own entity and the target entity each frame, rendering a thin line between the two endpoints. This line can be a thin cylindrical mesh or a bulletin board strip facing the camera, and the material can be arbitrarily specified by the application developer, including color, transparency, and self-illumination. When either end moves, the connection consumer reconstructs the thin line mesh each frame with the new position, achieving frame-by-frame re-soldering. When the target entity is destroyed or does not exist, the connection consumer hides the thin line without crashing.

[0061] In some practical applications, the connection consumer liberates the connection between two active points from a restricted capability that existed only within the effects package into a neutral geometric primitive. This restricted capability was originally soldered into the glowing effect beam, accessible only through effects actions, and rendered as a glowing laser rather than a neutral thin line. The connection consumer can describe its appearance using any material, allowing for the selection of materials such as dandelion strands, grappling hook ropes, tow cables, constellation edges, traction lines, and aiming lines. When the target entity reference resolves to null, i.e., the target entity is destroyed, the connection consumer hides the thin line without crashing, adhering to the headless mode's empty node discipline. The connection consumer reuses frame-by-frame resoldered tracking mathematics, but renders ordinary meshes rather than effects scenes, thus not introducing new tracking mechanisms; it desolders existing capabilities from the effects system.

[0062] The connection consumer is also used to obtain connecting corridors with a limited number of turns on a grid chessboard, applicable to gameplay such as connect-the-dots and line-matching puzzles. The grid chessboard is generated by a grid, with each cell carrying row and column attributes, and empty cells modeled with zero occupancy attribute. The connection consumer provides a connectivity determination function to determine whether two cells can be connected by a corridor that is entirely empty internally and changes direction no more than K times, where K defaults to 2, i.e., the standard two-turn rule. It provides a turn count calculation function to find the minimum number of turns for any connecting corridor, and a corridor routing function to calculate the minimum turning corridor and write the corridor's inflection points (including the two endpoints, world coordinates, and order) into a runtime growable ordered point buffer. "Entirely empty internally" means that none of the intermediate cells traversed by the connecting corridor are occupied, i.e., their occupancy attributes are all empty. The two-turn rule means that the connecting path can change direction at most twice, and all intermediate cells traversed by the path are unoccupied. This corridor routing function does not build its own line renderer, but instead passes the output to a reusable carrier—the runtime growable ordered point buffer—which is then displayed by a path-distributed consumer or a polyline rendering consumer. It should be noted that the fine-line rendering function of the two-entity connection consumer uses the real-time positions of the two entities and does not involve curve abstraction; its connection corridor function writes the inflection points into the runtime growable ordered point buffer, and then generates curve abstraction through the unified path resolver for use by other consumers. The connection consumer does not reference the path, which does not conflict with "runtime evaluation by reference".

[0063] By connecting to the consumer end, the connection between the two activity points is freed from the limited capabilities within the special effects package and is transformed into a neutral geometric primitive, allowing any material to describe its appearance, such as grappling hook ropes, towing cables, constellation sidings, traction lines, and aiming lines, each to be chosen as needed.

[0064] In a preferred embodiment, the path consumption end includes both road consumption end and sweeping consumption end. For example... Figure 1 as well as Figure 2 As shown, the road consumption end (corresponding to) Figure 1 "Road consumption end" and Figure 2 The "roads" in the text) and the sweeping consumer end (corresponding to Figure 1 "Sweeping away the consumer end" and Figure 2 The “sweep” in the code obtains curve abstractions from the unified path resolver.

[0065] The road consumer obtains the location of points from the curve abstraction to determine the height profile, and obtains the total arc length to determine the flattening range. It then flattens the ground surface along the path and lays the road surface. The road consumer allows application developers to declare a route that traverses the terrain, flattening the ground surface below the road surface along the curve to make it drivable or walkable without any under-road undulations, while also allowing the road surface to spread along it, eliminating the need for manually sculpting height maps or manually painting blend maps. Several roads are declared in a list on the terrain, each road referencing an existing named static path. Specifically, the road consumer is a configuration entry on the terrain, referencing an existing named static path whose curve is the centerline and whose path point height is the road surface elevation profile. The configuration parameters of the road consumer include the path reference, width, and transition zone. The width is the full width of the flattened corridor, half of which is half the width, and the transition zone is the transition margin for the ground surface to gradually return to its original undulations outside the flattened corridor. During world construction, the road consumer flattens the world elevation of the ground surface to the path points within the width, smoothing back the original undulations within the transition zone. The road surface appearance is the existing strip grid (width plus material) of the path itself, laid on the flattened surface, and its thickness is read as the roadbed. The road consumer bakes a derived heightmap of the same size during world construction, which remains static and is not re-flattened during runtime. The road consumer requires that the terrain where the referenced path is located must have heightmap tiles. On flat terrain, if there is no heightmap and only a strip road surface needs to be laid, the road without a heightmap is considered a validation error. The reason for not re-flattening during runtime is for range convergence considerations; that is, the road flattening operation is only performed once during world construction, and the surface is not dynamically modified during runtime to ensure the determinism and stability of the terrain data.

[0066] The sweep consumer obtains the position of points from the curve abstraction to determine the placement position of the cross-section, obtains the tangent direction and side normal to determine the orientation of the cross-section, and gradually places the selected cross-sections along the curve and stitches them into a mesh. The side normal is determined by rotating the tangent provided by the curve abstraction within a preset plane, specifically by rotating the tangent direction 90 degrees in the horizontal plane to obtain the unit horizontal side normal. Specifically, the sweep consumer is a pure data component with configuration fields including path reference, cross-section shape (pipe, box, and strip; pipe with radius, box with width and height, strip with width), side and offset (lateral placement, zero for centering on the line), lift (vertical lift of the cross-section), material (material block consistent with geometry), and number of segments (the number of subdivisions along the curve, defaulting to the path). During runtime or build, the sweep consumer moves along the named curve (using the same sampling method as the road surface strip), placing the selected cross-section in the curve's tangent-side normal-vertical frame at each step, laterally moving it by side × offset, and vertically lifting it by lift, stitching adjacent cross-sections into a triangular mesh. A seamless closed loop is achieved by closing the path. Lateral offset, offset, and lift are directly specified by the application developer in the sweep consumer configuration. The sweep consumer generates colliders when the host rigid body is included. The road surface strip mesh is a special case with a cross section. The sweep consumer generalizes the existing flat strip to a selected cross section with lateral offset. The same stitching loop and parameterized cross section prove that sweep is a generalization of the road surface flat strip rather than a parallel code path.

[0067] In the above approach, the sweeping consumer stitches the triangular mesh serially within the central processing unit (CPU). An alternative approach allows the sweeping consumer to stitch the mesh in parallel within the graphics processing unit (GPU) compute shader to improve performance, though this compromises performance, and the output remains a triangular mesh.

[0068] Through the road consumption terminal and the sweep consumption terminal, all the geometry dragged out along the centerline by the road conforming to the terrain, curb, guardrail, railing, pipeline, tunnel, riverbank, line, etc., is converged into pure data configuration. Application developers only need to declare a path plus a road entry or sweep entry to achieve this, without having to manually edit the height map or manually place a large number of boxes to fake sweep geometry.

[0069] In a preferred implementation, the runtime-growing ordered point buffer is a named, persistently resident ordered 3D point table within the entity component. Its configuration fields include a name (required, a globally unique name for the buffer), a point list (optional initial literal point list), and an upper limit (zero for unlimited, for circular buffers, older points are discarded if the limit is exceeded). The initial literal point list refers to the initial 3D point list directly written by the application developer in the configuration, serving as the initial content of the buffer. New points can be added to this initial point list during subsequent runtime operations. The runtime-growing ordered point buffer is accompanied by an append action, which uses a single operation field to unify two runtime writes (i.e., op:push / clear): when the operation field is the first value (push), a 3D point is pushed into the ordered point buffer; when the operation field is the second value (clear), the ordered point buffer is cleared. Unifying two runtime write operations with a single operation field means that the append action uses the same action type, but distinguishes between "push in a point" and "clear the entire table" write operations by different values ​​of the operation field. Application developers only need to configure one append action, and can control which write is executed by the value of the operation field, without having to configure different action types for the two operations separately. The runtime growable ordered point buffer can be used as a path reference source consumed by various path consumers, or it can be mounted as an optional rendering block and drawn as a continuous thin tube. Given the line thickness, color, optional self-illumination and transparency, the engine reconstructs a thin tube mesh every frame based on the current active points (if there are fewer than two active points, it will not be drawn).

[0070] In an alternative approach, the optional rendering block can also be equipped with a camera-facing strip section. For each pair of adjacent points of a polyline, the direction of the view is determined by the direction from the midpoint of the line segment to the camera position in the current frame. The cross product of the line segment direction and the view direction is used to obtain the unfolding direction. At both ends of the line segment, the width of the line is extended by half along the unfolding direction to form a quadrilateral that always faces the camera. These quadrilaterals are then pieced together to form a strip mesh that always faces the observer. This method requires querying the camera position every frame to determine the orientation of the strip section.

[0071] The runtime-growing ordered point buffer decouples the load (named buffer) from the consumption (distribution, rendering), allowing the same buffer to supply multiple consumers simultaneously. Through the runtime-growing ordered point buffer and its accompanying additional actions, runtime polylines such as player-drawn trajectories, walking trails, connecting corridors, projectile trails, and route previews can both load and display.

[0072] All of the above alternative solutions must obtain curve abstraction through a unified path resolver, use pure data description, and complete verification during loading (running). These three points are the essence of this invention and cannot be replaced.

[0073] In Example 1, an application developer defines a named static path called "Patrol," constructed from a series of more than ten points along a smooth curve and marked as closed. A guard entity attaches a follower consumer, references the path named "Patrol," configures a given speed and sets a loop mode, and specifies an event per lap. This guard entity then patrols indefinitely along this closed route, generating a lap event for game counting or triggering a shift change after each lap. Another application developer uses a distributed consumer, also referencing the path named "Patrol," placing a street lamp every few meters along the path and oriented it according to the tangent direction. Both the follower consumer and the distributed consumer reference the same path named "Patrol," obtain the same curve abstraction through the same unified path resolver, and have completely identical data such as sampling point positions and tangent directions.

[0074] In Example 2, the application developer defines a named static path called "Main Road," where the height of its points corresponds to the road surface elevation profile. The path itself carries a strip mesh and material. A road entry is declared on the terrain, referencing the path named "Main Road," and given a width and transition zone. During world construction, the surface is flattened along the "Main Road" within the specified width, and then smoothly returns to hills within the transition zone. The strip road sits on the flattened surface, forming a drivable gravel road situated in rugged mountains. All three consumer endpoints—follower, distribution, and road—reference the same path, obtain the same curve abstraction through the same unified path resolver, and each consumer endpoint obtains curve data in a completely consistent manner, without resolving different curves due to different consumer endpoints.

[0075] The two specific examples described above, totaling approximately one hundred configuration terms, can replace the spline sampling scripts, game-by-game patrol state machines, and pixel-by-pixel edited height maps that are almost inevitably written incorrectly in traditional solutions. Furthermore, the same path can be reused by multiple consumer terminals such as sampling value functions, follow-up functions, distribution functions, and roads. Because each consumer terminal references the same path name through the same unified path resolver, different curves will never be resolved due to different consumer terminals.

[0076] In summary, this invention, through a complete process of acquiring path references, determining the curve abstraction of the path based on the path references, and providing the curve abstraction to each path consumer, enables the sampling mathematics of paths and spline curves to be completed by the engine itself. Each path consumer references paths in a consistent manner, and all game function modules that rely on curves converge into pure data configurations that can be verified during loading. There are zero new instruction streams added during runtime. This solves the problems of path sampling relying on runtime scripts, inconsistent parsing among different consumers, the need for manual editing of road conforming to terrain, and the lack of a unified carrier for trajectory and sweep geometry during runtime in traditional engines. It has significant progress and practical value.

[0077] In the above embodiments, although the steps are numbered S1, S2, etc., they are only specific embodiments given by the present invention. Those skilled in the art can adjust the execution order of S1, S2, etc. according to the actual situation, and these situations are also within the protection scope of the present invention. It can be understood that in some embodiments, some or all of the above embodiments may be included.

[0078] Furthermore, the acquisition process of the data involved in this application follows the principles of legality, legitimacy, and necessity. Based on obtaining the explicit authorization and consent of the user, only the minimum necessary information required to achieve the purpose is collected, and data security protection obligations are fulfilled in accordance with the law.

[0079] This invention also provides a declarative path and spline curve parsing system, the specific technical solution of which is as follows: a path parsing module and a curve distribution module; The path parsing module is used to obtain path references and determine the curve abstraction of the path based on the path references. The curve abstraction is used at least to determine the position of the point along the curve arc length, to determine the tangent direction along the curve arc length, and to determine the total arc length of the curve. The curve distribution module is used to abstract curves and provide them to at least one path consumer, so that each path consumer can reference the path in a consistent way and complete its respective game function.

[0080] It should be noted that the beneficial effects of the declarative path and spline curve parsing system provided in the above embodiments are the same as those of the declarative path and spline curve parsing method described above, and will not be repeated here. Furthermore, the system provided in the above embodiments is only illustrated by the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the system can be divided into different functional modules according to the actual situation to complete all or part of the functions described above. In addition, the system and method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process is detailed in the method embodiments, and will not be repeated here.

[0081] like Figure 3 As shown, an embodiment of the present invention provides a computer device 300, which includes a processor 320 coupled to a memory 310. The memory 310 stores at least one computer program 330, which is loaded and executed by the processor 320 to enable the computer device 300 to implement any of the above-described methods. Specifically: The computer device 300 can vary considerably due to differences in configuration or performance. It may include one or more processors 320 (Central Processing Units, CPUs) and one or more memories 310. The one or more memories 310 store at least one computer program 330, which is loaded and executed by the one or more processors 320 to enable the computer device 300 to implement the declarative path and spline curve parsing method provided in the above embodiments. Of course, the computer device 300 may also have wired or wireless network interfaces, a keyboard, and input / output interfaces for input and output. The computer device 300 may also include other components for implementing device functions, which will not be elaborated upon here.

[0082] An embodiment of the present invention provides a computer-readable storage medium storing at least one computer program, which is loaded and executed by a processor to enable a computer to implement any of the above-described methods.

[0083] Alternatively, the computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CD-ROM), magnetic tape, a floppy disk, and an optical data storage device, etc.

[0084] In an exemplary embodiment, a computer program product or computer program is also provided, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform any of the declarative path and spline curve parsing methods described above.

[0085] It should be noted that the terms "first," "second," etc., used in the specification of this application are used to distinguish similar objects and do not imply a specific order or sequence. Where appropriate, the order of use for similar objects can be interchanged so that the embodiments of this application described herein can be implemented in an order other than that shown in the figures or description.

[0086] Those skilled in the art will recognize that this invention can be implemented as a system, method, or computer program product. Therefore, this disclosure can be specifically implemented in the following forms: it can be entirely hardware, entirely software (including firmware, resident software, microcode, etc.), or a combination of hardware and software, generally referred to herein as a "circuit," "module," or "system." Furthermore, in some embodiments, the invention can also be implemented as a computer program product contained in one or more computer-readable media, which includes computer-readable program code.

[0087] Any combination of one or more computer-readable media may be used. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in connection with an instruction execution system, apparatus, or device.

[0088] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A declarative path and spline curve analysis method, characterized in that, include: Obtain a path reference, and determine the curve abstraction of the path based on the path reference. The curve abstraction is at least used to determine the position of the point along the curve arc length, the tangent direction along the curve arc length, and the total arc length of the curve. The curves are abstracted and provided to at least one path consumer, so that each path consumer references the path in a consistent manner and completes its respective game function.

2. The declarative path and spline curve parsing method according to claim 1, characterized in that, The path reference sources include at least one of named static paths and runtime growable ordered point buffers; The named static path is constructed from a list of points according to curve types and identified by a path name; the runtime can grow an ordered point buffer, which is an ordered 3D point table named after the entity component, and points can be added one by one during runtime.

3. The declarative path and spline curve parsing method according to claim 1, characterized in that, The path consumer end includes a sampled value function consumer end; The consumer provides the curve as a pure data value function that can be read. The pure data value function includes at least: a function for determining the position of a point along the arc length of the curve, a function for determining the tangent direction along the arc length of the curve, and a function for determining the total arc length of the curve.

4. The declarative path and spline curve parsing method according to claim 1, characterized in that, The path consumer end includes follow-up consumer end and distributed consumer end; The following consumer terminal abstracts the position of the point from the curve to determine the advancing position, obtains the total arc length to determine whether the endpoint has been reached, and obtains the tangent direction to determine the orientation of the entity. The distributed consumer terminal obtains the position of the point from the curve abstraction to determine the placement position, obtains the side normal to determine the offset direction, obtains the tangent direction to determine the entity orientation, and places the entity along the preset interval of the total arc length; The side normal is determined by rotating the tangent provided by the curve abstraction within a preset plane.

5. The declarative path and spline curve parsing method according to claim 2, characterized in that, The path consumer end includes the connected consumer end; The connected consumer end renders a thin line between the entity and the target entity and resolders it frame by frame as either end moves. The connected consumer terminal is also used to obtain a connecting corridor with a limited number of turns on the grid chessboard, and write the inflection points of the connecting corridor into the runtime growable ordered point buffer.

6. The declarative path and spline curve analysis method according to claim 1, characterized in that, The path consumption end includes the road consumption end and the sweeping consumption end; The road consumer end obtains the location of the point from the curve to determine the height profile, obtains the total arc length to determine the flattening range, flattens the ground surface along the path and lays the road surface; The sweeping consumer end abstracts the position of the point from the curve to determine the placement position of the cross section, obtains the tangent direction and the side normal to determine the orientation of the cross section, and gradually places the selected cross section along the curve and stitches it into a mesh; The side normal is determined by rotating the tangent provided by the curve abstraction within a preset plane.

7. The declarative path and spline curve parsing method according to claim 1, characterized in that, The path and the path consumer are statically compiled closed sets, configured as pure data, and evaluated by reference at runtime, without generating any new instruction streams. Before determining the curve abstraction of the path based on the path reference, the method further includes: validating the validity of the path reference, the validation including at least: Has the path already been declared? Does the configuration parameter of the path consumer meet the preset configuration conditions? Does the way the path consumer references the path meet the preset access conditions? 8. A declarative path and spline curve parsing system, characterized in that, include: Path parsing module and curve distribution module; The path parsing module is used to obtain path references and determine the curve abstraction of the path based on the path references. The curve abstraction is used at least to determine the position of the point along the curve arc length, the tangent direction along the curve arc length, and the total arc length of the curve. The curve distribution module is used to abstract the curve and provide it to at least one path consumer, so that each path consumer can reference the path in a consistent manner and complete its respective game function.

9. A computer device, characterized in that, The computer device includes a processor coupled to a memory storing at least one computer program, which is loaded and executed by the processor to enable the computer device to implement a declarative path and spline curve parsing method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one computer program, which is loaded and executed by a processor to enable the computer to implement a declarative path and spline curve parsing method as described in any one of claims 1 to 7.

Images