Wireframe data generation method, electronic device, storage medium, and program product

Abstract

This application provides a method for generating wireframe data, an electronic device, a storage medium, and a program product, relating to the field of intelligent driving technology. The method involves acquiring scene definition data for an intelligent driving simulation scenario; generating a simulation scene description file based on the scene definition data; and driving a simulation platform to perform wireframe rendering based on the simulation scene description file to obtain the wireframe data of the intelligent driving simulation scenario. Using this application can improve the efficiency of wireframe data generation.

Description

Technical Field

[0001] This application relates to the field of intelligent driving technology, and in particular to a method for generating wireframe data, an electronic device, a storage medium, and a program product. Background Technology

[0002] With the rapid development of intelligent driving technology, generative world models, as a core technology for realizing intelligent driving scenario simulation and algorithm verification, have become a key research and development direction in the industry. Generative world models generate multi-view videos using text prompts and wireframe data as input. Among them, wireframe data can represent the geometric structure and contour constraints of targets such as roads, vehicles, and pedestrians, providing key spatial data in a simplified form. This can effectively improve the model's efficiency in understanding scene dynamics and is an important input condition supporting the stable operation of generative world models.

[0003] In related technologies, the generation of wireframe data is generally based on the transformation of real-world datasets. This approach is highly dependent on large-scale real datasets and suffers from drawbacks such as high data acquisition costs and difficulty in covering edge scenes, ultimately resulting in low efficiency in generating wireframe data. Summary of the Invention

[0004] The main objective of this application is to provide a method for generating wireframe data, an electronic device, a storage medium, and a program product, with the aim of improving the efficiency of wireframe data generation.

[0005] To achieve the above objectives, a first aspect of this application proposes a method for generating wireframe data, the method comprising: Obtain scenario definition data for intelligent driving simulation scenarios; A simulation scenario description file is generated based on the scenario definition data; The simulation platform is driven by the simulation scene description file to perform wireframe rendering, thereby obtaining the wireframe data of the intelligent driving simulation scene.

[0006] In some embodiments, generating a simulation scene description file based on the scene definition data includes: Based on the scenario definition data, a combination of scenario parameters matching the intelligent driving simulation scenario is extracted from a preset structured scenario parameter library; A simulation scenario description file is generated based on the combination of scenario parameters.

[0007] In some embodiments, the structured scene parameter library includes multi-dimensional scene parameters, and the step of extracting a combination of scene parameters matching the intelligent driving simulation scene from the preset structured scene parameter library based on the scene definition data includes: Parse the scene definition data to generate scene parameter sampling instructions; Based on the scene parameter sampling instructions, target scene parameters describing the intelligent driving simulation scene are extracted from the multi-dimensional scene parameters to obtain a combination of scene parameters that matches the intelligent driving simulation scene.

[0008] In some embodiments, the method further includes: If the initial combination of scenario parameters of the target scenario passes the constraint verification, the initial combination of scenario parameters is determined to be a combination of scenario parameters that matches the intelligent driving simulation scenario; the constraint verification includes at least one of physical rule verification, logical rule verification and distribution rule verification corresponding to the intelligent driving simulation scenario.

[0009] In some embodiments, the wireframe data includes a sequence of wireframe images, and the step of driving the simulation platform to perform wireframe rendering based on the simulation scene description file includes: Parse the simulation scenario description file to generate scenario simulation instructions; Based on the scene simulation instructions, the simulation platform is driven to render wireframe images in wireframe rendering mode, thereby obtaining the wireframe image sequence output by the simulation platform.

[0010] In some embodiments, the method further includes: Preprocessing is performed on the wireframe data; the preprocessing includes quality assessment of the wireframe data; The preprocessed wireframe data is input into the generative world model to generate the intelligent driving simulation scene.

[0011] In some embodiments, the quality assessment of the wireframe data includes: Based on a number of preset quantitative indicators, the scores of the wireframe data are calculated for each indicator. The number of quantitative indicators includes at least two of the following: geometric integrity indicator, trajectory continuity indicator, viewpoint consistency indicator, dynamic richness indicator, and noise interference rate indicator. The scores of the multiple quantitative indicators are weighted and summed based on their respective weight distributions to obtain the overall quality score of the wireframe data; the overall quality score of the preprocessed wireframe data is greater than or equal to the preset quality pass score.

[0012] To achieve the above objectives, a second aspect of this application proposes a wireframe data generation system, the system comprising: The scenario definition module is used to acquire scenario definition data of intelligent driving simulation scenarios; and to generate a simulation scenario description file based on the scenario definition data. The simulation platform module is used to drive the simulation platform to perform wireframe rendering based on the simulation scene description file, so as to obtain the wireframe data of the intelligent driving simulation scene.

[0013] To achieve the above objectives, a third aspect of this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the wireframe data generation method described in the first aspect.

[0014] To achieve the above objectives, a fourth aspect of the present application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the wireframe data generation method described in the first aspect.

[0015] To achieve the above objectives, a fifth aspect of the present application provides a computer program product, which includes a computer program that, when executed by a processor, implements the wireframe data generation method provided in the first aspect above.

[0016] The wireframe data generation method, system, electronic device, computer-readable storage medium, and computer program product proposed in this application obtain scene definition data of an intelligent driving simulation scene; generate a simulation scene description file based on the scene definition data; and drive a simulation platform to perform wireframe rendering based on the simulation scene description file to obtain the wireframe data of the intelligent driving simulation scene.

[0017] Compared to traditional methods that collect and process real-world data to generate wireframe data, this application's embodiment only requires generating a simulation scene description file based on the scene definition data of the intelligent driving simulation scene, and then driving the simulation platform to perform wireframe rendering based on this simulation scene description file to obtain the wireframe data of the intelligent driving simulation scene. This solves the problem of wireframe data generation's dependence on real-world data, thus eliminating the limitations of real-world data collection, conversion, and processing, and effectively improving the efficiency of wireframe data generation. Attached Figure Description

[0018] Figure 1 A flowchart illustrating the steps of the wireframe data generation method provided in some embodiments of this application; Figure 2 for Figure 1 A detailed flowchart of step S102; Figure 3 for Figure 1 A detailed flowchart of step S103; Figure 4A flowchart illustrating the steps of the wireframe data generation method provided in this application embodiment in other embodiments; Figure 5 A schematic diagram of the system structure involved in a complete embodiment of the wireframe data generation method provided for the application embodiments; Figure 6 A schematic diagram of the system workflow involved in a complete embodiment of the wireframe data generation method provided in this application; Figure 7 The wireframe data generation method provided in the embodiments of this application involves wireframe images in some embodiments; Figure 8 The wireframe data generation method provided in the embodiments of this application involves inference videos in some embodiments; Figure 9 This is a schematic diagram of the structure of the wireframe data generation system provided in the embodiments of this application; Figure 10 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0020] It should be noted that although functional modules are divided in the device / system schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device / system or the order in the flowchart. The terms "first," "second," etc., in the specification, claims, and the aforementioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0021] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0022] First, the technical terms involved in the embodiments of this application will be explained.

[0023] Intelligent driving simulation scenario: Intelligent driving simulation scenarios, also known as autonomous driving simulation test scenarios, refer to the dynamic interaction descriptions of autonomous vehicles and environmental elements (roads, traffic participants, weather, etc.) under specific times and tasks. They are the core basis for verifying the safety and robustness of the system. Scenario construction should not only cover typical driving situations but also include extreme and low-probability edge scenarios to comprehensively evaluate system performance. Scenario components typically include static elements (road structure, traffic signs, buildings, etc.), dynamic elements (vehicles, pedestrians, bicycles, etc.), and environmental elements (lighting, rain, snow, fog, etc.). Internationally, standardized formats such as OpenSCENARIO and OpenDRIVE are commonly used for description.

[0024] Generative world model: Generative world models are the "virtual pre-show brain" in the field of intelligent driving. They require lightweight, structured wireframe data (non-color wireframe videos) to learn / verify the spatial logic of traffic scenes (such as the positional relationships and movement trajectories of vehicles and pedestrians). Wireframe data retains only the outlines and key structures of objects, removing redundant information such as textures and lighting, making it suitable for rapid model computation.

[0025] OSC2.0: OSC2.0, short for OpenSCENARIO 2.0, is a standardized scenario description language in the field of intelligent driving. It can be used to describe dynamic driving scenarios, including road networks, traffic participant behavior, and environmental conditions, thereby defining the rules of traffic scenarios (such as "the main vehicle is traveling straight at 30 km / h" and "a pedestrian walks from the roadside into the lane").

[0026] Simulation platform: Simulation platforms in the field of intelligent driving can be called autonomous driving simulation testing platforms. They are digital virtual simulation infrastructures for the research, development, testing, and verification of the entire stack of autonomous driving technologies. By constructing high-fidelity virtual traffic scenarios and digital twin environments, they reproduce the physical rules of real roads, the behavior of traffic participants, sensor perception characteristics, and vehicle dynamics characteristics. This enables closed-loop testing, scenario traversal, and extreme condition verification of the entire chain of autonomous driving algorithms, including perception, decision-making, planning, and control. At the same time, they can output standardized scene data and multimodal image sequences to support the training, fine-tuning, and accuracy verification of large-scale intelligent driving models such as generative world models.

[0027] Vehicle cut-in: In the context of autonomous driving, "cut-in" refers to a situation where a vehicle in an adjacent lane changes lanes laterally within a short period of time, encroaching on the lane of the main vehicle and occupying its path. For example, "the main vehicle being cut-in" means that a vehicle in an adjacent lane quickly changes lanes and enters the lane of the main vehicle, cutting directly in front of it. After cutting in, this vehicle becomes the new vehicle in front of the main vehicle, hence the term "cut-in by the vehicle in front."

[0028] OpenDRIVE high-precision maps: OpenDRIVE high-precision maps are standardized descriptions of open lane-level static road traffic environments developed by the Automation and Measurement Systems Standards Association (ASAM, which belongs to the OpenX standards system along with OpenSCENARIO 2.0 / OSC 2.0). The standard file format is .xodr. With centimeter-level accuracy, OpenDRIVE high-precision maps standardize the geometric and semantic information of the entire static road traffic environment, including road topology, lane attributes, traffic facilities, and road surface physical features. It serves as the core static infrastructure for intelligent driving simulation testing and the development of autonomous driving control / perception algorithms. Together with OSC 2.0, it forms a standardized closed-loop system for the entire intelligent driving simulation scenario, combining a static environment stage with dynamic behavior scripts.

[0029] Next, the overall concept of the wireframe data generation method provided in the embodiments of this application will be briefly described.

[0030] The rapid development of intelligent driving technologies (such as intelligent assisted driving technology and autonomous driving technology) relies on high-performance perception and decision-making models. Among them, generative world models in the field of intelligent driving (such as the open-source COSMOS-Drive model) typically use wireframe constraints and text prompts as input for multi-view video generation. Wireframe constraints represent the geometric structure of the scene (such as the edges and contours of roads, vehicles, and pedestrians), providing simplified but crucial spatial information that helps the model efficiently understand scene dynamics.

[0031] In related technologies, wireframe data generation typically involves converting real-world datasets (such as the open nuScenes or Waymo datasets) into wireframe data. Specifically, raw data is first extracted from real-world data collected by vehicle sensors (such as LiDAR, cameras, etc.), and then processed (such as object detection, segmentation, etc.) to generate wireframe representations of the scene, which are then used for inference generation in generative world models.

[0032] However, since this approach relies on large-scale real-world datasets, while it can provide real-world diversity, it has significant limitations, such as high data collection costs (real data collection requires expensive sensors and vehicle platforms) and difficulty in covering scenarios (such as edge cases), data scarcity (data for certain dangerous or rare extreme weather, accidents, and other scenarios is difficult to obtain), and insufficient flexibility (modifying or expanding real data is difficult and it is hard to adapt to the specific testing needs of the intelligent driving field).

[0033] To address the aforementioned issues, this application proposes a method, system, electronic device, computer-readable storage medium, and computer program product for generating wireframe data, aiming to improve the efficiency of wireframe data generation.

[0034] This application embodiment obtains scene definition data of an intelligent driving simulation scene; generates a simulation scene description file based on the scene definition data; and drives the simulation platform to perform wireframe rendering based on the simulation scene description file to obtain the wireframe data of the intelligent driving simulation scene.

[0035] Compared to traditional methods that collect and process real-world data to generate wireframe data, this application's embodiment only requires generating a simulation scene description file based on the scene definition data of the intelligent driving simulation scene, and then driving the simulation platform to perform wireframe rendering based on this simulation scene description file to obtain the wireframe data of the intelligent driving simulation scene. This solves the problem of wireframe data generation's dependence on real-world data, thus eliminating the limitations of real-world data collection, conversion, and processing, and effectively improving the efficiency of wireframe data generation.

[0036] Furthermore, in the embodiments of this application, any scenario can be flexibly defined during the process of generating simulation scenario description files based on scenario definition data, and the overall quality of wireframe data is strictly ensured through the rendering of the simulation platform, thereby effectively covering edge cases and further improving the diversity and controllability of wireframe data generation.

[0037] Furthermore, since the embodiments of this application first generate a simulation scene description file based on scene definition data, and then drive the simulation platform to render and generate wireframe data based on the simulation scene description file, it is possible to generate corresponding wireframe data by defining extreme scenes, thereby improving the efficiency of generative world models in performing intelligent driving reasoning.

[0038] Next, the wireframe data generation method, system, electronic device, computer-readable storage medium, and computer program product provided in this application will be specifically described through the following embodiments, and firstly, the various detailed embodiments of the wireframe data generation method provided in this application will be described in detail.

[0039] It should be noted that in all specific embodiments of this application, when processing data related to user identity or characteristics, such as user information, user behavior data, user historical data, and user location information, user permission or consent is obtained first. Furthermore, the collection, use, and processing of this data comply with relevant laws, regulations, and standards. In addition, when embodiments of this application require access to sensitive personal information of users, separate permission or consent from the user is obtained through pop-ups or redirection to confirmation pages. Only after obtaining the user's separate permission or consent is the necessary user-related data required for the proper functioning of these embodiments acquired.

[0040] It should be noted that the wireframe data generation method provided in this application relates to the field of intelligent driving technology. The wireframe data generation method provided in this application can be applied to a terminal, a server, or software running on either a terminal or a server. In some embodiments, the terminal can be an in-vehicle terminal, a smartphone, tablet, laptop, desktop computer, or other electronic device associated with a vehicle and capable of communicating and interacting with the vehicle via a network. The server can be a backend server terminal device of the terminal, which can be configured as an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms. The software can be an application implementing the wireframe data generation method, a computer program, and a storage medium carrying the computer program. It should be understood that, based on different design needs of practical applications, the terminal, server, and software that apply the wireframe data generation method provided in this application embodiment may also be other forms not listed here, and the wireframe data generation method provided in this application embodiment does not specifically limit these.

[0041] Furthermore, this application can also be used in numerous general-purpose or special-purpose computer system environments or configurations. Examples include: vehicle terminals, personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics devices, personal computers (PCs), minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via communication networks. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0042] For ease of understanding and explanation, the following text will use the wireframe data generation method provided in the embodiments of this application applied to a terminal device as an example to describe the various specific embodiments of this application in detail. In some descriptions, the terminal device may be simply referred to as a terminal. The implementation of the wireframe data generation method provided in the embodiments of this application for any of the above-described subject matter can refer to the implementation process of the wireframe data generation method described below.

[0043] Please refer to Figure 1 , Figure 1 The flowchart illustrates the steps of the wireframe data generation method provided in some embodiments of this application. It should be understood that, although... Figure 1 The flowcharts illustrating subsequent steps show the execution order of some method steps. However, based on different design needs in practical applications, the wireframe data generation method provided in this application embodiment can, of course, employ a different execution order of method steps than shown in the figures. That is, Figure 1 The order of the method steps shown does not constitute a limitation on the execution logic order of the wireframe data generation method provided in the embodiments of this application. Any other order based on... Figure 1 Reasonable changes to the order of steps shown should be included within the protection scope of the wireframe data generation method provided in the embodiments of this application.

[0044] like Figure 1 As shown, in some embodiments, the wireframe data generation method provided in this application may include steps S101 to S103 as shown below.

[0045] Step S101: Obtain the scene definition data of the intelligent driving simulation scenario.

[0046] When generating wireframe data, the terminal device first obtains the scene definition data of the intelligent driving simulation scenario. For example, when conducting autonomous driving simulation testing, in order to generate an intelligent simulation scenario using a generative world model, the terminal device needs to generate wireframe data as input to the generative world model. In this case, the terminal device can first obtain the scene definition data of the intelligent simulation scenario.

[0047] In some embodiments, the scene definition data can be a generation strategy for the intelligent simulation scene, which may include: the number of targets, complexity level, and covered targets, etc. The terminal device can receive the intelligent simulation scene generation strategy specified by the user or the previous system (e.g., the intelligent simulation scene control and drive system) that generated the wireframe data, for example: Target number: Generate 1000 scenes; Complexity level: Generates scenarios at the "extreme" level; Coverage objective: Prioritize coverage of sparse cases such as "emergency cut-in on rainy nights".

[0048] In some embodiments, the scenario definition data can be a description of an intelligent simulation scenario, which includes a complete generation strategy. The terminal device can receive user-defined input descriptions of intelligent simulation scenarios, such as generating 1000 "extreme" level scenarios, prioritizing coverage of sparse cases like "emergency cut-in on a rainy night".

[0049] Step S102: Generate a simulation scenario description file based on the scenario definition data.

[0050] After obtaining the scene definition data, the terminal device further describes the dynamic elements of the intelligent driving simulation scene (such as vehicle trajectory, pedestrian behavior, etc.) based on the scene definition data, thereby generating a simulation scene description file for the intelligent driving simulation scene.

[0051] In some embodiments, the simulation scenario description file can be an OSC2.0 scenario file. The terminal device can use OSC2.0 syntax to write scenario definition data into an OSC2.0 scenario file, for example: a scenario where the main vehicle is cut-in by the vehicle in front.

[0052] In some embodiments, the terminal device can also use OpenSCENARIO 1.0 to compile the scene definition data into an OSC1.0 scene file conforming to the OpenSCENARIO 1.0 standard. In this case, the OSC1.0 scene file is the simulation scene description file for the intelligent driving simulation scene.

[0053] Step S103: Drive the simulation platform to perform wireframe rendering based on the simulation scene description file to obtain the wireframe data of the intelligent driving simulation scene.

[0054] After generating the simulation scene description file, the terminal device drives the simulation platform to perform wireframe rendering based on the simulation scene description file, so as to instantiate the scene elements described in the simulation scene description file through the simulation platform, thereby obtaining the wireframe data of the intelligent driving simulation scene output by the simulation platform.

[0055] In some embodiments, the terminal device can generate rendering driver instructions for the simulation platform based on the simulation scene description file, thereby driving the simulation platform to perform wireframe rendering operations to generate wireframe data.

[0056] In some embodiments, the simulation platform can be pre-configured to perform wireframe rendering. For example, before the simulation platform officially runs a case, rendering parameters can be set (such as disabling pixel shaders and only retaining vertex shaders for wireframe drawing) to ensure that only wireframes are output. In this way, the terminal device can directly determine the wireframe rendering operation to be performed by the simulation platform based on the simulation scene description file.

[0057] In some embodiments, the terminal device can also control the simulation platform to run wireframe rendering mode in real time according to the configured rendering parameters when driving the simulation platform based on the simulation scene description file. For example, while officially driving the simulation platform to perform wireframe rendering, the terminal device sends an instruction to the simulation platform to run wireframe rendering mode according to the configured rendering parameters. The simulation platform then responds to the instruction and switches to wireframe rendering mode in real time. In wireframe rendering mode, it responds to the rendering driving instructions generated based on the simulation scene description file and performs wireframe rendering operations.

[0058] In this embodiment, when generating wireframe data, the terminal device first obtains the scene definition data of the intelligent driving simulation scene. Then, it further describes the dynamic elements of the intelligent driving simulation scene based on the scene definition data, thereby generating a simulation scene description file of the intelligent driving simulation scene. Finally, it drives the simulation platform to perform wireframe rendering based on the simulation scene description file, so as to instantiate the scene elements described in the simulation scene description file through the simulation platform, thereby obtaining the wireframe data of the intelligent driving simulation scene output by the simulation platform.

[0059] Compared to traditional methods that collect and process real-world data to generate wireframe data, this application's embodiment only requires generating a simulation scene description file based on the scene definition data of the intelligent driving simulation scenario. Then, by driving the simulation platform to perform wireframe rendering based on this simulation scene description file, the wireframe data of the intelligent driving simulation scenario can be obtained. This solves the problem of wireframe data generation's dependence on real-world data, thus eliminating the limitations of real-world data collection, conversion, and processing, effectively improving the efficiency of wireframe data generation. Furthermore, since it no longer relies on collecting real-world data to generate wireframe data, the overall cost of intelligent driving simulation scenario testing can be further reduced.

[0060] Please refer to Figure 2 , Figure 2 for Figure 1 A detailed flowchart of step S102.

[0061] like Figure 2 As shown, in some embodiments, step S102 above: generating a simulation scene description file based on the scene definition data may include steps S201 and S202 as shown below.

[0062] Step S201: Based on the scenario definition data, extract the scenario parameter combination that matches the intelligent driving simulation scenario from the preset structured scenario parameter library.

[0063] It should be noted that the structured scene parameter library can store standardized scene parameters in an extensible JSON format, and each parameter item defines its legal value range, probability distribution (such as normal distribution, uniform distribution, piecewise discrete distribution, etc.) and semantic constraints (such as "the speed of pedestrians crossing in the rain is ≤1.2m / s").

[0064] When generating a simulation scenario description file for an intelligent driving simulation scenario based on scenario definition data, the terminal device can extract target scenario parameters describing the intelligent driving simulation scenario from various scenario parameters stored in the structured scenario parameter library according to the generation strategy represented by the scenario definition data, and form a combination of scenario parameters that matches the intelligent driving simulation scenario.

[0065] Step S202: Generate a simulation scene description file based on the combination of scene parameters.

[0066] After collecting the combination of scene parameters that matches the intelligent driving simulation scenario, the terminal device further edits the combination of scene parameters in machine language to generate a simulation scenario description file for the intelligent driving simulation scenario.

[0067] In some embodiments, the terminal device can use the OSC2.0 syntax to write the target scene parameters in the scene parameter combination to obtain an OSC2.0 scene file, which is the simulation scene description file of the intelligent driving simulation scene.

[0068] For example, terminal devices can pre-configure OSC2.0 scene templates, which are code frameworks conforming to the ASAMOpenSCENARIO2.0 standard and include placeholders. For instance: #Pseudocode template scenario:CutIn_Scenario parameters: ego_speed={{ego_speed}}, # Placeholder, to be replaced by the actual sampled value cutin_vehicle_speed={{cutin_speed}}, weather_condition={{weather}} ... Based on this, the terminal device fills the target scene parameters in the scene parameter combination into the preset OSC2.0 scene template, and thus obtains the OSC2.0 scene file of the intelligent driving simulation scene.

[0069] In some embodiments, the structured scene parameter library includes multi-dimensional scene parameters. For example, the scene parameters stored in the structured scene parameter library may include: Road structure parameters, such as road curvature, number of lanes, gradient, intersection type (T-shaped, cross, roundabout), curb height, etc. (based on OpenDRIVE high-precision map topology). Traffic participant behavior parameters, such as vehicle speed range, acceleration distribution, lane change probability, following distance, pedestrian crossing timing and speed, and non-motorized vehicle trajectory disturbance patterns; Environmental condition parameters, such as light intensity (0–100%), weather type (sunny / rainy / foggy / snowy), visibility, and road surface friction coefficient; Interactive event parameters, such as emergency braking trigger threshold, cut-in / cut-out distance, and multi-vehicle cooperative conflict mode (such as "three-vehicle sandwich" and "ghost peek").

[0070] In some embodiments, step S201 above: extracting a combination of scene parameters matching the intelligent driving simulation scenario from a preset structured scene parameter library based on the scene definition data, may include the following steps: Parse the scene definition data to generate scene parameter sampling instructions; Based on the scene parameter sampling instructions, target scene parameters describing the intelligent driving simulation scene are extracted from the multi-dimensional scene parameters to obtain a combination of scene parameters that matches the intelligent driving simulation scene.

[0071] When the terminal device extracts scene parameters from the structured scene parameter library, it first parses the scene definition data of the intelligent driving simulation scene to decompose the generation strategy represented by the scene definition data into scene parameter sampling instructions. Then, based on the scene parameter sampling instructions, it extracts the target scene parameters used to describe the intelligent driving simulation scene from the multi-dimensional scene parameters stored in the structured scene parameter library, thereby obtaining a combination of scene parameters that matches the intelligent driving simulation scene.

[0072] In some embodiments, the terminal device may further design a multi-level, constrained random combination engine, in addition to introducing a structured scene parameter library to generate simulation scene description files. The random combination engine intelligently samples the huge parameter space of the structured scene parameter library according to explicit rules and algorithms, thereby avoiding invalid or contradictory scene parameter combinations and ensuring the physical authenticity and logical consistency of the final generated intelligent driving simulation scene.

[0073] For example, when the terminal device obtains a generation strategy specified by the user or the upper-level system as the scene definition data for the intelligent driving simulation scene, it uses this generation strategy as input to the scene generation controller in the random combination engine. The scene generation controller then decomposes the generation strategy into specific scene parameter sampling instructions and schedules subsequent processes. Specifically, the scene parameter sampling instructions are sent to the parameter sampler in the random combination engine. This parameter sampler further extracts target scene parameters from the multi-dimensional scene parameters in the structured scene parameter library according to the controller instructions (scene parameter sampling instructions). Since these target scene parameters are extracted based on the scene parameter sampling instructions obtained from the decomposed generation strategy, they can describe the scene elements of the intelligent driving simulation scene. The combination of these target scene parameters is the scene parameter combination that matches the intelligent driving simulation scene. Then, the scene assembler in the random combination engine can fill the target scene parameters from the scene parameter combination into a preset OSC2.0 scene template, thereby obtaining the OSC2.0 scene file of the intelligent driving simulation scene.

[0074] It should be noted that the parameter sampler extracts target scene parameters according to controller instructions, but the sampling is not completely random. The parameter sampler can adopt a weighted random sampling strategy to set a non-uniform probability distribution for certain key parameters (such as "weather") to ensure that edge cases (such as "heavy snow") can be generated in an appropriate amount, thereby avoiding data skew; and / or, the parameter sampler can also adopt a rule-based sampling strategy, first determining a "core event" (such as "pedestrian crossing"), then sampling parameters that are strongly correlated with it (such as "pedestrian speed" and "crossing position"), and then sampling parameters that are weakly correlated (such as "ambient lighting").

[0075] In some embodiments, the method for generating wireframe data provided in this application further includes the following steps: If the initial combination of scenario parameters of the target scenario passes the constraint verification, the initial combination of scenario parameters is determined to be a combination of scenario parameters that matches the intelligent driving simulation scenario; the constraint verification includes at least one of physical rule verification, logical rule verification and distribution rule verification corresponding to the intelligent driving simulation scenario.

[0076] It should be noted that physics rule validation checks whether parameter combinations conform to physical laws. For example, if the road surface friction coefficient is less than 0.3 (slippery), then the maximum lateral acceleration threshold for vehicles must be reduced accordingly. Thus, if the sampled "cornering speed" might cause lateral acceleration to exceed the threshold, the speed or friction coefficient will be adjusted. Furthermore, logic rule validation checks the semantic rationality of the scene description. For example, if the weather is heavy snow, then visibility is good; if a conflict occurs, it will be overridden or resampled according to rule priority. Another example is: if the event is highway cut-in, then the vehicle speed is greater than 60 km / h, and the target lane must exist. Moreover, distribution rule validation checks whether parameter combinations contribute to achieving the expected scene distribution based on the generation strategy. For example, if too many "nighttime" scenes have been generated, the sampling weight of "time = nighttime" will be appropriately reduced.

[0077] After extracting target scene parameters from multi-dimensional scene parameters, the terminal device can further perform constraint verification on the initial scene parameter combinations of these target scene parameters. If the initial scene parameter combination passes the constraint verification, it is then determined to be a scene parameter combination that matches the intelligent driving simulation scene. This involves at least one of the following: physical rule verification (checking whether the parameter combination conforms to physical laws), logical rule verification (checking the semantic rationality of the scene description), and distribution rule verification corresponding to the intelligent driving simulation scene (checking whether the parameter combination helps achieve the expected scene distribution based on the generation strategy).

[0078] For example, the terminal device can use the constraint checker in the random combination engine to perform constraint verification on the parameter combination (initial scene parameter combination) output by the parameter sampler. That is, the constraint checker performs physical rule verification, logical rule verification, and distribution rule verification on the parameter combination based on the built-in rule knowledge base, and then outputs a self-consistent parameter combination that passes all constraint checks. This parameter combination can then be used as the final scene parameter combination that matches the intelligent driving simulation scenario.

[0079] In this embodiment, after the terminal device extracts the target scene parameters from the multi-dimensional scene parameters, it further performs constraint verification on the initial scene parameter combination of the target scene parameters. In this way, the initial scene parameter combination that passes the constraint verification is determined as the final scene parameter combination that matches the intelligent driving simulation scene, thus ensuring the legality of the scene parameter combination.

[0080] In some embodiments, the wireframe data includes a sequence of wireframe images. When the terminal device drives the simulation platform to perform wireframe rendering based on the simulation scene description file, the simulation platform can render each frame of wireframe image in real time according to the scene description, thereby generating a sequence of wireframe images.

[0081] Please refer to Figure 3 , Figure 3 for Figure 1 A detailed flowchart of step S103.

[0082] like Figure 3 As shown, in some embodiments, the step of "driving the simulation platform to perform wireframe rendering based on the simulation scene description file" in step S103 above may include steps S301 and S302 as shown below.

[0083] Step S301: Parse the simulation scene description file to generate scene simulation instructions.

[0084] Step S302: Based on the scene simulation command, drive the simulation platform to render wireframe images in wireframe rendering mode, and obtain the wireframe image sequence output by the simulation platform.

[0085] When the terminal device drives the simulation platform to perform wireframe rendering and generate wireframe data based on the simulation scene description file, it can parse the simulation scene description file to generate scene simulation instructions that the simulation platform can understand. Then, based on the scene simulation instructions, it determines the wireframe rendering mode configured by the simulation platform. In the wireframe rendering mode, the simulation platform renders each frame of wireframe image in real time according to the scene description and outputs it, thereby obtaining the wireframe image sequence output by the simulation platform.

[0086] In some embodiments, the terminal device can parse the OSC2.0 scene file and the opendrive high-precision map to generate scene simulation instructions, thereby driving the simulation platform to run dynamic cases to render wireframe images in wireframe rendering mode and obtain a sequence of wireframe images.

[0087] In some embodiments, the terminal device can be equipped with an OSC2.0 parser on the simulation platform, thereby parsing the OSC2.0 scene file to generate scene simulation instructions that drive the simulation platform. For example, the simulation platform can be the geely simulation platform (an intelligent driving simulation platform based on Unreal Engine (UE)). When the simulation platform is configured in wireframe rendering mode, it only draws geometric wireframes of the high-precision map and the dynamic elements described in the simulation scene description file, ignoring textures and lighting, while receiving the drive of the OSC2.0 parser to render the wireframe image sequence in real time.

[0088] In some embodiments, the terminal device can also drive the simulation platform to generate wireframe videos of large-scale traffic flows through a Simulation of Urban Mobility (SUMO) system (such as the open-source sumo traffic flow software). That is, it generates a simulation scenario description file for the intelligent driving simulation scenario based on the sumo traffic flow software (based on SUMO traffic flow export), and then generates scenario simulation instructions to drive the simulation platform to run dynamic cases.

[0089] In this embodiment, the simulation scene description file is parsed by the terminal device to generate scene simulation instructions, which then drive the simulation platform to render a sequence of wireframe images in wireframe rendering mode. In particular, by parsing the OSC2.0 scene file to drive the simulation platform, wireframe data can be generated as input for the world model in intelligent driving simulation scene testing without collecting real-world data. This effectively solves the problem of real data dependence in traditional wireframe data generation schemes and reduces costs.

[0090] Please refer to Figure 4 , Figure 4 The flowchart of the method for generating wireframe data provided in the embodiments of this application is shown in some other embodiments.

[0091] like Figure 4 As shown, in some embodiments, the wireframe data generation method provided in this application may further include steps S401 and S402 as shown below.

[0092] Step S401: Perform preprocessing on the wireframe data; the preprocessing includes quality assessment of the wireframe data.

[0093] After receiving the wireframe data output by the simulation platform, the terminal device can further perform preprocessing on the wireframe data to match the input requirements of the generative world model. This includes performing a quality assessment on the wireframe data to filter out wireframe data that meets the quality requirements.

[0094] In some embodiments, during the preprocessing of wireframe data, the terminal device may first perform a quality assessment on the wireframe data, and then, if the wireframe data passes the quality assessment, further perform operations such as format conversion (e.g., jpg->mp4) and frame rate adjustment on the wireframe data, thereby obtaining preprocessed wireframe data that matches the input requirements of the generative world model.

[0095] In some embodiments, the terminal device may also perform a quality assessment of the wireframe data in parallel while performing operations such as format conversion and frame rate adjustment on the wireframe data during the preprocessing process, thereby obtaining the preprocessed wireframe data.

[0096] Step S402: Input the preprocessed wireframe data into the generative world model to generate the intelligent driving simulation scene.

[0097] After receiving the preprocessed wireframe data, the terminal device can further input the wireframe data into the generative world model, since the wireframe data has passed the quality assessment and matches the input requirements of the generative world model. The model can then use the wireframe data and text prompts to infer and generate the final intelligent driving simulation scenario.

[0098] In some embodiments, quality assessment of the wireframe data may include the following steps: Based on a number of preset quantitative indicators, the scores of the wireframe data are calculated for each indicator. The number of quantitative indicators includes at least two of the following: geometric integrity indicator, trajectory continuity indicator, viewpoint consistency indicator, dynamic richness indicator, and noise interference rate indicator. The scores of the multiple quantitative indicators are weighted and summed based on their respective weight distributions to obtain the overall quality score of the wireframe data; the overall quality score of the preprocessed wireframe data is greater than or equal to the preset quality pass score.

[0099] It should be noted that among the above quantitative indicators, the geometric integrity indicator is used to calculate the geometric integrity score (GIS) of wireframe data (e.g., based on OpenCV contour detection, the ratio of the number of closed contours of valid wireframes in each frame to the expected number is used to obtain the GIS), thus preventing target loss or breakage due to rendering errors; the trajectory continuity indicator is used to calculate the trajectory continuity score (TCS) of wireframe data (e.g., calculating the variance of the center point displacement of the same target in consecutive frames to determine whether there are "jumps" or "disappearance-reappearance" anomalies), thus avoiding the model misjudging non-physical motion; the viewpoint consistency indicator is used to calculate the viewpoint consistency of wireframe data. The scoring VCS (e.g., performing 3D reprojection consistency verification on multi-view wireframe sequences (front view, side view, top view) and calculating the root mean square of the projection error) ensures that the multi-view inputs are logically consistent in space; the dynamic richness index is used to calculate the dynamic richness score DFS of the wireframe data (e.g., statistically analyzing the entropy value of the change in the number of moving targets in the scene per unit time to measure the dynamic complexity of the scene), which can filter out invalid samples such as "static empty scenes"; the noise interference rate index is used to calculate the noise interference rate NIR of the wireframe data (e.g., detecting the proportion of non-target wireframes (such as rendering artifacts) to the total number of wireframes), which can eliminate interference structures introduced by simulation engine errors.

[0100] When evaluating the quality of wireframe data, the terminal device first calculates the scores for each of the aforementioned quantitative indicators. Then, based on the pre-set weight distribution of each quantitative indicator, it performs a weighted sum of the calculated scores to obtain the overall quality score of the wireframe data. For example, the weights of the geometric integrity, trajectory continuity, viewpoint consistency, dynamic richness, and noise interference rate indicators are w1=0.3, w2=0.25, w3=0.2, w4=0.15, and w5=0.1, respectively. When the multi-indicator scores of the wireframe data consist of the scores of all five quantitative indicators, the terminal device uses a weighted comprehensive scoring method to calculate the final overall quality score of the wireframe data, Qtotal=w1. GIS+w2 (1 TCSnorm)+w3 (1 VCSnorm)+w4 DFS+w5 (1 NIR).

[0101] Based on this, if the overall quality score of the wireframe data is greater than or equal to the preset quality pass score (e.g., the quality pass score is the threshold Qthreshold=0.75), the terminal device determines that the wireframe data passes the quality assessment and can further perform standardized processes in preprocessing (such as format conversion, frame rate alignment, and normalized size) to finally obtain the preprocessed wireframe data. Conversely, if the overall quality score of the wireframe data is less than the preset quality pass score, the terminal device determines that the wireframe data fails the quality assessment and directly removes the wireframe data.

[0102] For example, suppose the terminal device generates a 2-second (60-frame) three-view wireframe video sequence through a simulation platform, which describes a simple scene: Front view: A three-lane road with three vehicles in this frame: your own car (EgoCar), a sedan in the same lane ahead (Car1), and a truck in the opposite lane (Car2). Top-down view: Displays the position and bounding boxes of all vehicles; Side view: Displays the vehicle's height and longitudinal distance.

[0103] At this point, when the terminal device performs a quality assessment on the wireframe video sequence, it first calculates several quantitative indicators, that is, the following raw data of the wireframe video sequence is obtained automatically through program analysis: 1. Geometric Integrity Score (GIS) = (Average number of valid closed contours per frame) / (Expected number of contours).

[0104] Raw data: Expected number of contours: 3 vehicles per frame = 3 main closed contours; Actual detection: Due to a rendering error, Car1's outline was not closed (it was broken) from frame 30 to frame 35 (6 frames in total). Out of 60 frames, 54 frames detected 3 closed outlines, and 6 frames detected only 2. Average number of valid outlines per frame = (54*3+6*2) / 60 = 174 / 60 = 3.9; GIS score: GIS = 2.9 / 3 = 0.96.

[0105] Judgment: 0.967 > 0.85 (GIS qualification threshold), this item passes.

[0106] 2. Trajectory Continuity Score (TCS) = Variance of the center point displacement of the same target in consecutive frames (unit: pixel²).

[0107] Raw data: Taking Car1 as an example, we tracked its center point coordinates for 100 consecutive frames in the front-view video (assuming a frame rate of 30fps). Under normal circumstances, the displacement should be smooth. Due to simulation jitter, Car1 suddenly experienced an abnormal and huge jump at the center point of frame 45; Calculate the variance of the displacement of the Car1 center point in the entire sequence. This outlier greatly increases the variance value. Assume the calculation result is TCS = 18.5 pixels².

[0108] Judgment: 18.5 > 15 (TCS pass threshold), this item fails, which indicates that there is a non-physical "jumping" phenomenon in the video.

[0109] 3. Viewpoint Consistency Score (VCS) = Root Mean Square of Multi-View 3D Reprojection Error (RMSE, unit: pixel).

[0110] Raw data: The system uses the wireframe information from the front, side, and top views to calculate the position of each target (such as Car1) in 3D space. Then, it projects this 3D position back to another 2D view and compares it with the original 2D wireframe position to calculate the error. Assuming a slight error in the top view, the average error in the reprojected front view is calculated to be VCS = 9.2 pixels.

[0111] Judgment: 9.2 > 8.0 (VCS pass threshold), this item fails. This indicates that the data from the three perspectives are not completely self-consistent in space, which will interfere with the correct inference of the model.

[0112] 4. Dynamic richness score DFS = Entropy value of change in the number of moving objects (unit: bit / frame).

[0113] Raw data: Count the number of moving targets in each frame; In this scenario, the three cars are moving at a constant speed, with no new cars appearing or disappearing. The number of moving targets remains constant at three. "Change entropy" measures uncertainty, and no change at all means that the entropy value is extremely low. Assuming the calculation result is DFS = 0.8 bits / frame.

[0114] Judgment: 0.8 < 2.0 (DFS pass threshold), this item fails, indicating that the scene is too static and simple, lacks effective dynamic information, and belongs to "invalid sample".

[0115] 5. Noise Interference Rate (NIR) = (Number of non-target wireframes) / (Number of bus frames).

[0116] Original data: During the rendering process, due to rendering artifacts and other reasons, some flickering wireframes were randomly generated at the edges of the image; Throughout the sequence, a total of 1200 wireframe outlines of "real targets" were detected, while 85 "noise" wireframes caused by rendering defects were also detected. NIR=85 / (1200+85)≈85 / 1285≈0.066, or 6.6%.

[0117] Judgment: 6.6% > 5% (pass threshold), this item fails, indicating that the video contains too much interference noise.

[0118] The terminal device then calculates the overall quality score Q_total for the wireframe video sequence.

[0119] At this point, the terminal device needs to normalize and invert the three indicators—TCS, VCS, and NIR—where smaller values ​​are better, to align them semantically with the two indicators—GIS and DFS—where larger values ​​are better (i.e., larger values ​​represent better quality). The terminal device can use the following extreme values ​​for normalization: TCS_max=30(pixel²) / / Considering variance exceeding 30 to be completely unacceptable; VCS_max=15(pixel) / / Consider an error exceeding 15 to be completely unacceptable; NIR_max=10% / / This means that a noise rate exceeding 10% is considered completely unacceptable.

[0120] Normalized calculation: 1.TCS_norm=TCS / TCS_max=18.5 / 30≈0.617, (1-TCS_norm)=1-0.617=0.383; 2.VCS_norm=VCS / VCS_max=9.2 / 15≈0.613, (1-VCS_norm)=1-0.613=0.387; 3.NIR_norm=NIR / NIR_max=6.6% / 10%=0.66, (1-NIR_norm)=1-0.66=0.34.

[0121] Then, assuming the weight allocation is as follows (summing up to 1): w1 (GIS weight) = 0.25, w2 (TCS weight) = 0.25, w3 (VCS weight) = 0.20, w4 (DFS weight) = 0.20, w5 (NIR weight) = 0.10. Substitute these weights into the following formula for calculation: Qtotal=w1 GIS+w2 (1 TCSnorm)+w3 (1 VCSnorm)+w4 DFS+w5 (1 NIR); Therefore, the final overall quality score of the wireframe video sequence can be obtained as Qtotal = (0.25 * 0.975) + (0.25 * 0.383) + (0.20 * 0.387) + (0.20 * 0.8) + (0.10 * 0.34) = 0.611. Thus, given a pre-set acceptable quality score of 0.70, the terminal device determines the wireframe video sequence to be unacceptable and filters it.

[0122] 4) COSMOS-Drive model module: Receives processed wireframe video and text prompts, performs inference tasks (multi-view video generation), and the model output can be used for training autonomous driving perception algorithms.

[0123] In some embodiments, after calculating the index score corresponding to each quantitative indicator of the wireframe data, the terminal device can also compare the index score individually with the corresponding pass threshold to determine whether the wireframe data meets the quality requirements for that quantitative indicator. For example, after calculating the geometric integrity score (GIS) of the wireframe data, the terminal device compares it with the pass threshold of GIS (e.g., 0.85). If the geometric integrity score (GIS) of the wireframe data is ≥ 0.85, the terminal device determines that the geometric integrity index of the wireframe data meets the quality requirements. As another example, after calculating the trajectory continuity score (TCS) of the wireframe data, the terminal device compares it with the pass threshold of TCS (e.g., 15 pixels²). If the trajectory continuity score (TCS) of the wireframe data is ≤ 15 pixels², the terminal device determines that the trajectory continuity index of the wireframe data meets the quality requirements. As yet another example, after calculating the viewpoint consistency score (VCS) of the wireframe data, the terminal device compares it with the pass threshold of VCS (e.g., 8.0 pixels). If the Viewing Consistency Score (VCS) of the wireframe data is ≤ 8.0 pixels, the terminal device determines that the viewing consistency index of the wireframe data meets the quality requirements. Similarly, after calculating the Dynamic Richness Score (DFS) of the wireframe data, the terminal device compares it with the acceptable threshold for DFS (e.g., 2.0 bits / frame). If the DFS score is ≥ 2.0 bits / frame, the terminal device determines that the dynamic richness index of the wireframe data meets the quality requirements. Likewise, after calculating the Noise Interference Rate (NIR) of the wireframe data, the terminal device compares it with the acceptable threshold for NIR (e.g., 5%). If the NIR score is ≤ 5%, the terminal device determines that the noise interference rate of the wireframe data meets the quality requirements.

[0124] In this embodiment, the wireframe data is preprocessed by the terminal device to perform a quality assessment, thereby filtering out wireframe data that fails the quality assessment. This ensures that the wireframe data used as input to the generative world model after preprocessing has high semantic consistency, geometric integrity, and reasoning validity, thus ensuring the model's reasoning efficiency.

[0125] In some embodiments, after generating a simulation scenario description file for an intelligent driving simulation scenario, the terminal device can first perform scenario validity verification on the simulation scenario description file. For example, it can use a simulation platform to quickly instantiate and simulate the simulation scenario description file (e.g., the first 10 seconds of the simulation), thereby utilizing the quality assessment mechanism in the wireframe video processing module of the simulation platform to perform preliminary verification of the instantiated data. In this way, it can be ensured that the simulation scenario description file can not only be parsed, but also generate stable and reasonable wireframe data output.

[0126] Next, a complete embodiment of the wireframe data generation method provided in this application will be presented.

[0127] Please refer to Figure 5 , Figure 5 A schematic diagram of the system structure involved in a complete embodiment of the wireframe data generation method provided for the application embodiments.

[0128] like Figure 5As shown, when the terminal device uses the wireframe data generation method provided in this application embodiment to render and generate wireframe videos using OSC2.0 and a simulation platform, and inputs them into the generative world model (COSMOS-Drive) model, it can parse the OSC2.0 scene file (describing dynamic elements such as vehicle trajectories and pedestrian behaviors) and the opendrive high-precision map through the OSC2.0 scene definition module, thereby driving the simulation platform to run dynamic cases. Here, the simulation platform can be the geely simulation platform module, configured in wireframe rendering mode, drawing only geometric wireframes for the high-precision map and dynamic elements, ignoring textures and lighting, while receiving the drive from the OSC2.0 parser to render wireframe image sequences in real time. Furthermore, the terminal device can also preprocess the wireframe images output by the simulation platform through the wireframe video processing module, such as format conversion (jpg->mp4) and frame rate adjustment, to match the input requirements of the COSMOS-Drive model. To ensure that the wireframe video sequences input to the COSMOS-Drive model possess high semantic consistency, geometric integrity, and inference validity, a wireframe video quality assessment and filtering system can be embedded in the preprocessing module. This system automatically scores and filters each generated wireframe video sequence based on the aforementioned five quantitative indicators. For example, after each wireframe video sequence is scored using the five indicators, a weighted comprehensive scoring method is used to calculate the final quality score: Qtotal=w1 GIS+w2 (1 TCSnorm)+w3 (1 VCSnorm)+w4 DFS+w5 (1 The video sequences are processed using a multi-view video frame (NIR) model. The weights are assigned as follows: w1=0.3, w2=0.25, w3=0.2, w4=0.15, w5=0.1 (optimal based on actual testing). Samples with a total score below the threshold Qthreshold=0.75 are automatically removed. The selected video sequences undergo a standardization process (format conversion, frame rate alignment, and size normalization) for weighted use during subsequent model training. The COSMOS-Drive model module receives the processed wireframe video and text prompts, performs inference tasks (multi-view video generation), and the model output can be used for training autonomous driving perception algorithms.

[0129] Please refer to Figure 6 , Figure 6 A schematic diagram of the system workflow involved in a complete embodiment of the wireframe data generation method provided in this application.

[0130] like Figure 6 As shown, in some embodiments, the terminal device is based on Figure 5 The system shown, when using OSC2.0 and a simulation platform to render and generate wireframe videos and input them into the COSMOS-Drive model, first draws a high-precision map of OpenDrive for reference in the OSC2.0 scene file. Then, it enters the scene definition stage, using OSC2.0 syntax to write scene files, such as a scene where the main vehicle is cut-in by the vehicle in front. The simulation platform is then configured for rendering; that is, before running the case, rendering parameters are set to ensure only wireframes are output, such as disabling pixel shaders and retaining only vertex shaders for wireframe drawing. Next, the OSC2.0 parsing driver module (parser) parses the OSC2.0 scene file and drives the simulation platform, such as randomly calling vehicles and pedestrians from the resource library and executing cases according to the generalized trajectory of the scene file (this step ensures that scene elements (such as vehicle models and road meshes) are correctly instantiated). Then, the wireframe video generation step is performed: the simulation platform renders each frame in real-time according to the scene description, generating a sequence of wireframe images, such as... Figure 7 As shown, the image only displays geometric edges, such as vehicle outlines and lane lines. Preprocessing is then performed, adjusting the rendered frame sequence to match the input frame rate of the COSMOS-drive model and converting the format (jpg->mp4). Finally, the model inference stage begins, inputting the preprocessed wireframe video into the COSMOS-Drive model, and the output is as follows. Figure 8 The reasoning video shown.

[0131] Please refer to Figure 9 This application also provides a wireframe data generation system, which can implement the above-described wireframe data generation method.

[0132] like Figure 9 As shown, the wireframe data generation system provided in this application embodiment may include: The scenario definition module is used to acquire scenario definition data of intelligent driving simulation scenarios; and to generate a simulation scenario description file based on the scenario definition data. The simulation platform module is used to drive the simulation platform to perform wireframe rendering based on the simulation scene description file, so as to obtain the wireframe data of the intelligent driving simulation scene.

[0133] In some embodiments, the scenario definition module is further configured to extract a combination of scenario parameters that matches the intelligent driving simulation scenario from a preset structured scenario parameter library based on the scenario definition data; and to generate a simulation scenario description file based on the combination of scenario parameters.

[0134] In some embodiments, the structured scene parameter library includes multi-dimensional scene parameters, and the scene definition module is further configured to parse the scene definition data to generate scene parameter sampling instructions; and, based on the scene parameter sampling instructions, extract target scene parameters describing the intelligent driving simulation scene from the multi-dimensional scene parameters to obtain a combination of scene parameters matching the intelligent driving simulation scene.

[0135] In some embodiments, the scenario definition module is further configured to determine, if the initial scenario parameter combination of the target scenario parameters passes the constraint verification, that the initial scenario parameter combination is a scenario parameter combination that matches the intelligent driving simulation scenario; the constraint verification includes at least one of physical rule verification, logical rule verification, and distribution rule verification corresponding to the intelligent driving simulation scenario.

[0136] In some embodiments, the wireframe data includes a sequence of wireframe images. The simulation platform module is further configured to analyze the simulation scene description file to generate scene simulation instructions; and to drive the simulation platform to render wireframe images in wireframe rendering mode based on the scene simulation instructions, thereby obtaining the sequence of wireframe images output by the simulation platform.

[0137] In some embodiments, the wireframe data generation system provided in this application further includes: A preprocessing module is used to perform preprocessing on the wireframe data; the preprocessing includes quality assessment of the wireframe data; and inputting the preprocessed wireframe data into a generative world model to generate the intelligent driving simulation scene.

[0138] In some embodiments, the preprocessing module is further configured to calculate multiple index scores of the wireframe data based on preset multiple quantitative indicators; the multiple quantitative indicators include at least two of geometric integrity indicators, trajectory continuity indicators, viewpoint consistency indicators, dynamic richness indicators, and noise interference rate indicators; and to perform a weighted summation of the multiple index scores based on the weight distribution of each of the multiple quantitative indicators to obtain a comprehensive quality score of the wireframe data; the comprehensive quality score of the preprocessed wireframe data is greater than or equal to a preset quality pass score.

[0139] It should be noted that the specific implementation of the wireframe data generation system provided in this application is basically the same as the specific implementation of the wireframe data generation method described above, and will not be repeated here.

[0140] Please see Figure 10 This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described method for generating wireframe data.

[0141] In some embodiments, the electronic device may be any smart terminal such as an in-vehicle terminal, an in-vehicle hardware platform (e.g., an in-vehicle computer), a tablet computer, a smartphone, or a wearable device; or, the electronic device may be a vehicle including a memory and a processor.

[0142] like Figure 10 As shown, the electronic device provided in this application embodiment may include: The processor 1001 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application. The memory 1002 can be implemented as a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 1002 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 1002 and is called and executed by the processor 1001 using the wireframe data generation method of the embodiments of this application. Input / output interface 1003 is used to implement information input and output; The communication interface 1004 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). Bus 1005 transmits information between various components of the device (e.g., processor 1001, memory 1002, input / output interface 1003, and communication interface 1004); The processor 1001, memory 1002, input / output interface 1003 and communication interface 1004 are connected to each other within the device via bus 1005.

[0143] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method for generating wireframe data.

[0144] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0145] This application also provides a computer program product, including a computer program. The steps implemented by the computer program when executed by a processor are basically the same as those in the specific embodiments of the wireframe data generation method described above, and will not be repeated here.

[0146] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of this application, and do not constitute a limitation on the technical solutions provided in this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided in this application are also applicable to similar technical problems.

[0147] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0148] The system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0149] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0150] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0151] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding factor is divided by the following factor, or that the related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0152] In the embodiments provided in this application, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between systems or units may be electrical, mechanical, or other forms.

[0153] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0154] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0155] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0156] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A method for generating wireframe data, characterized in that, The method includes: Obtain scenario definition data for intelligent driving simulation scenarios; A simulation scenario description file is generated based on the scenario definition data; The simulation platform is driven by the simulation scene description file to perform wireframe rendering, thereby obtaining the wireframe data of the intelligent driving simulation scene.

2. The method according to claim 1, characterized in that, The process of generating a simulation scene description file based on the scene definition data includes: Based on the scenario definition data, a combination of scenario parameters matching the intelligent driving simulation scenario is extracted from a preset structured scenario parameter library; A simulation scenario description file is generated based on the combination of scenario parameters.

3. The method according to claim 2, characterized in that, The structured scene parameter library includes multi-dimensional scene parameters. The step of extracting a combination of scene parameters matching the intelligent driving simulation scene from the preset structured scene parameter library based on the scene definition data includes: Parse the scene definition data to generate scene parameter sampling instructions; Based on the scene parameter sampling instructions, target scene parameters describing the intelligent driving simulation scene are extracted from the multi-dimensional scene parameters to obtain a combination of scene parameters that matches the intelligent driving simulation scene.

4. The method according to claim 3, characterized in that, The method further includes: If the initial combination of scenario parameters of the target scenario passes the constraint verification, the initial combination of scenario parameters is determined to be a combination of scenario parameters that matches the intelligent driving simulation scenario; the constraint verification includes at least one of physical rule verification, logical rule verification and distribution rule verification corresponding to the intelligent driving simulation scenario.

5. The method according to claim 1, characterized in that, The wireframe data includes a sequence of wireframe images, and the step of driving the simulation platform to perform wireframe rendering based on the simulation scene description file includes: Parse the simulation scenario description file to generate scenario simulation instructions; Based on the scene simulation instructions, the simulation platform is driven to render wireframe images in wireframe rendering mode, thereby obtaining the wireframe image sequence output by the simulation platform.

6. The method according to any one of claims 1 to 5, characterized in that, The method further includes: Preprocessing is performed on the wireframe data; the preprocessing includes quality assessment of the wireframe data; The preprocessed wireframe data is input into the generative world model to generate the intelligent driving simulation scene.

7. The method according to claim 6, characterized in that, The quality assessment of the wireframe data includes: Based on a number of preset quantitative indicators, the scores of the wireframe data are calculated for each indicator. The number of quantitative indicators includes at least two of the following: geometric integrity indicator, trajectory continuity indicator, viewpoint consistency indicator, dynamic richness indicator, and noise interference rate indicator. The scores of the multiple quantitative indicators are weighted and summed based on their respective weight distributions to obtain the overall quality score of the wireframe data; the overall quality score of the preprocessed wireframe data is greater than or equal to the preset quality pass score.

8. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method for generating wireframe data according to any one of claims 1 to 7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method for generating wireframe data as described in any one of claims 1 to 7.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the method for generating wireframe data as described in any one of claims 1 to 7.

Images