Proximity-based generation of surface textures for simulated environmental systems and applications

Abstract

In various examples, a simulation platform generates a simulated driving environment by processing road map data to derive the location of wear-related visual artifacts for sections of a lane surface. Using map data, the simulation platform generates texture maps for aesthetic road rendering, which are used to apply textures to a 3D polygon topology mesh. The simulation platform generates visual artifacts representing the wear and tear of the road surface based on a calculation of one or more lane feature distances derived from the map data. The simulation platform calculates distances associated with reference line data derived from an image to render a texture of one or more lane features.The spacing is used to determine how the appearance of the texel is adjusted to include wear-related visual artifacts when displayed on a lane of the simulated driving environment.

Description

BACKGROUNDIn many computer generated graphical simulations of today's driving environments, interactions between different objects and / or features are modeled as appearing and behavioring as their real counterparts appear and behavioring. For example, a simulation platform may generate a driving environment that includes a three-dimensional solid surface representing a road (or other path) and a three-dimensional solid object representing an instance of a simulated vehicle. The simulation platform may execute a physics engine or similar set of algorithms to manage interactions between the simulated vehicle and the simulated road surface according to the real physics, for example, to perform a simulation of the simulated vehicle standing on and / or riding over the simulated ground surface. Accordingly, simulation environments may use road surface data to generate a simulated road surface for the simulated vehicle to drive. Moreover, such simulated driving environments may be used in the method of training and / or validating machine learning models used to operate ego machines, such as, but not limited to, autonomous and semi-autonomous vehicles and autonomous and semi-autonomous moving robots or robot platforms.SUMMARYEmbodiments of the present disclosure relate to the generation of drivable surface textures for simulated environmental systems and applications. Systems and methods are disclosed that can be used to process road map data to generate visual artifacts (e.g., wear and tear) for realistic road surface representations in simulated driving environments.In contrast to conventional methods, the embodiments presented herein provide a simulation platform that generates a simulated driving environment by processing road map data to derive the location of visual artifacts for portions of a lane surface. In some embodiments, the simulation platform generates texture maps for aesthetic road rendering using map data, which are used to apply textures to a three-dimensional (3D) polygon topology network. The simulation platform generates visual artifacts - e.g., representing wear and tear - of the lane surface based on calculating one or more distances of lane features derived from the map data. That is, the simulation platform calculates distances associated with pixels of an image of a material that are used to represent a texture (often referred to as a "texel") of one or more lane features. The distances are then used in the determining to adjust the appearance of the texels to include the visual artifacts (e.g., wear-related) when displayed in a lane of the simulated driving environment.Lane features derived from map data may include, for example, lane boundary lines such as boundaries between lanes and / or boundaries representing the edges of the road. Other lane features may then be determined based on distances from the lane boundary lines to calculate surface reference lines used to represent the visual artifacts. As non-limiting examples, a surface reference line representing the center of a lane may be calculated as a line equidistant from left and right side lane boundary lines. A lane center reference line may be used as a reference from which fluid-colored surface materials may be represented. Similarly, one or more surface reference lines may be calculated that represent reference lines for rendering textures that represent road surface materials that are colored by tire wear.In some embodiments, a simulation platform may include a surface texture mapping function that applies one or more adjustments to the appearance of a road surface vertex to integrate visual artifacts for the wear and wear of the surface - wherein the degree of adjustment is based on the distance of a vertex from one or more of the surface reference lines. For example, the surface texture mapping function may apply a smooth curve and / or a look-up table to calculate and / or determine the decay rate in the degree of matching a texel for a particular visual artifact based on the distance(s) from one or more reference lines.The simulation platform may use texture maps adjusted by the surface texture mapping function to represent the wear and wear-based visual artifacts calculated based on distances from surface reference lines. The simulation platform may use a 3D surface topology network (e.g., a computer graphics model including a 3D surface network) to represent the surface structure within the simulated driving environment, including regions where drivable roads indicated by the map data are rendered. The 3D surface topology network may comprise a network of polygons defining the 3D surface topology of a scene within a simulated environment. To provide the roads in the simulated environment with an appearance similar to a specific road surface material (e.g., concrete, asphalt, gravel, etc.), the 3D surface topology mesh surfaces (e.g., defined by vertices forming a surface polygon) are expanded in appearance as indicated by the texture maps. The texels of the texel image are mapped back to the 3D surface topology network to impart the appearance of a road surface material to roads.BRIEF DESCRIPTION OF THE DRAWINGSThe present systems and methods for wear-based generation of drivable surface textures for simulated environmental systems and applications are described in detail below with reference to the accompanying drawing figures, wherein: FIGS. 1A-1B are exemplary illustrations of a simulation platform, in accordance with some embodiments of the present disclosure; FIG. 1C is an exemplary illustration of UV texture coordinate packaging, in accordance with some embodiments of the present disclosure; FIG. 2A is a diagram illustrating determination of lane boundary line data based on map data according to some embodiments of the present disclosure; FIGS. 2B-2D are diagrams illustrating determination of surface reference line data based on lane boundary line data, in accordance with some embodiments of the present disclosure; FIG. 3 is a diagram illustrating layering a plurality of different visual artifacts to produce a cumulative visual effect of road wear artifacts on a lane surface, in accordance with some embodiments of the present disclosure; FIGS. 4A and 4B are diagrams illustrating renderings of visual artifacts on a lane surface, in accordance with some embodiments of the present disclosure; FIG. 5 is a diagram illustrating a method for generating visual artifacts on a lane surface in a simulation environment, in accordance with some embodiments of the present disclosure; FIGS. 6A-6F are exemplary illustrations of a simulation system, in accordance with some embodiments of the present disclosure; FIG. 7A is an exemplary illustration of a simulation system at runtime, in accordance with some embodiments of the present disclosure; FIG. 7B includes a cloud-based architecture for a simulation system, in accordance with some embodiments of the present disclosure; FIG. 8A is an illustration of an example autonomous vehicle in accordance with some embodiments of the present disclosure; FIG. 8B is an example of camera positions and fields of view for the example autonomous vehicle of FIG. 8A, in accordance with some embodiments of the present disclosure; FIG. 8C is a block diagram of an example system architecture for the example autonomous vehicle of FIG. 8A, in accordance with some embodiments of the present disclosure; FIG. 8D is a system diagram for communication between cloud-based server(s) and the example autonomous vehicle of FIG. 8A, in accordance with some embodiments of the present disclosure; FIG. 9 is a block diagram of an example computing device suitable for use in implementing some embodiments of the present disclosure; and FIG. 10 is a block diagram of an example data center suitable for use in implementing some embodiments of the present disclosure.DETAILED DESCRIPTIONSystems and methods are disclosed with respect to creating surface textures for simulated environments. The present disclosure relates to computer-rendered graphics for simulated driving environments. In particular, the systems and methods presented in this disclosure provide technologies that can be used to process road map data to generate visual artifacts of, for example and without limitation, wear and wear for realistic road surface representations in simulated environments.Although some embodiments of the present disclosure may be described with respect to an example autonomous or semi-autonomous vehicle, robot, robot platform, or machine 800 (alternatively referred to herein as "vehicle 800" or "ego machine 800", an example of which is described with respect to FIGS. 8A-8D ), this is not intended to be limiting. For example, the systems and methods described herein may be used by, without limitation, non-autonomous vehicles or machines, semi-autonomous vehicles or machines (e.g., in one or more advanced driver assistance systems (ADASs)), autonomous vehicles or machines, controlled and non-controlled robots or robot platforms, storage vehicles, off-road vehicles, vehicles coupled to one or more trailers, airships, boats, shuttles, emergency vehicles, motor cycles, electric or motorized bicycles, aircrafts, construction vehicles, trains, underwater vehicles, remote controlled vehicles such as drones and / or other types of vehicles. Moreover, while the present disclosure may be described with respect to rendering road surface textures for simulated driving environments, this is not intended to be limiting, and the systems and methods described herein may be used in augmented reality content, virtual reality content, mixed reality, robotics, safety and monitoring, autonomous or semi-autonomous machine applications, and / or any other technology spaces in which rendering surface textures may be used for virtual scene topologies.In some existing simulated road rendering methods, map data modeled from real road maps may be applied to a three-dimensional (3D) surface topology that includes a 3D polygonal topology network. For the purpose of rendering a realistic simulated environment, the polygonal faces of the 3D polygonal topology network may be aligned with roads derived from the map data and provided with a texture corresponding to the material forming the surface of the road. Such texturing may be implemented, for example, using a set of texels (e.g., as a texture image) representing the appearance of the material used for the surface of the road. For example, for a concrete road surface, a texture image having the appearance of concrete may be applied to the mesh to provide a texture. Likewise, for a road surface constructed of asphalt or gravel, a corresponding image having the appearance of asphalt or gravel is applied to impart a texture to the surface. Texture images that provide a texture to a road surface may be sized and oriented to repeat seamlessly over the road surface such that a repeating pattern is not readily observable.That is, road surfaces rendered using only generic texture images tend to lack low frequency variations caused by the use of roads by vehicle traffic, such as road wear, including tire traces and spots from exiting vehicle fluids-and are therefore unable to provide realistic road surfaces as would be observed in the physical world. Current methods for adding road wear to computer graphics rendered roads often involve a graphics artist that uses 3D modeling software to paint visual artifacts manually onto the computer graphics rendered roads. Other methods may capture aerial images of the actual road represented by the map data (e.g., using an aerial drone) and project a texture from the images onto the rendered roads. Such methods may be prohibitively time-consuming and cumbersome for simulated driving environments that include thousands of kilometers of drivable road surfaces.In contrast to these conventional methods, the embodiments presented herein provide a simulation platform that generates a simulated environment by processing road map data to derive the location of (e.g., wear-related) visual artifacts for portions of a lane surface. In some embodiments, the simulation platform generates texture maps for road graphic rendering using map data, which are used to apply textures to a 3D polygon topology network. The simulation platform generates visual artifacts that represent and are consistent with the use and wear of real world road surfaces based on calculating one or more distances of lane features derived from the map data. That is, the simulation platform calculates distances associated with pixels of an image of a material that are used to represent a texture (often referred to as a "texel") of one or more lane features. The distances are then used in determining how to display the appearance of the texels in a lane of the simulated driving environment. As used herein, the terms "road" and / or "lane" are used in a general sense that may refer to any form of transit path or transit path between one location and another location in the simulation environment (e.g., any road or path included in the map data) - which provides a navigable route over which one or more ego agents may travel within the simulation environment. Map data used by the simulated driving environment may represent drivable roads as representations of drivable road segments, referred to herein as lanelets, that may be generated based on real roads and / or synthetically generated roads.Within a simulated driving environment, a set of individual lanelets may be interconnected as a basis for generating drivable road segments. In some embodiments, map data may be derived from sources such as, but not limited to, NVIDIA DRIVE map, NVIDIA HD map, OpenDRIVE maps, Universal Scene Description (USD) data, and / or other data from other mapping frameworks. As an example, map data including lanelets may be received in the form of an extensible markup language (XML) file or other file format.Lane features derived from map data may include, for example and without limitation, lane boundary lines such as boundaries between lanes and / or boundaries representing the edges of the road (e.g., where road surface and / or navigable boundaries terminate). Other lane features may then be determined based on distances from the lane boundary lines to calculate surface reference lines used to represent the visual artifacts. As non-limiting examples, a surface reference line representing the center of a lane may be calculated as a line equidistant from the left and right side lane boundary lines (e.g., left and right lane boundary indications from the map data). A lane center reference line may be used as a reference from which fluid-colored surface materials may be rendered, as vehicles may move on average approximately at the center of a lane and drop fluids from any portion of the vehicle chassis (although fluids may leak on average from locations near the center of the vehicle). Similarly, one or more surface reference lines may be calculated that represent reference lines for rendering textures that represent road surface materials that are colored by tire wear. As an example, the lane boundary lines may define a lane that is 3.6 meters wide, whereas the simulation platform may define an average wheel-to-wheel width of a vehicle as 1.5 meters. As such (again assuming vehicles are moving approximately in the center of a lane), a first surface reference line defining a first tire wear reference line may be calculated based on a distance from a left side lane boundary (e.g., about 1 meter to the right of the left side lane boundary) and a second surface reference line defining a second tire wear reference line may be calculated based on a distance from a right side lane boundary (e.g., about 1 meter to the left of the right side lane boundary). As another example, material discoloration may occur near the edge of a lane where small deposits and materials carried by rain drains accumulate. As such, another surface reference line may be calculated at a defined distance (e.g., 0.3 meters) from a lane boundary line for a lane edge to define a reference line for washing debris.With one or more of the embodiments discussed herein, the simulation platform may include a surface texture mapping function that applies one or more adjustments to the appearance of a road surface vertex (representing the texture of the road surface) to integrate visual artifacts for the wear and wear of the surface - wherein the degree of adjustment is based on the distance of a texel from one or more of the surface reference lines. For example, the appearance of texels closest to a reference line (e.g., a tire wear reference line) may be adjusted to exhibit a high degree of discoloration (e.g., due to tire wear), where adjustments to texels farther from the reference line are adjusted to decay (e.g., have progressively lower degrees of discoloration due to tire wear) as a function of distance from the reference line. For example, the surface texture mapping function may apply a smooth curve and / or a look-up table to calculate and / or determine the decay rate for the degree of matching at a texel for a particular visual artifact based on the distance(s) from one or more reference lines. Moreover, adjustments to a texel may be layered to account for cumulative effects of multiple different visual artifacts. For example, a tex may be adjusted to show a first degree of discoloration due to tire wear as a function of distance from the tire wear reference line and adjusted to show a second degree of discoloration due to leaking fluid spots as a function of distance from the lane center reference line. In this way, visual artifacts that account for changes in the appearance of the road surface due to wear and tear can be directly calculated by processing map data - which increases efficiency by avoiding the time-consuming use of computational resources that arise from a developer that needs to manually adjust road surface representations by painting surfaces using, for example, 3D modeling software.In some embodiments, the simulation platform uses texture maps (e.g., texel maps consisting of texel images) adjusted by the surface texture mapping function to represent the wear and wear-based visual artifacts calculated based on distances from surface reference lines. As described herein, the simulation platform may use a 3D surface topology network (e.g., a computer graphics model including a 3D surface network) to represent the surface structure within the simulated driving environment, including regions where drivable roads indicated by the map data are rendered. The 3D surface topology network may include a network of polygons (e.g., triangles) that define the 3D surface topology of a scene within a simulated environment (e.g., a simulated driving environment) for rendering by the simulation platform. To provide roads in the simulated environment with an appearance that looks like a specific road surface material (e.g., concrete, asphalt, gravel, etc.), the 3D surface topology mesh surfaces (e.g., defined by vertices that form a surface polygon) are expanded in appearance as indicated by texture maps, where a texture map may be structured as a texel image. The texels of the texel image are mapped back to the 3D surface topology network to impart the appearance of a road surface material to roads.In some embodiments, the simulation platform aligns drivable roads indicated by the map data with the 3D surface topology network representing a portion of the terrain within the simulated environment. The simulation platform may segment (e.g., subdivide) the simulated environment into a series of image tiles for further processing, where individual image tiles may include segments of drivable roads as well as other non-drivable surfaces.To process the series of tiles more efficiently, in some embodiments, each tile may be applied to a UV packaging function. That is, each tile is assigned a set of UV coordinates, where "U" and "V" indicate the axes of a two-dimensional (2D) texture image. These UV coordinates may be referred to as texture coordinates in UV-based texturing methods and may range from 0 to 1 along the abscissa and ordinate axes of a texture map. For a single tile, the regions of the 3D surface topology network corresponding to drivable roads are destructured into a plurality of segments that fit within the boundaries of a texel image using a UV packaging technique (sometimes referred to as a texel density). Based on the 3D surface topology network, UV deconvolution may be applied to surfaces corresponding to drivable roads and UV coordinates generated for at least one (e.g., each) vertex of the 3D surface topology network. At least one (e.g., each) vertex of the 3D surface topology map may include a data structure that describes one or more attributes (e.g., color, location, and / or other attributes) that may be used to render a texture across a region of the 3D surface topology network. The texel image provides a rastered image in UV coordinate space representing textures to be applied to respective surfaces of the 3D surface mesh to generate road surface rendering data. Each pixel of the texel image is a texel having a UV coordinate that can be mapped back to a respective vertex of the 3D surface topology network using a UV projection. In other words, the simulation platform may use UV texture coordinates assigned to a vertex of the 3D surface topology network to reference texels of the texture map to determine how to apply the appearance of a texture to the 3D surface topology network to render a realistic looking road surface in the simulated environment.When the simulation platform de-constructs the segments of the 3D surface topology network for the drivable roads to form the texel image for a texture map, the location of lane features (provided by the map data) relative to vertices of the 3D surface topology network may be maintained and presented in the texel images (such as lane boundary lines determined from the map data). Thus, the simulation platform may process the texel image based on lane boundary lines to determine surface lines and then generate one or more visual artifacts for individual texels of the texel map as a function of the distance therefrom one or more of the surface lines. In some embodiments, each of the wear-related visual artifacts in a texel image may be represented as a grayscale luminance value in a corresponding attribute channel of a texel, and then the UV coordinates of the texel may be projected back onto the corresponding vertex of the 3D surface topology network to apply an image of a texture as modified by one or more visual artifacts to a region of the 3D surface topology network representing the drivable road. As mentioned above, a texel may include multiple attribute channels, where the different channels may store data for rendering different wear-related visual artifacts. When rendering a road surface texture on the 3D surface topology network, multiple visual artifacts may be applied to regions of the 3D surface topology network by layering the discoloration adjustments represented by each attribute channel. In some embodiments, additional visual adjustments may be made to modulate the intensity of visual artifact adjustments along the direction of travel (e.g., using a randomizing method) to further increase variations that improve the realism of the appearance in a road surface.In some embodiments, texels of a texels image for a texture map are generated from a basic texture image associated with a road surface material. For example, the simulation platform may access (e.g., created by a graphic artist) a library of curved road surface material assets and retrieve a road surface material asset that includes a base texture image that represents the appearance and / or texture of a road surface material associated with a location of a drivable road on the 3D surface topology network. The base texture image may represent a texture using an image having the appearance of gravel, asphalt, concrete, or other textures such as dirt, sand, and / or grass. In some embodiments, the wear-based discoloration adjustments represented by each attribute channel of a sickle card function as texture masking characteristics that can be applied to the base texture image to render a composite texture image, which is then applied to the 3D surface topology network based on a UV mapping of texels of the sickle image to vertices of the 3D surface topology network.In some embodiments, the resulting road surface rendering data may be used to generate scene description data and output the data as a data file, such as a Universal Scene Description (USD) file. The scene description data may be provided to the simulation platform as road surface rendering data to generate a scene that includes a simulated environment in which roads within the scene include drivable surfaces with textured appearances that include wear-based visual artifacts, as discussed herein. In some embodiments, the scene description data may be provided as input directly to the simulation platform. The scene description data may be used by the simulation platform to generate a visual rendering of a scene and / or physical simulations of interactions between rigid bodies.In some embodiments, drivable surfaces with wear-based visual artifacts may be used in a simulated driving environment used to generate synthetic sensor data used to train, update, and / or test machine learning models and / or other components of ego machines, such as autonomous and semi-autonomous vehicles. For example, in some embodiments, textured renderings of the one or more drivable road surfaces may be rendered in a computer vision simulation environment and used to generate synthetic sensor data. For example, the simulation platform may process the computer vision simulation environment to generate synthetic image data for one or more cameras or other virtualized image sensors of an ego vehicle that uses the computer vision simulation environment as a simulated driving environment for training and / or testing components of the ego vehicle. That is, image data corresponding to virtualized image sensors may include renderings of one or more drivable road surfaces that include wear-based visual artifacts generated as described herein. Different channels of such virtualized image sensor data may be generated to correspond to different sensors having different views of an environment around an ego vehicle and used as input to a computer simulation of an ego vehicle or substituted for actual data channels as input for testing a physical ego vehicle. In some embodiments, a simulated or actual ego vehicle may generate a computer vision representation of an environment around the ego vehicle that includes drivable road surfaces with wear-based visual artifacts. The renderings of the one or more drivable road surfaces include visual artifacts of wear and tear resulting in more realistic road surface representations for viewing via a display device by humans as well as more realistic road surface representations for training machine learning models.One or more aspects of the simulation platform and / or tile surface texture mapping of visual artifacts may be executed at least in part on one or more graphics processing units that may operate in conjunction with software executed on a central processing unit coupled to memory. In some embodiments, the various functions performed to generate road textures with wear-based visual artifacts may be performed at least using functions from a computer graphics 3D animation software library. The graphics processing units may be programmed to execute kernels to implement one or more of the features and functions of the simulation platform described herein. In some embodiments, aspects of the simulation platform may be executed in parallel on different GPUs. In some embodiments, some features and functions of the simulation platform may be distributed and performed by a combination of one or more processors including processing circuitry and / or cloud computing resources. For example, in some embodiments, simulation platform functions to generate road textures with wear-based visual artifacts may be implemented at least in part as a virtual function in a cloud computing environment and / or implemented as a component of a virtualized machine learning model.Referring to FIG. 1A, FIG. 1A is an example dataflow diagram for a method for a driving environment simulation platform 100 that implements wear-based generation of surface textures for simulated environmental systems and applications, in accordance with some embodiments of the present disclosure. It should be understood that these and other arrangements described herein are presented by way of example only. Other arrangements and elements (e.g., machines, interfaces, functions, orders, groupings of functions, etc.) may be used in addition to or in place of those shown, and some elements may be omitted altogether. Further, many of the elements described herein are functional entities that can be implemented as discrete or distributed components or in conjunction with other components and in any suitable combination and location. Various functions described herein as being executed by entities may be executed by hardware, firmware, and / or software. For example, various functions may be performed by one or more processors including processing circuitry executing instructions stored in memory. In some embodiments, the various functions and operations of the driving environment simulation platform 100 described herein may be implemented at least in part using a simulation system 600 as illustrated by the simulation systems 600A, 600B, 600C, and 600D in FIGS. 6A-D and described in more detail below.As shown in FIG. 1A, the driving environment simulation platform 100 processes road map data 104 to generate an image tile texel map 132, which may be used to generate road surface rendering data 142 to generate visual artifacts of wear and wear for realistic road surface representations in simulated environments (e.g., the simulated environment 610 as discussed with respect to FIG. 6A ), which may include a simulated driving environment. The map data 104 may represent one or more drivable road surfaces as representations of drivable road segments, referred to herein as lanelets, that may be generated based on real roads and / or synthetically generated roads, in some embodiments. A set of individual lanelets may be interconnected as a basis for generating drivable road segments. In some embodiments, map data 104 may be derived from sources such as, but not limited to, NVIDIA DRIVE map, NVIDIA HD map, OpenDRIVE maps, Universal Scene Description (USD) data, and / or other data from other geo-mapping or driving frameworks. As an example, map data 104 including lanelets may be received in the form of an extensible markup language (XML) file or other file format. In some embodiments, the driving environment simulation platform 100 may include a preprocessor (e.g., the road segmentation function 110) that may reformat map data 104 received in various formats into lanelets for further processing as described herein to render road surfaces that include road wear-based visual artifacts.As shown in FIG. 1A, the driving environment simulation platform 100 may include the road segmentation function 110 that receives the map data 104 and / or 3D surface topology data 106 as input to generate segments of the road as image tiles represented by image tile data 114. The driving environment simulation platform 100 uses the 3D surface topology data (e.g., a computer graphics model that includes a 3D surface topology network) representing a terrain within a simulated environment that is rendered including the regions where drivable roads are indicated by the map data 104. The 3D surface topology data 106 may include a network of polygons (e.g., triangles) that define the 3D surface topology of a scene within the simulated environment for rendering by the driving environment simulation platform 100. In some embodiments, the road segmentation function 110 correlates (e.g., aligns) one or more drivable road surfaces indicated by the map data 104 with a corresponding region of the 3D surface topology data 106 and segments the resulting roads and topology into a series of image tiles, where individual image tiles may be represented by image tile data 114. The image tile data 114 may include a base tile image 116 representing the roads that appear in this region of the simulated environment, along with a tile 3D surface topology network 120 representing the surface topology of the region for the tile within the simulated environment, as derived from the 3D surface topology data 106 by the road segmentation function 110.To more efficiently process the series of tiles, in some embodiments, each tile may be processed with a UV packing function 112 to generate a UV-packed road image 118. For example, the base tile image 116 is assigned a set of UV coordinates (e.g., texture coordinates) that may range from 0 to 1 along the abscissa and ordinate axes of a texture map. For a single tile represented by the image tile data 114, regions of the 3D surface topology data 106 corresponding to drivable roads are reconstructed into a plurality of segments that fit within the boundaries of a texel image using a UV packaging technique (sometimes referred to as a texel density). For example, FIG. 1C illustrates an example UV road image 118 (shown at 196) that may be generated by the UV packing function 112 based on the base tile image 116. As shown at 190, the base tile image 116 may include one or more regions of pixels within the boundaries of the tile that represent roads defined by the map data 104 (e.g., shown as road regions 192). The base tile image 116 may also include one or more regions of pixels representing non-drivable surfaces within the boundaries of the tile (e.g., shown as non-road regions 194). To avoid using processing resources and memory to evaluate non-road regions 194 for road wear artifacts, the UV packing function 112 disassembles the road regions 192 of the base tile image 116 into a plurality of UV sections 198 within the UV road image 118. The UV portions 198 may be of any size and shape and arranged by the UV packaging function 112 using UV packaging (e.g., Texe density) to fit within the boundaries of the UV road image 118 that may be used to form an image tile Texe map (e.g., a Texe image), as discussed herein. The UV road image 118 thus provides a rastered image in the UV coordinate space that can be updated by the tile surface texture mapping function 130 to represent textures that can be applied to respective faces of the 3D surface topology data 106 network to generate road surface rendering data 142.As shown in FIG. 1A, the image tile data 114 is processed by the tile surface texture mapping function 130 such that the UV road image 118 is used to generate an image tile texel map 132 (which may include a texel image based on the UV road image 118 and may have UV coordinates matching those of the UV road image 118).As discussed herein, the UV road image 118 may be processed to calculate reference lines for rendering road surface textures on the 3D surface topology network 120 that include various wear-related visual artifacts. In particular, the tile surface texture mapping function 130 generates visual artifacts representing road surface usage and wear based on calculating one or more distances of lane features derived from the image tile data 114. In some embodiments, an image tile texel map 132 may be generated based on the UV road image 118 and may be initialized with texel (texture image) data based on the surface material of the one or more roads included in the image tile data 114. In some embodiments, the driving environment simulation platform 100 may include or otherwise access an asset library comprising road surface texture image data 122. For texels of the image tile texel map 132 corresponding to asphalt road surfaces, the tile surface texture mapping function 130 may access asphalt road texture images and assign these asphalt road texture images to texels of the image tile texel map 132 that are used to render the asphalt road surfaces. For texels of the image tile texel map 132 corresponding to particular road surfaces, the tile surface texture mapping function 130 may access particular road texture images and assign those particular road texture images to texels of the image tile texel map 132 that are used to render the particular road surfaces. For texels of the image tile texel map 132 corresponding to unfastened road surfaces (e.g., gravel, dirt, grass, etc.), the tile surface texture mapping function 130 may access unfastened road texture images and assign the unfastened road surface texture images to texels of the image tile texel map 132 that are used to render the corresponding unfastened road surfaces. The texels of the initialized image tile texel map 132 may then be adjusted to have visual artifacts that represent road surface usage and wear.In particular, in some embodiments, the tile surface texture mapping function 130 may include a visual artifact adaptation function 140 that extracts road boundary line data 136 (e.g., which may define one or more polylines in 3D space) from the image tile data 114 (e.g., using the UV road image 118) and calculates, from the road boundary line data 136, vector space surface reference line data 138 (e.g., as one or more polylines in 3D space) for one or more surface characterization lines. For example, the surface reference line data 138 may include polylines generated from the road boundary line data 136 by interpolating vertex positions between boundaries (e.g., centerlines) or offsetting a resulting center curve by a given distance in either bitmap directions (e.g., lanes and / or spots). In some embodiments, distances used for generating surface reference line data 138 may be based on real distances and / or units of measure (e.g., in meters / centimeters, feet / inch). The surface baseline data 138 may then be used to calculate graded adjustments to the image tile texel map 132 based on the visual artifact texture data 124. FIGS. 2A-2E illustrate one such method that may be performed by a visual artifact adjustment function 140 to calculate wear-based visual artifact adjustments. Although FIGS. 2A-2E illustrate a two-lane road for example purposes, embodiments are not so limited and may include determining boundary line data 136 and / or calculating surface reference line data 138 for roads having any number of lanes.For example, FIG. 2A illustrates an example extraction of lane boundary line data 136 from the image tile data 114 at 201. In some embodiments, the illustrated lane boundary line data 136 corresponds to a single UV portion 198 for the image tile texel map 132, and similar boundary line data extractions may be performed for each UV portion of the image tile texel map 132. For example, the visual artifact adjustment function 140 may identify lane boundary lines 210 (e.g., curbs and / or edges of roads where road surfaces and / or lane boundaries end) based on the image tile data 114. The image tile data 114 may further define lane boundary information. For example, the visual artifact adjustment function 140 may identify lane boundary lines 212 based on the image tile data 114 that separate lanes for traffic within the boundaries of the identified lane boundary lines 210 (e.g., lane L 1 and lane L 2). It should be noted that in some cases road map data 104 may include lane boundary line data 136 including center line representations (e.g., road map data 104 derived from DeepMap and / or omnimap sources), while in other cases road map data 104 may not include center line data (e.g., road map data 104 derived from OpenDrive sources). In some embodiments, if midline data is not included in the road map data 104, surface reference line data 138 for representing the center of a lane may be obtained as described in FIG. 2B.As a non-limiting example, FIG. 2B illustrates calculating surface reference line data 138 for surface reference line(s) 214 representing the center of a lane. For example, as shown at 202, a first track center surface line (surface reference line 214) may be calculated based on determining polylines with respect to the track L 1 equidistant (e.g., a distance of L 1 / 2) from each of the track boundary lines 212 defining the track L 1. Similarly, a second track center surface line (surface reference line 214) may be calculated based on determining polylines with respect to the track L 2 equidistant (e.g., a distance of L 2 / 2) from each of the track boundary lines 212 defining the track L 2. The track center surface reference line 214 may be used as a reference from which a gradient of visual artifacts of fluid-colored surface material may be derived. For example, in some embodiments, the visual artifact adjustment function 140 may access visual artifact texture data 124 representing the visual characteristics of a fluid-colored surface and adjust the values of one or more texels of the texel map 132 in a stepped manner based on a function of distance from the track center surface reference line 214 to generate a visual fluid speckle artifact 216 centered on the track center surface reference lines 214 of the respective track L 1 and track L 2. The visual fluid staining artifact 216 is graded to have a highest value (e.g., the least transparency) near the track center surface reference line 214, and to decrease the value after a predetermined decay curve with increasing distance from the track center surface reference line 214 (e.g., to a predefined threshold distance). In some embodiments, the value of the visual fluid speckle artifact 216 applied to a texel may be stored in the texel map 132 as a grayscale luminance value in a corresponding attribute channel of that texel associated with the visual fluid speckle artifacts.As another non-limiting example, FIG. 2C illustrates calculating surface reference line data 138 for surface reference line(s) 220 for visual artifacts related to tire wear. For example, as shown at 203, within a track (e.g., L 1 and / or track L 2), a first tire wear surface reference line 220 may be calculated based on a function of the distance D 1 from a first track boundary line 212 and / or the distance D 2 from the track center surface reference line 214. Similarly, a second tire wear surface reference line 220 may be calculated based on a function of the distance D 1 from a second lane boundary line 212 and / or the distance D 2 from the lane center surface reference line 214. The calculated tire wear surface reference line(s) 220 may / may be used as a reference from which a gradient for visual artifacts of tire wear surface material may be derived. For example, in some embodiments, visual artifact adjustment function 140 may access visual artifact texture data 124 representing the visual characteristics of tire wear on a surface and adjust the values of one or more texels of the texel map 132 in a stepped manner based on a function of distance from a tire wear surface reference line 220 to generate a visual tire wear artifact 222 centered on a set of tire wear surface reference line(s) 220 calculated for the respective lane L 1 and lane L 2. The visual tire wear artifact 222 is graded to have a highest value (e.g., the least transparency) near the tire wear surface reference line 220, and to decrease the value after a predetermined decay curve with increasing distance from the tire wear surface reference line 220 (e.g., to a predefined threshold distance). In some embodiments, the value of the visual tire wear artifact 222 applied to a texel may be stored in the texel map 132 as a grayscale luminance value in a corresponding attribute channel of that texel associated with the visual tire wear artifacts.As a non-limiting example, FIG. 2D illustrates calculating surface reference line data 138 for surface reference line(s) 234 for visual road artifacts. For example, as shown at 206, a first road edge wash surface reference line 230 for a lane L 1 may be calculated based on determining a function of the distance D 3 from a first lane edge boundary line 210 and / or the distance D 4 from the lane boundary line 212. Similarly, a second reference line 230 for a roadside wash-off surface for a lane L 2 may be calculated based on determining a function of the distance D 3 from a second lane edge boundary line 210 and / or the distance D 4 from a lane boundary line 212. The roadside wash surface reference line 230 may be used as a reference from which a gradient for visual artifacts with respect to roadside wash surface material may be derived. For example, in some embodiments, visual artifact adjustment function 140 may access visual artifact texture data 124 representing the visual characteristics of dirt, debris, stains, and other images of roadside wash material, and adjust the values of one or more texels of the texel map 132 in a stepped manner based on a function of distance from the roadside wash surface reference line 230 to generate a visual roadside wash artifact 232 that originates from the roadside wash surface reference line 230 and extends toward a roadside boundary line 210. The roadside visual wash artifact 232 may be graded to have a lowest value (e.g., the greatest transparency) near the roadside wash surface reference line 230 and to increase the value after a predetermined decay curve with increasing distance from the roadside wash surface reference line 230 (e.g., up to a predefined threshold distance). In some embodiments, the value of the roadside wash surface reference line 230 applied to a texel may be stored in the texel map 132 as a grayscale luminance value in a corresponding attribute channel of that texel associated with the visual fluid staining artifacts.It should be appreciated that the visual artifacts of fluid-colored surface material, the visual artifacts of tire wear surface material, and the visual artifacts of roadside wash surface material are provided as non-limiting examples of visual artifacts that may be generated by the visual artifact adjustment function and mapped by projecting texel attribute channel values from the image tile's texel map 132 onto the tile's 3D surface topology network 120. One or more other road surface visual artifacts may likewise be generated based on the same method of defining one or more surface reference lines (e.g., based on boundary lines and / or other surface reference lines) and then calculating pixel values for artifact texture data varying as a gradient based on a function of distance from the one or more surface reference lines. In some embodiments, additional visual adjustments may be made to modulate the intensity of adjustments to visual artifacts applied to a road surface within an image tile to further increase variations that improve the realism of the appearance in a road surface. As a non-limiting example, a visual fluid staining artifact 216 centered by the lane center surface reference lines 214 may be modulated in terms of saturation / intensity along the direction of travel of the road. The modulation may be implemented using a randomizing and / or periodic method and / or based on other road factors. For example, the visual fluid staining artifact 216 may be adjusted to have a higher value (e.g., to apply a darker stain) at road segments adjacent intersections to simulate the effect of a higher collection of stains from vehicles that are temporarily stopped and idling at these locations.FIG. 3 illustrates an example of layering a plurality of different visual artifacts to produce a cumulative visual effect of road wear on a lane surface from multiple sources, in accordance with some embodiments. As discussed above, an initial version of the image tile texel map 132 (shown at 320) may be initialized with texels (texture image) data based on the surface material of the one or more roads included in the image tile data 114 using road surface texture image data 122 corresponding to the material of the surface of the road (e.g., asphalt, concrete, gravel, dirt, grass, etc.). The initial image tile texel map 320 may then be adjusted by adjusting the values of the visual artifact attribute channels 310 of the image tile visual artifact texel map 132 such as, but not limited to, visual fluid blotch artifacts 216 (as shown at 203), visual tire wear artifacts 222 (shown at 205), visual roadside wash artifacts 232 (shown at 207), and / or other visual artifacts. In some embodiments, visual artifact adjustment function 140 may use visual artifact texture data 124 to assign a base appearance to a visual artifact attribute channel 310 associated with the particular visual artifact being rendered. For example, visual tire wear artifacts may be assigned to visual artifact texture data 124 having the appearance of flat black gum, while visual fluid leak artifacts may be assigned to visual artifact texture data 124 having the appearance of a slightly glossy brown fluid. The degree to which the appearance is applied to one or more pixels of the initial image tile texel map 320 is represented by the value of the visual artifact attribute channel 310 associated with that individual visual artifact - which, as described herein, is based on a gradient curve as a function of the distance from one or more surface reference lines.The resulting image tile texel map 132 generated by the tile surface texture map 130 represents the cumulative effect of one or more visual artifact attribute channels 310 as adjustments to the initial image tile texel map 320. In some embodiments, each pixel of the image tile texel map 132 is a texel having a UV coordinate that can be mapped back to a respective vertex of the 3D surface topology network 120 using a UV projection. In other words, the tile surface texture map 130 may use the UV texture coordinates assigned to a vertex of the 3D surface topology mesh 120 to reference texels of the image tile texel map 132 to determine how to apply the appearance of a texture (both the base surface material texture image and one or more visual artifacts) to the 3D surface topology mesh 120 to render a realistic-looking road surface within the image tiles generated in the simulated environment. The faces of the 3D surface topology mesh 120 are thus improved in appearance as indicated by the image tile texel map 132. The texels of the image tile texel map 132 are mapped back onto the 3D surface topology network 120 to impart to roads the appearance of a road surface material which is colored in appearance due to one or more different forms of road wear. The result of mapping the texels of the image tile texel map 132 to the 3D surface topology network 120 may be output by the tile surface texture mapping function 130 as road surface rendering data 142. In some embodiments, the road surface rendering data 142 may be used to generate and output scene description data as a data file, such as a Universal Scene Description (USD) file. In some embodiments, the road surface rendering data 142 may be used as input to a simulation processor to generate a scene that includes a simulated environment in which roads within the scene include drivable surfaces with textured appearances that include wear-based visual artifacts, as discussed herein.As shown in FIG. 1B, the driving environment simulation platform 100 may further include a simulation processor 160 including a scene rendering engine 162. The scene rendering engine 162 may be used to realize and / or render a simulated driving environment in which one or more simulated machine agents may simulate driving over one or more lane surfaces defined based at least in part on the road surface rendering data 142. In some embodiments, the road segmentation function 110 and / or tile surface texture map 130 may be a component that is at least partially integrated with the simulation processor 160 or may be a different component that is separate from the simulation processor 160.The scene rendering engine 162 may include one or more algorithms that may be executed at least in part on one or more graphics processing units (GPUs) (or other parallel processing circuitry, such as a parallel processing unit (PPU), a deep learning accelerator (DLA), a vector processing unit (VPU), a programmable image processing accelerator (PVA), etc.) that may operate in conjunction with software executed on one or more central processing units (CPU(s)) coupled to memory. The GPUs may be programmed to execute kernels to implement one or more of the features and functions of the road segmentation function 110, the tile surface texture map 130, and / or the scene rendering engine 162. In some embodiments, some features and functions of the road segmentation function 110, the tile surface texture map 130, and / or the scene rendering engine 162 may be distributed and performed by a combination of processors and / or cloud computing resources.Input channels to the scene rendering engine 162 may include the road surface rendering data 142, a physics engine 164, simulation parameters 166, and / or simulated machine agent data 168. In some embodiments, the input channels to the scene rendering engine 162 may include real-time user inputs 169. The simulation parameters 166 may include operating parameters relevant to structuring and performing a driving simulation, such as simulation duration and image rendering frequency. In some embodiments, the simulated machine agent data 168 may define characteristics of one or more simulated vehicles within the driving environment (e.g., size, weight, or other characteristics). The physics engine 164 may provide data regarding interactions between the simulated machine agents and the simulated lane surface, which is at least partially defined by road surface rendering data 142 according to the real physics (e.g., to perform a simulation of the simulated vehicle standing on and / or riding over the simulated drivable surface). Real-time user inputs 169 may include, for example, user interactions to control the speed and / or direction of one or more of the machine agents within the simulation.Based on at least one or more of the input channels, the scene rendering engine 162 may generate a runtime simulation output 180, which may include a visual rendering of a scene and / or results of physical simulations of interactions between rigid bodies within the simulated driving environment. The runtime simulation output 180 may be displayed with a human machine interface (HMI) 185 (e.g., a display screen) and / or stored for subsequent streaming, such as with the human machine interface 185. In one or more embodiments, the road surfaces generated by the simulation processor 160 based on the road surface rendering data 142 may be used for other purposes. For example, such runtime simulation outputs 180 of simulated driving environments may be used in the method of training and / or validating machine learning models used to operate ego machines, such as, but not limited to, autonomous and semi-autonomous vehicles. In some embodiments, the runtime simulation output 180 includes renderings of drivable surfaces with wear-based visual artifacts that can be used to generate synthetic sensor data for training and / or testing machine learning models and / or other components of ego machines, such as autonomous and semi-autonomous vehicles. For example, the simulation processor may output the runtime simulation output 180 for use as synthetic image data for one or more cameras or other virtualized image sensors of an ego vehicle (such as the ego machine 800 described with reference to FIGS. 8A-8D ) that the computer vision simulation platform 100 uses to provide a simulated driving environment for training and / or testing components of the ego vehicle.FIGS. 4A and 4B are diagrams illustrating example renderings of visual artifacts on a lane surface, in accordance with some embodiments of the present disclosure. FIG. 4A illustrates an aerial view of a rendering of a simulated environment 400 that includes a rendered lane surface 410. The rendered lane surface 410 includes a baseline of texture images corresponding to a concrete surface material applied to a 3D surface topology, which in this example corresponds to a substantially flat region of city roads. As shown in FIG. 4A, the base concrete texture image of the rendered lane surface 410 is adjusted to include various visual artifacts generated by a tile surface texture map 130. For example, the rendered lane surface 410 includes visual fluid leak artifact renderings, such as shown at 420, and visual tire wear artifact renderings, such as shown at 425. FIG. 4B illustrates an alternative perspective of the simulated environment 400 of FIG. 4A that is closer to a road plane view, wherein the rendered lane surface 410 includes a baseline of texture images corresponding to a concrete surface material adapted to include various visual artifacts such as visual fluid leak artifacts 420 and visual tire wear artifacts 425.FIG. 5 is a diagram illustrating a method for generating visual artifacts on a lane surface in a simulation environment, in accordance with some embodiments of the present disclosure. It should be appreciated that the features and elements described herein with respect to the method 500 of FIG. 5 may be used in conjunction with, in combination with, or replaced by elements of any of the other embodiments discussed herein, and vice versa. Further, it is understood that the functions, structures, and other descriptions of elements for embodiments described in FIG. 5 may apply to like or similarly named or described elements in any of the figures and / or embodiments described herein, and vice versa.Each block of the method 500 described herein includes a computing process that may be performed using any combination of hardware, firmware, and / or software. For example, various functions may be performed by a processor executing instructions stored in a memory. The methods may also be embodied as computer usable instructions stored on computer storage media. The methods may be provided by a stand-alone application, service or hosted service (stand-alone or in combination with another hosted service), or plug-in for another product, to name just a few. Additionally, the method 500 will be described by way of example with respect to the driving environment simulation platform 100 of FIG. 1A. However, these methods may additionally or alternatively be performed by any system or combination of systems including, but not limited to, those described herein.As discussed in more detail herein, the method may include generating a textured rendering of one or more road surfaces in a simulated environment based on at least one mapping of one or more individual texels to one or more vertices of a 3D polygon topology network representing a surface structure for at least a portion of the simulated environment, wherein the one or more individual texels are adjusted based on at least one function of distance to one or more surface lines derived from map data representing the one or more drivable road surfaces.The method 500 includes, at B 502, correlating one or more surfaces of an environment represented by map data with one or more regions of a three-dimensional (3D) polygon topology network corresponding to the environment. For the purpose of rendering a realistic simulated driving environment, the polygonal faces of the 3D polygonal topology network may be aligned with roads derived from the map data and provided with a texture corresponding to the material forming the surface of the road. Such texturing may be implemented, for example, using a texture image having the appearance of the material used for the surface of the road. The map data may represent drivable roads as representations of drivable road segments, referred to herein as lanelets, in some embodiments, that may be generated based on real roads and / or synthetically generated roads. A set of individual lanelets may be interconnected as a basis for generating drivable road segments. As an example, map data including lanelets may be received in the form of an extensible markup language (XML) file or other file format. The 3D surface topology data may include a network of polygons (e.g., triangles) that define the 3D surface topology of a scene within the simulated environment for rendering by the driving environment simulation platform. In some embodiments, as shown in FIG. 1A, a road segmentation function 110 aligns drivable roads indicated by the map data 104 at a corresponding region of the 3D surface topology data 106 and segments the resulting roads and topology into a series of image tiles, where individual image tiles may be represented by image tile data 114. The image tile data 114 may include a base tile image 116 representing the roads that appear in this region of the simulated environment, along with a tile 3D surface topology network 120 representing the surface topology of the region for the tile within the simulated environment, as derived from the 3D surface topology data 106 by the road segmentation function 110.The method 500 includes, at B 504, determining, based at least on the map data, one or more boundary lines corresponding to one or more tracks of the one or more surfaces. In some embodiments, a tile surface texture mapping function 130 may include a visual artifact adaptation function 140 that extracts road boundary lines from the image tile data 114 (e.g., using the UV road image 118). For example, as shown in FIG. 2A, the visual artifact adjustment function 140 may identify lane edge boundary lines 210 (e.g., curbs and / or edges of roads where road surface and / or drivable boundaries end) based on the image tile data 114. The image tile data 114 may further define lane boundary information. For example, the visual artifact adjustment function 140 may identify lane boundary lines 212 based on the image tile data 114 that separate lanes for traffic within the boundaries of the identified lane boundary lines 210 (e.g., lane L 1 and lane L 2). In some embodiments, the road boundary line data 136 may be calculated for a single UV portion of the image tile texel map 132, and similar boundary line data extractions may be performed for each UV portion of the image tile texel map 132.The method 500 includes, at B 506, calculating one or more surface lines associated with the one or more tracks based at least on the one or more boundary lines. The surface reference line data 138 may then be used to calculate graded adjustments to the image tile texel map 132 based on visual artifact texture data 124, as shown in FIGS. 2A-2E. The one or more surface lines may be associated with discoloration of the one or more surfaces based on at least one of tire wear, stains from exiting vehicle fluids, contact damage, and / or collected road debris.The method 500 includes, at B 508, generating a texel image representing a surface texture appearance for the one or more tracks, wherein individual texels of the texel image are adjusted based on at least one function of distance to at least one surface line of the one or more surface lines. The texel image may include a texture map.For example, a track center surface reference line 214 may be used as a reference from which a gradient for visual artifacts of fluid-colored surface material may be derived. The visual artifact adjustment function 140 may access the visual artifact texture data 124, which represents the visual characteristics of a fluid-colored surface, and adjust the values of one or more texels of the texel map 132 in a graduated manner based on a function of distance from the track center surface reference line 214 to generate a visual fluid speckle artifact 216. Similarly, in some embodiments, surface reference line(s) 220 may be calculated for visual artifacts related to tire wear. The calculated tire wear surface reference line(s) 220 may / may be used as a reference from which a gradient for visual artifacts with respect to tire wear surface material may be derived. For example, in some embodiments, visual artifact adjustment function 140 may access visual artifact texture data 124 representing the visual characteristics of tire wear on a surface and adjust the values of one or more texels of the texel map 132 in a stepped manner based on a function of distance from a tire wear surface reference line 220 to generate a visual tire wear artifact 222 centered with a set of tire wear surface reference line(s) 220. In some embodiments, surface reference line(s) 234 may be calculated for road edge visual wash artifacts. The roadside wash surface reference line 230 may be used as a reference from which a gradient for visual artifacts with respect to roadside wash surface material may be derived. For example, in some embodiments, the visual artifact adjustment function 140 may access visual artifact texture data 124 representing the visual characteristics of dirt, debris, stains, and other images of roadside wash material, and adjust the values of one or more texels of the texel map 132 in a stepped manner based on a function of distance from the roadside wash surface reference line 230 to generate a visual roadside wash artifact 232 originating from the roadside wash surface reference line 230.It should be appreciated that the visual artifacts of fluid-colored surface material, the visual artifacts of tire wear surface material, and the visual artifacts of roadside wash surface material are provided as non-limiting examples of visual artifacts that may be generated by the visual artifact adjustment function and mapped by projecting texel attribute channel values from the road tile's texel map 132 onto the tile's 3D surface topology network 120. One or more other road surface visual artifacts may likewise be generated based on the same method of defining one or more surface reference lines (e.g., based on boundary lines and / or other surface reference lines) and then calculating pixel values for artifact texture data varying as a gradient based on a function of distance from the one or more surface reference lines. In some embodiments, additional visual adjustments may be made to modulate the intensity of visual artifacts applied to one or more navigable (e.g., road) surfaces (e.g., along a direction of travel) within an image tile to further increase variations that improve the realism of the appearance in a road surface. As a non-limiting example, a visual fluid staining artifact 216 centered by the lane center surface reference lines 214 may be modulated in terms of saturation / intensity along the direction of travel of the road. The modulation may be implemented using a randomizing and / or periodic method and / or based on other road factors. For example, the visual fluid staining artifact 216 may be adjusted to have a higher value (e.g., to apply a darker stain) at road segments adjacent intersections to simulate the effect of a higher collection of stains from vehicles that are temporarily stopped and idling at these locations. In some embodiments, the method may assign UV coordinates to the one or more vertices of the 3D polygon topology network, generating a set of texels in a UV coordinate space, and mapping the one or more vertices of the 3D polygon topology network to individual texels from the set of texels based at least on the UV coordinates. That is, to generate the texel image, the method may disassemble at least one segment of the 3D surface topology network into a plurality of segments and adjust the plurality of segments within the boundaries of the texel image using a UV packaging method. In some embodiments, individual vertices of the one or more vertices include a data structure that describes one or more visual artifacts, wherein the one or more visual artifacts are used to adjust an appearance of the one or more surfaces based at least on the individual texels of the set of texels. As discussed herein, individual texels of the set of texels represent a combination of a baseline texture image and one or more texture masking characteristics that conform the baseline texture image in appearance based at least on the function of distance to at least one surface line of the one or more surface lines.The method 500 includes, at B 510, generating a rendering of the one or more surfaces in a simulation environment based at least on mapping the individual texels of the texel image to one or more vertices of the 3D polygon topology network. A base texture image may represent a texture using an image having the appearance of gravel, asphalt, concrete, or other textures such as dirt, sand, and / or grass. In some embodiments, the wear-based discoloration adjustments represented by each attribute channel of a sickle card function as texture masking characteristics that can be applied to the base texture image to render a composite texture image, which is then applied to the 3D surface topology network based on UV mapping of texels of the sickle image to vertices of the 3D surface topology network.The method may generate a scene description data file representing the rendering of the one or more surfaces and realize the simulation environment rendering the rendering of the one or more surfaces based at least on the scene description data file. For example, the method may include generating a surface structure for at least a portion of the simulation environment based at least on the 3D polygon topology network. In some embodiments, the resulting road surface rendering data may be used to generate scene description data and output the data as a data file, such as a Universal Scene Description (USD) file. The scene description data may be provided to a simulation platform as road surface rendering data to generate a scene that includes a simulated environment in which roads within the scene include drivable surfaces with textured appearances that include wear-based visual artifacts, as discussed herein. In some embodiments, the scene description data may be provided as input directly to the simulation platform. The scene description data may be used by the simulation platform to generate a visual rendering of a scene and / or physical simulations of interactions between rigid bodies.In some embodiments, textured renderings of the one or more drivable road surfaces may be rendered and used in a simulation environment to generate synthetic sensor data. For example, the simulation platform may process the simulation environment to generate synthetic image data for one or more cameras or other virtualized image sensors of an ego vehicle that uses the simulation environment as a simulated driving environment for training and / or testing components of the ego vehicle. The method may include collecting (e.g., storing) the rendering in a dataset of renderings of a plurality of surfaces and training or updating a machine learning model for operating the ego vehicle based on the dataset of renderings. The renderings of the one or more drivable road surfaces include visual artifacts of wear and tear resulting in more realistic road surface representations for viewing via a display device by humans and more realistic road surface representations for training machine learning models.In some embodiments, the systems and methods described herein may be performed within or in connection with a simulation environment (e.g., DriveSIM from NVIDIA) using simulated data (e.g., simulated sensor data from simulated virtual or simulated machine sensors). For example, simulated sensor data and / or map data may be used that includes application of realistic road surface representations to road surfaces within the simulation environment, and this information may be used to perform operations (e.g., navigating) associated with the virtual machine within the environment. These simulated operations may be used to test the performance of the underlying algorithms, systems, and / or methods before being deployed in the real world. In some cases, the simulation may be used to generate synthetic training data - e.g., training data that includes regions of interest and / or subregions of interest from within the simulation. The synthetic training data (additionally or alternatively to real world data) may then be processed to determine geometry and / or other information related to road surfaces, for example. In any example, such as when a simulation environment is used for testing, validating, training, etc., the simulation environment and / or associated training data may be rendered or otherwise generated using one or more light transport algorithms, such as ray tracing and / or path tracing algorithms. In some embodiments, the simulation environment and / or one or more objects, features, or components thereof may be generated or managed within a three-dimensional (3D) content work platform (e.g., OMNIVERSSE from NVIDIA) for industrial digitalization, generative physical AI, and / or other use cases, applications, or services. For example, the content collaboration platform or system may include a system for using or developing Universal Scene Descriptor (USD) (e.g., OpenUSD) data for managing objects, features, scenes, etc. within a simulated environment, digital environment, etc. The platform may include a real physics simulation, such as using NVIDIA's PhysX SDK to simulate real physics and physical interactions with simulations hosted by the platform. The platform may integrate OpenUSD along with ray tracing / path tracing / light transport simulation (e.g., RTX rendering technologies from NVIDIA) into tools and simulation workflows for building, training, deploying, or testing AI systems, such as systems for testing, validating, training (e.g., machine learning models, neural networks, etc.), and / or other tasks related to automotive, robotic, machine, or other applications.The systems and methods described herein may be used for a variety of purposes, including, but not limited to, machine control, machine travel, machine driving, synthetic data generation, model training, perception, augmented reality, virtual reality, mixed reality, robotics, safety and monitoring, simulation and digital twinning, autonomous or semi-autonomous machine applications, deep learning, environmental simulation, object or actor simulation, and / or digital twinning, data center processing, conversational AI, light transport simulation (e.g., ray tracing, path tracing, etc.), collaborative content creation for 3D assets, Cloud computing and / or any other suitable applications. Further, the systems and methods described herein may be used by, without limitation, non-autonomous vehicles, semi-autonomous vehicles (e.g., in one or more adaptive driver assistance systems (ADAS)), controlled and non-controlled robots or robotic platforms, storage vehicles, off-road vehicles, vehicles coupled to one or more trailers, airships, boats, shuttles, emergency vehicles, motorcycle, electric or motorized bicycles, aircraft, construction vehicles, trains, subsea vehicles, remote controlled vehicles such as drones, and / or other types of vehicles.The disclosed embodiments may be included in a variety of different systems, such as automotive systems (e.g., an autonomous or semi-autonomous machine control system, an autonomous or semi-autonomous machine perception system), systems implemented using a robot, air systems, media systems, boat systems, smart area monitoring systems, systems for performing deep learning operations, systems for performing simulation operations, systems for performing digital twining operations, systems implemented using an edge device, systems including one or more virtual machines (VMs), systems for performing synthetic data generation operations, systems at least partially implemented in a data center, Systems for performing conversational AI operations, systems implementing one or more language models, such as one or more big language models (LLMs) and / or one or more vision language models (VLMs), systems for performing light transport simulation, systems for performing collaborative content creation for 3D assets, systems implemented at least in part using cloud computing resources, and / or other types of systems.Example Simulation SystemIn some embodiments, the road surface rendering data 142 and / or the runtime simulation output 180 may be used as a source of virtual sensor data in a simulated environment to test one or more autonomous or semi-autonomous driving software stacks. For example, the simulation system 600 may generate a global simulation, e.g., as illustrated by the simulation systems 600A, 600B, 600C, and 600D in FIGS. 6A-D, and described in more detail below, that simulates a virtual world or environment (e.g., a simulated environment), which may include artificial intelligence (AI) vehicles or other objects (e.g., pedestrians, animals, etc.), hardware in the loop (HIL) vehicles or other objects, software in the loop (SIL) vehicles or other objects, and / or person in the loop (PIL) vehicles or other objects. The driving environment simulation platform 100 may be implemented based at least in part on the simulation system 600. The global simulation may be managed within an engine (e.g., a game engine) or other software development environment, which may include a rendering engine (e.g., for 2D and / or 3D graphics), a physics engine (e.g., for collision detection, collision response, etc.), sound, script, animation, AI, networking, streaming, memory management, threading, localization support, scene graphics, kinetics, and / or other features. In some examples, as described herein, one or more vehicles or objects within the simulation system 600 (e.g., HIL objects, SIL objects, PIL objects, AI objects, etc.) may be managed within its own instance of the engine. In such examples, a virtual sensor for the respective virtual object may have its own instance of the engine (e.g., an instance for a virtual camera, a second instance for a virtual LiDAR sensor, a third instance for another virtual LiDAR sensor, etc.). Thus, an instance of the engine may be used to process sensor data for the respective virtual sensor with respect to the virtual sensor's perception of the global simulation. Thus, the virtual camera instance may be used to process image data with respect to the field of view of the virtual camera in the simulated environment. As another example, the virtual IMU sensor instance may be used to process IMU data (e.g., representative of the orientation) for the object in the simulated environment.Kl-controlled agents or other objects within the simulation may include pedestrians, animals, foreign vehicles, vehicles, and / or other object types. Agents executing within the simulated environment may be controlled using artificial intelligence (e.g., machine learning such as neural networks, rule-based control, a combination thereof, etc.) in a manner that simulates or emulates how corresponding objects would behave in the real world. In some examples, the rules or actions for agents may be learned from one or more HIL objects, SIL objects, and / or PIL objects. In an example where an agent in the simulated environment corresponds to a pedestrian, the bot may be trained to act like a pedestrian in any of a number of different situations or environments (e.g., walking, walking, jogging, being inattentive, at the phone, in rain, in snow, in a city, in a town area, in a rural community, etc.). Thus, when the simulated environment is used to test vehicle performance (e.g., for HIL or SIL embodiments), the bot (e.g., the pedestrian) may behave like a pedestrian in the real world (e.g., as an unobserved pedestrian during rain or dark conditions, not watching stop signs or traffic lights, etc.) to more accurately simulate an environment in the real world. This method may be used for any agent in the simulated environment, such as vehicles, cyclists, or motorcycle, whose agents may also be trained to behave like objects in the real world (e.g., slalom driving in traffic, swerving, lane change without blinking or sudden, unexpected braking, etc.).The AI objects that may be remote from the vehicle of interest (e.g., the ego vehicle in the simulated environment) may be represented in a simplified form, such as by a radial distance function or a list of points at known positions in a plane with associated current motion vectors. Thus, the AI objects can be modeled similarly as AI agents can be modeled in video game engines.HIL vehicles or objects may use hardware used in the physical vehicles or objects to support at least a portion of the control of the HIL vehicles or objects in the simulated environment. For example, a vehicle controlled in an HIL environment may use one or more SoCs 804 (FIG. 8C), CPU(s) 818, GPU(s) 820, etc. in a dataflow loop to control the vehicle in the simulated environment. In some examples, the hardware of the vehicles may be an NVIDIA DRIVE AGX Pegasus™ computing platform and / or an NVIDIA DRIVE PX Xavier™ computing platform. For example, the vehicle hardware (e.g., vehicle hardware 601) may include some or all of the components and / or functionality described in U.S. Non-Provisional Application No. 16 / 186,473, filed Nov. 9, 2018, which is hereby incorporated by reference in its entirety. In such examples, at least some of the control decisions may be generated using hardware configured to be installed in a real-world autonomous vehicle (e.g., vehicle 800) to execute at least a portion of a software stack(s) 603 (e.g., an autonomous driving software stack).SIL vehicles or objects may use software to simulate or emulate the hardware from the HIL vehicles or objects. For example, instead of using the actual hardware that may be configured for use in physical vehicles (e.g., vehicle 800), software, hardware, or a combination thereof may be used to simulate or emulate the actual hardware (e.g., simulate the SoC (SoCs) 804).PIL vehicles or objects may use one or more hardware components that enable a remote operator (e.g., a human, a robot, etc.) to control the PIL vehicle or object within the simulated environment. For example, a person or robot may control the PIL vehicle using a remote control system (e.g., including one or more pedals, a steering wheel, a VR system, etc.), such as the remote control system described in U.S. Non-Provisional Application No. 16 / 366,506, filed Mar. 27, 2019, and hereby incorporated by reference in its entirety. In some examples, the remote operator may control autonomous driving level 0, 1, or 2 virtual vehicles (e.g., according to Society of Automotive Engineers document J3016) using a VR headset and (a) CPU(s) (e.g., an X86 processor), (a) GPU(s), or a combination thereof. In other examples, the remote operator may control advanced Level 2, 3, or 4 AI-assisted vehicles modeled using one or more advanced SoC platforms. In some examples, the PIL vehicles or objects may be recorded and / or tracked, and the records and / or tracking data may be used to train or otherwise at least partially contribute to control of AI objects, such as those described herein.Referring now to FIG. 6A, FIG. 6A is an exemplary representation of a simulation system 600A, in accordance with some embodiments of the present disclosure. The simulation system 600A may generate a simulated environment 610 (e.g., a simulated driving environment, as discussed herein), which may include agents such as AI objects 612 (e.g., AI objects 612A and 612B), HIL objects 614, SIL objects 616, PIL objects 618, and / or other object types. The simulated environment 610 may include features of a driving environment, such as roads, bridges, tunnels, road signs, stop lights, pedestrian crossings, buildings, trees and foliage, sun, moon, reflections, shadows, etc., to accurately simulate a real-world environment within the simulated environment 610. In some examples, the driving environment features within the simulated environment 610 may be more life-fast by including chipping, color, graffiti, wear, damage, etc. Although described with respect to a driving environment, this is not intended to be limiting, and the simulated environment may include an interior environment (e.g., for a robot, drone, etc.), an air environment (e.g., for a UAV, drone, plane, etc.), a water environment (e.g., for a boat, ship, submarine, etc.), and / or another type of environment.The simulated environment 610 may be generated using virtual data, real world data, or a combination thereof. For example, the simulated environment may include real-world data that is augmented or altered using virtual data to generate combined data that may be used to simulate particular scenarios or situations with different and / or added items (e.g., additional AI objects, environmental features, weather conditions, etc.). For example, prerecorded video may be augmented or altered to include additional pedestrians, obstacles, and / or the like so that the virtual objects (e.g., executing the software stack(s) 603 as HIL objects and / or SIL objects) may be tested against variations in the real world data.The simulated environment may be generated using rastering, ray tracing, using DNNs such as generative adversarial networks (GANs), another rendering technique, and / or a combination thereof. For example, the simulation system 600A may use real-time ray tracing to generate more life-less, realistic lighting conditions (e.g., shadows, reflections, glare, global lighting, environmental occlusion, etc.). In one or more embodiments, one or more hardware accelerators may be used by the simulation system 600A to perform real-time ray tracing. Ray tracing can be used to simulate a LiDAR sensor to accurately generate LiDAR data. For example, ray casting may be used to simulate LiDAR reflectivity. In another example, virtual LiDAR data may be generated using a learned sensor model, as described in more detail above. In any example, ray tracing techniques used by simulation system 600A may include one or more techniques described in U.S. Provisional Patent Application No. 62 / 644,385, filed Mar. 17, 2018, U.S. Provisional Patent Application No. 62 / 644,386, filed Mar. 17, 2018, U.S. Provisional Patent Application No. 62 / 644,601, filed Mar. 19, 2018, and U.S. Provisional Application No. 62 / 644,806, filed Mar. 19, 2018, among others, U.S. Non-Provisional Patent Application No. 16 / 354,983, filed Mar. 15, 2019, and / or U.S. Non-Provisional Patent Application No. 16 / 355,214, filed Mar. 15, 2019, each of which is hereby incorporated by reference in its entirety.In some examples, a simulated environment as described herein (e.g., by the driving environment simulation platform 100) may be rendered, at least in part, using one or more DNNs such as generative adversarial neural networks (GANs). For example, real-world data may be collected, such as real-world data captured by autonomous vehicles (e.g., camera(s), LiDAR sensor(s), RADAR sensor(s), etc.), robots, and / or other objects, as well as real-world data captured by any sensors (e.g., images or video drawn from data stores, online resources such as search engines, etc.). The real world data may then be segmented, classified, and / or categorized, such as by identifying different portions of the real world data based on a class (e.g., for a landscape image, portions of the image, such as pixels or groups of pixels, may be identified as a car, headliner, tree, road, building, water, waterfall, vehicle, bus, truck, sedan, etc.). A GAN (or other machine learning DNN or model) may then be trained using the segmented, classified, and / or categorized data to generate new versions of the various types of objects, landscapes, and / or other features as graphics within the simulated environment.The simulator component(s) 602 of the simulation system 600 may / may communicate with the vehicle simulator component(s) 606 via a wired and / or wireless connection. In some examples, the connection may be a wired connection using one or more sensor switches 608, where the sensor switches may provide a low voltage differential signaling (LVDS) output. For example, the sensor data (e.g., image data) may be transmitted over an HDMI-to-LVDS connection between the simulator component(s) 602 and the vehicle simulator component(s) 606. Simulator component(s) 602 may include any number of compute nodes (e.g., computers, servers, etc.) that are interconnected to ensure synchronization of world state. In some examples, as described herein, communication between each of the compute nodes (e.g., the compute nodes of the vehicle simulator component(s) and the compute nodes of the simulator component(s)) may be managed by a distributed shared memory system (DSM) (e.g., DSM 624 of FIG. 6C ) using a distributed shared memory protocol (e.g., a coherency protocol). The DSM may include a combination of hardware (cache coherency circuits, network interfaces, etc.) and software. This shared memory architecture may separate memory into shared portions distributed between nodes and main memory, or distribute all memory between all nodes. In some examples, InfiniBand (IB) interfaces and associated communication standards may be used. For example, communication between different nodes of the simulation system 600 (and / or 700) may use IB.Simulator component(s) 602 may include one or more GPUs 604. The virtual vehicle being simulated may include any number of sensors (e.g., virtual or simulated sensors), which may correspond to one or more of the sensors described herein, at least with reference to FIGS. 8A-8C. Any or all of the sensors of simulator component(s) 602 may be implemented using a corresponding learned sensor model, as described in more detail above. In some examples, each sensor of the vehicle may correspond to or be hosted by one of the GPUs 604. For example, processing for a LiDAR sensor may be performed on a first GPU 604, processing for a wide-view camera may be performed on a second GPU 604, processing for a RADAR sensor may be performed on a third GPU, and so on. Thus, the processing of each sensor with respect to the simulated environment may be capable of being executed in parallel with each other sensor using a plurality of GPUs 604 to enable real-time simulation. In other examples, two or more sensors may correspond to or be hosted by one of the GPUs 604. In such examples, the two or more sensors may be processed by separate threads on the GPU 604 and may be processed in parallel. In other examples, processing for a single sensor may be distributed over more than one GPU. Additionally or alternatively to the GPU(s) 604, one or more TPUs, CPUs, and / or other processor types may be used to process the sensor data.The vehicle simulator component(s) 606 may include a compute node of the simulation system 600A that corresponds to a single vehicle represented in the simulated environment 610. Any other vehicle (e.g., 614, 618, 616, etc.) may include a respective node of the simulation system. As a result, the simulation system 600A may be scalable to any number of vehicles or objects, as each vehicle or object may be hosted by or managed by its own node in the system 600A. In the illustration of FIG. 6A, the vehicle simulator component(s) 606 may correspond to a HIL vehicle (e.g., because vehicle hardware 601 is used). However, this is not intended to be limiting, and as shown in FIGS. 6B and 6C, the simulation system 600 may include SIL vehicles, HIL vehicles, PIL vehicles, and / or AI vehicles. Simulator component(s) 602 (e.g., simulator host facility) may include one or more compute nodes of simulation system 600A, and may / may host the simulation of the environment with respect to each actor (e.g., with respect to each HIL, SIL, PIL, and AI actor), as well as the rendering and management of the environment or world condition (e.g., road, signs, trees, foliage, sky, sun, lighting, etc.). In some examples, simulator component(s) 602 may include one or more servers and associated components (e.g., CPU(s), GPU(s), computers, etc.) that may host a simulator (e.g., NVIDIA's DRIVE™ Constellation AV Simulator).The vehicle hardware 601 as described herein may correspond to the vehicle hardware that may be used in a physical vehicle 800. However, in the simulation system 600A, the vehicle hardware 601 may be integrated into the vehicle simulator component(s) 606. As such, because the vehicle hardware 601 may be configured for installation in the vehicle 800, the simulation system 600A may be specifically configured to use the vehicle hardware 601 in a node (e.g., a server platform) of the simulation system 600A. For example, similar interfaces used in the physical vehicle 800 may need to be used by the vehicle simulator component(s) 606 to communicate with the vehicle hardware 601. In some examples, the interfaces may include: (1) CAN interfaces including a PCAN adapter, (2) Ethernet interfaces including RAW UDP sockets with IP address, source, VLA, and / or source IP, all maintained, (3) serial interfaces with a USB to serial adapter, (4) camera interfaces, (5) InfiniBand (IB) interfaces, and / or other interface types.In examples, once the sensor data representative of (a) field of view / fields of view of the vehicle's sensor / sensors in the simulated environment has been generated and / or processed (e.g., using one or more codecs as described herein), the sensor data (and / or encoded sensor data) from the software stack(s) 603 (e.g., the autonomous driving software stack) executing on the vehicle hardware 601 may be used to perform one or more operations (e.g., generating one or more controllers, routing, detecting objects, identifying drivable free space, monitoring the environment for obstacle avoidance, etc.). As a result, the identical or substantially identical hardware components used by the vehicle 800 (e.g., a physical vehicle) to execute the autonomous driving software stack in real-world environments may be used to execute the autonomous driving software stack in the simulated environment 610. Use of the vehicle hardware 601 in the simulation system 600A thus provides a more accurate simulation of how the vehicle 800 will function in real-world situations, scenarios, and environments without actually having to locate and test the vehicle 800 in the real-world. This may reduce the amount of travel time required to test the hardware / software combination used in the physical vehicle 800 and may reduce safety risks by not requiring actual real-world tests (particularly for dangerous situations such as other vehicles traveling irregularly or at unsafe speeds, children playing on the road, ice on a bridge, etc.).In addition to the vehicle hardware 601, the vehicle simulator component(s) 606 may manage the simulation of the vehicle (or other object) using additional hardware, such as a computer-e.g., an X86 box. In some examples, additional processing may be performed for virtual sensors (e.g., learned sensor models) of the virtual object using vehicle simulation component(s) 606. In such examples, at least a portion of the processing may be performed by simulator component(s) 602, and another portion of the processing may be performed by vehicle simulator component(s) 606 (or 620 or 622, as described herein). In other examples, the virtual sensor processing may be performed entirely on the vehicle simulator component(s) 606.Referring now to FIG. 6B, FIG. 6B is another example illustration of a simulation system 600B, in accordance with some embodiments of the present disclosure. The simulation system 600B may include the simulator component(s) 602 (as one or more compute nodes), the vehicle simulator component(s) 606 (as one or more compute nodes) for an HIL object(s), the vehicle simulator component(s) 620 (as one or more compute nodes) for an SIL object(s), the vehicle simulator component(s) 606 (as one or more compute nodes) for a PIL object(s), and / or additional component(s) (or compute nodes) for AI objects and / or other object types. Each of the PIL, HIL, SIL, Kl compute nodes and / or compute nodes of a different object type may communicate with the simulator component(s) 602 to acquire, from the global simulation, at least data corresponding to the respective object within the simulated environment 610.For example, the vehicle simulator component(s) 622 may receive (e.g., retrieve, obtain, etc.) data corresponding to, are associated with, and / or needed by the vehicle simulator component(s) 622 to perform one or more operations by the vehicle simulator component(s) 622 for the PIL object from the global simulation (e.g., represented by the simulated environment 610) hosted by the simulator component(s) 602. In such an example, data (e.g., virtual sensor data corresponding to a field of view(s) of virtual camera(s) of the virtual vehicle, virtual LiDAR data, virtual RADAR data, virtual position data, virtual IMU data, etc.) corresponding to the respective sensor of the PIL object may be received by the simulator component(s) 602. This data may be used to generate an instance of the simulated environment corresponding to the field of view of a remote virtual vehicle operator controlled by the remote operator, and the portion of the simulated environment may be projected onto a display (e.g., a display of a VR headset, a computer or television display, etc.) to assist the remote operator in controlling the virtual vehicle through the simulated environment 610. The controls generated or input by the remote operator using the vehicle simulator component(s) 622 may be transmitted to the simulator component(s) 602 to update a state of the virtual vehicle within the simulated environment 610.As another example, the vehicle simulator component(s) 620 may receive (e.g., retrieve, obtain, etc.) data corresponding to, are associated with, and / or needed by the vehicle simulator component(s) 620 from the global simulation hosted by the simulator component(s) 602, to perform one or more operations by the vehicle simulator component(s) 620 for the SIL object. In such an example, data (e.g., virtual sensor data corresponding to a field of view(s) of virtual camera(s) of the virtual vehicle, virtual LiDAR data, virtual RADAR data, virtual position data, virtual IMU data, etc.) corresponding to the respective sensor of the SIL object may be received by the simulator component(s) 602. This data may be used to generate an instance of the simulated environment for each sensor (e.g., a first instance of a field of view of a first virtual camera of the virtual vehicle, a second instance of a field of view of a second virtual camera, a third instance of a field of view of a virtual LiDAR sensor, etc.). The instances of the simulated environment may thus be used to generate sensor data for each sensor by the vehicle simulator component(s) 620. In some examples, the sensor data may be encoded using one or more codecs (e.g., each sensor may use its own codec or each sensor type may use its own codec) to generate encoded sensor data that may be understood or trusted by an autonomous driving software stack simulated or emulated by the vehicle simulator component(s) 620. For example, a first vehicle manufacturer may use a first type of LiDAR data, a second vehicle manufacturer may use a second type of LiDAR data, etc., and thus the codecs may adapt the sensor data to the types of sensor data used by the manufacturers. As a result, the simulation system 600 may be universal, customizable, and / or usable by any number of different sensor types, depending on the types of sensors and the corresponding data types used by different manufacturers. In any example, the sensor data and / or encoded sensor data may be used by an autonomous driving software stack to perform one or more operations (e.g., object detection, path planning, control determinations, actuation types, etc.). For example, the sensor data and / or encoded data may be used as inputs to one or more DNNs of the autonomous driving software stack and the outputs of the one or more DNNs may be used to update a state of the virtual vehicle within the simulated environment 610. Thus, the reliability and effectiveness of the autonomous driving software stack, including one or more DNNs, may be tested, fine tuned, verified, and / or validated within the simulated environment.In yet another example, the vehicle simulator component(s) 606 may receive (e.g., retrieve, obtain, etc.) data corresponding to, are associated with, and / or needed by the vehicle simulator component(s) 606 from the global simulation hosted by the simulator component(s) 602 to perform one or more operations by the vehicle simulator component(s) 606 for the HIL object. In such an example, data (e.g., virtual sensor data corresponding to a field of view(s) of virtual camera(s) of the virtual vehicle, virtual LiDAR data, virtual RADAR data, virtual position data, virtual IMU data, etc.) corresponding to the respective sensor of the HIL object may be received by the simulator component(s) 602. This data may be used to generate an instance of the simulated environment for each sensor (e.g., a first instance of a field of view of a first virtual camera of the virtual vehicle, a second instance of a field of view of a second virtual camera, a third instance of a field of view of a virtual LiDAR sensor, etc.). The instances of the simulated environment may thus be used to generate sensor data for each sensor by the vehicle simulator component(s) 620 (e.g., using a corresponding learned sensor model). In some examples, the sensor data may be encoded using one or more codecs (e.g., each sensor may use its own codec or each sensor type may use its own codec) to generate encoded sensor data that may be understood or familiar by an autonomous driving software stack executing on the vehicle hardware 601 of the vehicle simulator component(s) 620. Similar to the SIL object described herein, the sensor data and / or encoded sensor data may be used by an autonomous driving software stack to perform one or more operations (e.g., object detection, path planning, control determinations, actuation types, etc.).Referring now to FIG. 6C, FIG. 6C is another example illustration of a simulation system 600C, in accordance with some embodiments of the present disclosure. The simulation system 600C may include a distributed shared memory (DSM) system 624, the simulator component(s) 602 (as one or more compute nodes), the vehicle simulator component(s) 606 (as one or more compute nodes) for (one) HIL object(s), the vehicle simulator component(s) 620 (as one or more compute nodes) for (one) SIL object(s), the vehicle simulator component(s) 606 (as one or more compute nodes) for (one) PIL object(s), and / or additional component(s) (or compute nodes) for AI objects and / or other object types (not shown). The simulation system 600C may include any number of HIL objects (e.g., each has its own vehicle simulator component(s) 606), any number of SIL objects (e.g., each has its own vehicle simulator component(s) 620), any number of PIL objects (e.g., each has its own vehicle simulator component(s) 622), and / or any number of AI objects (not shown, but may be hosted by the simulation component(s) 602 and / or separate compute nodes, depending on the embodiment).The vehicle simulator component(s) 606 may include one or more SoC (SoCs) 605 (or other components) that may be configured for installation and use in a physical vehicle. Thus, as described herein, the simulation system 600C may be configured to use the SoC (SoCs) 605 and / or other vehicle hardware 601 by using specific interfaces to communicate with the SoC (SoCs) 605 and / or other vehicle hardware. The vehicle simulator component(s) 620 may include one or more software instances 630 that may be hosted on one or more GPUs and / or CPUs to simulate or emulate the SoC (SoCs) 605. The vehicle simulator component(s) 622 may include one or more SoC (SoCs) 626, one or more CPU(s) 628 (e.g., X86 boxes), and / or a combination thereof in addition to the component(s) that may be used by the remote operator (e.g., keyboard, mouse, joystick, monitors, VR systems, steering wheel, pedals, in-vehicle components such as light switches, flashers, HMI display(s), etc., and / or other component(s)).The simulation component(s) 602 may include any number of CPU(s) 632 (e.g., X86 boxes), GPU(s), and / or a combination thereof. The CPU(s) 632 may host the simulation software to manage the global simulation, and the GPU(s) 634 may be used for rendering, physics, and / or other functionality to generate the simulated environment 610.As described herein, the simulation system 600C may include the DSM 624. The DSM 624 may use one or more distributed shared memory protocols to manage the state of the global simulation using the state of each of the objects (e.g., HIL objects, SIL objects, PIL objects, KI objects, etc.). Thus, each of the compute nodes corresponding to the vehicle simulator component(s) 606, 620, and / or 622 may be in communication with the simulation component(s) 602 via the DSM 624. By using the DSM 624 and the associated protocols, real-time simulation may be possible. For example, in contrast to how network protocols (e.g., TCP, UDP, etc.) are used in massive multi-player online (MMO) games, the simulation system 600 may use a distributed shared memory protocol to manage the state of the global simulation and each instance of the simulation (e.g., of each vehicle, object, and / or sensor) in real-time.Referring now to FIG. 6D, FIG. 6D is an example illustration of a hardware in the loop configuration in accordance with some embodiments of the present disclosure. The vehicle simulator component(s) 606 may include vehicle hardware 601 as described herein, and may include one or more computer(s) 636, one or more GPU(s) (not shown), and / or one or more CPU(s) (not shown). The computer(s) 636, the GPU(s), and / or the CPU(s) may manage or host the simulation software 638 or an instance thereof executing on the vehicle simulator component(s) 606. The vehicle hardware 601 may execute the software stack(s) 603 (e.g., an autonomous driving software stack, an IX software stack, etc.).As described herein, the other vehicle simulator component(s) 606 in the simulation environment 600 may need to be configured by using the vehicle hardware 601 to communicate with the vehicle hardware 601. For example, because the vehicle hardware 601 may be configured for installation in a physical vehicle (e.g., the vehicle 800), the vehicle hardware 601 may be configured to communicate via one or more connection types and / or communication protocols that are not standard in computing environments (e.g., server-based platforms, general purpose computers, etc.). For example, a CAN interface, LVDS interface, USB interface, Ethernet interface, InfiniBand (IB) interface, and / or other interfaces may be used by the vehicle hardware 601 to exchange signals with other components of the physical vehicle. Therefore, the vehicle simulator component(s) 606 (and / or other component(s) of the simulation system 600 must be configured as such for use with the vehicle hardware 601, in addition or alternatively to the vehicle simulator component(s) 606) in the simulation system 600. To achieve this, one or more CAN interfaces, LVDS interfaces, USB interfaces, Ethernet interfaces, and / or other interfaces may be used to provide communication (e.g., via one or more communication protocols, such as LVDS) between the vehicle hardware 601 and the other component(s) of the simulation system 600.In some examples, the virtual vehicle, which may correspond to the vehicle simulator component(s) 606 within the simulation system 600, may be modeled as a game object within an instance of a game engine. Additionally, each of the virtual vehicle sensors may be interfaced using sockets within the virtual vehicle software stack(s) 603 executing on the vehicle hardware 601. In some examples, each of the virtual sensors of the virtual vehicle may include an instance of the game engine in addition to the instance of the game engine associated with the virtual vehicle simulation software 638. In examples where the vehicle simulator component(s) 606 include a plurality of GPUs, each of the sensors may be executed on a single GPU. In other examples, multiple sensors or at least as many sensors as possible may be executed on a single GPU to ensure real-time generation of the virtual sensor data.The use of HIL objects in simulator system 600 may provide a scalable solution that may simulate or emulate various driving conditions for autonomous software and hardware systems (e.g., DRIVE AGX Pegasus™ computing platform from NVIDIA and / or DRIVE PX Xavier™ computing platform). Some advantages of HIL objects may include the ability to test DNNs faster than in real-time, the ability to scale verification with computing resources (e.g., instead of vehicles or test stretches), the ability to perform deterministic regression tests (e.g., the real-world environment is never twice the same, but which is the case with a simulated environment), an optimal ground truth label (e.g., no hand label required), the ability to test scenarios difficult to produce in the real-world, a fast generation of test permutations, and the ability to test a larger space of permutations in the simulation compared to the real-world.Referring now to FIG. 6E, FIG. 6E is an exemplary illustration of a hardware in the loop configuration in accordance with some embodiments of the present disclosure. The HIL configuration of FIG. 6E may include vehicle simulator component(s) 606 including SoC (SoCs) 605, one / more chassis fans 656, and / or a water cooling system. The HIL configuration may include a two-box solution (e.g., simulator component(s) 602 in a first box and vehicle simulator component(s) 606 in a second box). Using this approach may reduce the amount of space the system occupies, as well as reduce the number of external cables in data centers (e.g., by having multiple components along with the SoC(SoCs) 605 in the vehicle simulator component(s) 606 - e.g., the first box). The vehicle simulator component(s) 606 may include one or more GPUs 652 (e.g., NVIDIA QUADRO GPU(s)), which in an example non-limiting embodiment may provide 8 DP / HDMI video streams that may be synchronized using sync component(s) 654 (e.g., by a QUADRO Sync II card). These GPU(s) 652 (and / or other GPU types) may provide the sensor input to the SoC(SoCs) 605 (e.g., to the vehicle hardware 601). In some examples, the vehicle simulator component(s) 606 may include a network interface (e.g., one or more network interface cards (NICs) 650) that may simulate or emulate RADAR sensors, LiDAR sensors, and / or IMU sensors (e.g., by providing 8 gigabit ports with precision time protocol (PTP) support). Additionally, the vehicle simulator component(s) 606 may include analog input / output (I / O) integrated circuit 657. Registered Jack (RJ) interfaces (e.g., RJ45), high speed data (HSD) interfaces, USB interfaces, Pulse-Per-Second (PPS) clocks, Ethernet (e.g., 10 Gb Ethernet (GbE)) interfaces, CAN interfaces, HDMI interfaces, and / or other interface types may be used to effectively transfer and communicate data between and among the various component(s) of the system.Referring now to FIG. 6F, FIG. 6F is an exemplary illustration of a software in the loop configuration in accordance with some embodiments of the present disclosure. The vehicle simulator component(s) 620 may include computer(s) 640, GPU(s) (not shown), CPU(s) (not shown), and / or other components. The computer(s) 640, the GPU(s), and / or the CPU(s) may manage or host the simulation software 638 or an instance thereof executing on the vehicle simulator component(s) 620, and may host the software stack(s) 603. For example, the vehicle simulator component(s) 620 may simulate or emulate the vehicle hardware 601 using software to execute the software stack(s) 603 as accurately as possible.To increase accuracy in SIL embodiments, the vehicle simulator component(s) 620 may be configured to communicate via one or more virtual connection types and / or communication protocols that are not standard in computing environments. For example, a CAN virtual interface, an LVDS virtual interface, a USB virtual interface, an Ethernet virtual interface, and / or other virtual interfaces may be used by the computer(s) 640, the CPU(s), and / or the GPU(s) of the vehicle simulator component(s) 620 to provide communication (e.g., via one or more communication protocols, such as LVDS) between the software stack(s) 603 and the simulation software 638 within the simulation system 600. For example, the virtual interfaces may include middleware that may be used to provide a continuous feedback loop with the software stack(s) 603. Thus, the virtual interfaces may simulate or emulate communications between the vehicle hardware 601 and the physical vehicle using one or more software protocols, hardware (e.g., CPU(s), GPU(s), computer(s) 640, etc.), or a combination thereof.The computer / computers 640 may include X86 CPU hardware in some examples, and one or more X86 CPUs may execute both the simulation software 638 and the software stack(s) 603. In other examples, the computer / computers 640 may include GPU hardware (e.g., an NVIDIA DGX system and / or cloud-based NVIDIA Tesla server).In some examples, the virtual vehicle, which may correspond to the vehicle simulator component(s) 620 within the simulation system 600, may be modeled as a game object within an instance of a game engine. Additionally, each of the virtual vehicle sensors may be interfaced using sockets within the virtual vehicle software stack(s) 603 executing on the vehicle simulator component(s) 620. In some examples, each of the virtual sensors of the virtual vehicle may include an instance of the game engine in addition to the instance of the game engine associated with the virtual vehicle simulation software 638. In examples where the vehicle simulator component(s) 606 include a plurality of GPUs, each of the sensors may be executed on a single GPU. In other examples, multiple sensors or at least as many sensors as possible may be executed on a single GPU to ensure real-time generation of the virtual sensor data.Referring now to FIG. 7A, FIG. 7A is an example illustration of a simulation system 700 at runtime in accordance with some embodiments of the present disclosure (e.g., driving environment simulation platform 100). Some or all of the components of the simulation system 700 may be used in the simulation system 600, and some or all of the components of the simulation system 600 may be used in the simulation system 700. Thus, components, features, and / or functionality described with respect to the simulation system 600 may be associated with the simulation system 700, and vice versa. Additionally, each of the simulation systems 700A and 700B (FIG. 7B ) may include similar and / or shared components, features, and / or functionality.The simulation system 700A (e.g., illustrating an example of the simulation system 700) may include simulator component(s) 602, codec(s) 714, content data storage 702, scenario data storage 704, vehicle simulator component(s) 620 (e.g., for an SIL object), and vehicle simulator component(s) 606 (e.g., for an HIL object). The content data store or stores 702 may include detailed content information for modeling cars, trucks, people, cyclists, signs, buildings, trees, curbs, and / or other features of the simulated environment. The scenario datastore 704 may / may include scenario information that may include dangerous scenario information (e.g., that is uncertain to be tested in the real world environment), such as a child in an intersection.Simulator component(s) 602 may include an AI engine 708 that simulates traffic, pedestrians, weather, and / or other AI features of the simulated environment. Simulator component(s) 602 may include virtual world manager 710 that manages the world state for global simulation. Simulator component(s) 602 may further include a virtual sensor manager 712, which may manage the virtual sensors (any or all of which may be implemented using a corresponding learned sensor model). The AI engine 708 may model traffic similar to how traffic is modeled in an automotive video game, and may be executed using a game engine as described herein. In other examples, a customized AI may be used to provide the determination and computational level of details required for large-scale reproducible automobile simulation. In some examples, traffic may be modeled using SIL objects, HIL objects, PIL objects, KI objects, and / or a combination thereof. The system 700 may create a subclass of AI control, examine map data, calculate a route, and drive the route while avoiding other cars. The AI controller may calculate the desired steering, acceleration, and / or braking and may apply these values to the virtual objects. The vehicle characteristics used may include mass, max U / min, torque curves, and / or other characteristics. A physics engine may be used to determine states of AI objects. As described herein, for vehicles or other objects that may be far away and have no influence on a current sensor(s), the system may decide not to apply physics to these objects and only determine positions and / or current motion vectors. Ray casting may be used for each wheel to ensure that the wheels of the vehicles are in contact. In some examples, the traffic AI may operate according to a script (e.g., rule-based traffic). Traffic AI maneuvers for virtual objects may include lateral lane changes (e.g., direction, distance, duration, shape, etc.), longitudinal motion (e.g., adjusted speed, relative destination, delta to destination, absolute value), route tracking, and / or path tracking. The triggers for the traffic AI maneuvers may be time-based (e.g., after three seconds), speed-based (e.g., at sixty mph), proximity-based with respect to a map (e.g., within twenty feet of an intersection), proximity-based with respect to an actor (e.g., within twenty feet of another object), clear lane, and / or others.The AI engine 708 may model a pedestrian AI similar to the traffic AI described herein, but for pedestrians. Pedestrians may be modeled similar to real pedestrians, and system 700 may derive pedestrian behavior based on learned behaviors.Simulator component(s) 602 may be used to adjust the time of day such that street lights are turned on and off, headlights are turned on and off, shadows, glares, and / or sunset are accounted for, etc. In some examples, only lights within a threshold distance to the virtual object may be accounted for to increase efficiency.Weather may be accounted for by simulator component(s) 602 (e.g., virtual world manager 710). The weather may be used to update the coefficients of friction for the driving surfaces and temperature information may be used to update tire interaction with the driving surfaces. Where rain or snow is present, the system 700 may generate nets to describe where rainwater and snow may accumulate based on the structure of the scene, and the nets may be used when rain or snow is present in the simulation.In some examples, as described herein, at least a portion of simulator component(s) 602 may alternatively be included in vehicle simulator component(s) 620 and / or 606. For example, the vehicle simulator component(s) 620 and / or the vehicle simulator component(s) 606 may include the virtual sensor manager 712 to manage each of the sensors of the associated virtual object. Additionally, one or more of the codecs 714 may be included in the vehicle simulator component(s) 620 and / or the vehicle simulator component(s) 606. In such examples, the virtual sensor manager 712 may generate sensor data corresponding to a sensor of the virtual object (e.g., using a learned sensor model), and the sensor data may be used by the sensor emulator 716 of the codec(s) 714 to encode the sensor data according to the sensor data format or type used by the software stack(s) 603 (e.g., the software stack(s) 603 executing on the vehicle simulator component(s) 620 and / or the vehicle simulator component(s) 606).Codec(s) 714 may / may provide an interface to software stack(s) 603. Codec(s) 714 (and / or other codec(s) described herein) may / may include an encoder / decoder framework. Codec(s) 714 / may include CAN steering, throttle requests, and / or may be used to send sensor data to software stack(s) 603 in SIL and HIL embodiments. Codec(s) 714 may / may be advantageous for the simulation systems (e.g., 600 and 700) described herein. For example, when data is generated from the driving environment simulation platform 100 and the simulation systems 600 and 700, the data may be transmitted to the software stack(s) 603, so that the following standards may be satisfied. The data may be transmitted to the software stack(s) 603 such that minimal impact is introduced on the software stack(s) 603 and / or the vehicle hardware 601 (in HIL embodiments). This may result in more accurate simulations, as the software stack(s) 603 and / or the vehicle hardware 601 may be operated in an environment very similar to use in a real world environment. The data may be transmitted to the software stack(s) 603, such that the simulator and / or resimulator may be independent of the actual hardware configuration of the system under test. This may reduce development effort due to errors or separate code paths depending on the simulation configuration. The data may be transmitted to the software stack(s) 603 such that the data may match (e.g., bit by bit) the data sent from a physical sensor of a physical vehicle (e.g., vehicle 800). The data can be efficiently transmitted in both SIL and HIL embodiments.The sensor emulator 716 may emulate at least cameras, LiDAR sensors, and / or RADAR sensors, some or all of which may be implemented using a corresponding learned sensor model. Use of a learned sensor model may avoid the need to model the sensor using ray tracing, although in some embodiments ray tracing may additionally or alternatively be used. With respect to LiDAR sensors, some LiDAR sensors report tracked objects. Thus, for each image represented by the virtual sensor data, the simulator component(s) 602 may generate a list of all tracked objects (e.g., trees, vehicles, pedestrians, foliage, etc.) within the range of the virtual object with the virtual LiDAR sensors and may cast virtual beams toward the tracked objects. If a significant number of rays are incident on a tracked object, that object can be added to the LiDAR data report. In some examples, the LiDAR sensors may be modeled using simple ray casting without reflection, adjustable field of view, adjustable noise, and / or adjustable dropouts. LiDAR with moving parts, limited fields of view, and / or variable resolutions may be simulated. For example, the LiDAR sensors may be modeled as solid state LiDAR and / or as Optix-based LiDAR. In examples, the beams may be reflected from water, reflective materials, and / or windows using Optix-based LiDAR. A texture may be assigned to roads, signs, and / or vehicles to model laser reflection at the wavelengths corresponding to the textures. RADAR may be implemented similar to LiDAR. As described herein, RADAR and / or LiDAR may be simulated using learned sensors, ray tracing techniques, and / or otherwise.In some examples, the vehicle simulator component(s) 606, 620, and / or 622 may include a feedback loop with the simulator component(s) 602 (and / or the component(s) that generate the virtual sensor data). The feedback loop may be used to provide information for updating the acquisition or generation of virtual sensor data. For example, the feedback loop for virtual cameras may be based on sensor feedback, such as changes in exposure in response to lighting conditions (e.g., increase in exposure at weak lighting conditions so that the image data may be properly processed by the DNNs). As another example, the feedback loop for virtual LiDAR sensors may be representative of changes in energy level (e.g., to increase energy to generate more useful or accurate LiDAR data).GNNS sensors (e.g., GPS sensors) may be simulated within the simulation space to generate real-world coordinates. Noise functions can be used to approximate inaccuracies. As with any virtual sensors described herein, the virtual sensor data may be generated using a learned sensor model or otherwise and transmitted to the software stack(s) 603 using codec(s) 714 to be converted to a bit-by-bit correct signal (e.g., corresponding exactly to the signals generated by the physical sensors of the physical vehicles).One or more plug-in application programming interfaces (APIs) 706 may be used. The plugin APIs 706 may include first-party and / or third-party plugins. For example, third party providers may adjust the simulation system 700B using their own plug-in APIs 706 to provide customized information such as performance times, suspension dynamics, tire dynamics, etc.The plug-in APIs 706 may include one or more ego dynamic components (not shown) that may receive information from the simulator component(s) 602, including position, speed, auto state, and / or other information, and may provide information to the simulator component(s) 602, including performance times, suspension dynamics, tire dynamics, and / or other information. For example, simulator component(s) 602 may provide CAN throttle, steering, and driving surface information to ego dynamic component(s). In some examples, the ego dynamic component(s) may include a standardized vehicle dynamic package (e.g., IPG CARMAKER or VIRTUAL TEST DRIVE), while in other examples, the ego dynamic component(s) may be adjusted and / or received (e.g., from a first party provider and / or a third party provider).The plugin APIs 706 may include a Key Performance Indicator (KPI) API. The KPI API may receive CAN data, ground truth, and / or virtual object state information (e.g., from the software stack(s) 603) from the simulator component(s) 602, and may generate and / or provide a report (in real-time) that includes KPI's and / or commands to store state, restore state, and / or apply changes.Referring now to FIG. 7B, FIG. 7B includes a cloud-based architecture for a simulation system 700B, in accordance with some embodiments of the present disclosure. The simulation system 700B may be at least partially located in the cloud and may communicate over one or more networks, such as, but not limited to, those described herein (e.g., with respect to the network 890 of FIG. 8D ), with one or more GPU platforms 724 (which may include, e.g., GPUs, CPUs, TPUS, and / or other processor types) and / or one or more HIL platforms 726 (which may include, e.g., some or all of the components of the / the vehicle simulator component(s) 606 described herein).A simulated environment 728 (e.g., which may be similar to the simulated environment 610 described herein) may be modeled by interconnected components including a simulation engine 730, an AI engine 732, a global illumination (GI) engine 734, an asset data store (stores) 736, and / or other components. In some examples, this component(s) may be used to model a simulated environment (e.g., a virtual world) in a virtualized interactive platform (e.g., similar to a massive multi-player online (MMO) gaming environment). The simulated environment may further include physics, traffic simulation, weather simulation, and / or other features and simulations for the simulated environment. The GI engine 734 may compute the GI once and share the computation at each of the nodes 718( 1)- 718(N) and 720( 1)- 720(N) (e.g., the computation of GI may be view independent). The simulated environment 728 may include an AI universum 722 that provides data to the GPU platforms 724 (e.g., GPU servers), which may create renderings for each sensor of the vehicle (e.g., at the virtual sensor / codec(s) 718 for a first virtual object and at the virtual sensor / codec(s) 720 for a second virtual object). For example, the GPU platform 724 may receive data about the simulated environment 728 and may generate sensor inputs for each of 718( 1)- 718(N), 720( 1)- 720(N) and / or virtual sensor / codec pairs corresponding to other virtual objects (depending on the embodiment). In examples where the virtual objects are simulated using HIL objects, the sensor inputs may be provided to the vehicle hardware 601, which may use the software stack(s) 603 to perform one or more operations and / or generate one or more commands, such as those described herein. In some examples, as described herein, the virtual sensor data from each of the virtual sensors may be encoded using a codec before being used by (or transmitted to) the software stack(s) 603. Additionally, in some examples, each of the sensors may execute on its own GPU within the GPU platform 724, while in other examples, two or more sensors may share the same GPU within the GPU platform 724.The one or more operations or commands may be transmitted to the simulation engine 730, which may update the behavior of one or more of the virtual objects based on the operations and / or commands. For example, the simulation engine 730 may use the AI engine 732 to update the behavior of the AI agents as well as the virtual objects in the simulated environment 728. The simulation engine 730 may then update the object data and characteristics (e.g., within the asset data store(s) 736), update the GI (and / or other aspects such as reflections, shadows, etc.), and then generate and provide updated sensor inputs to the GPU platform 724. This process may repeat until a simulation is complete.EXAMPLE OF AN AUTONOMOUS VEHICLEFIG. 8A is a diagram of an example of an autonomous vehicle 800, in accordance with some embodiments of the present disclosure. The autonomous vehicle 800 (alternatively referred to herein as "vehicle 800") may include, without limitation, a passenger vehicle, such as a car, truck, bus, first-aid vehicle, shuttle bus, electric or motorized bicycle, motorcycle, fire truck, police vehicle, emergency truck, boat, construction vehicle, underwater vehicle, drone, aircraft, trailer-coupled vehicle (e.g., Goods Transport Semi-trailer), and / or other type of vehicle (e.g., unmanned and / or receiving one or more passengers). Autonomous vehicles are generally described in terms of automation levels provided by the National Highway Traffic Safety Administration (NHTSA), a division of the U.S. Ministry of Traffic, and the Society of Automotive Engineers (SAE) "Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles" (Standard No. J3016-201806 published June 15, 2018, Standard No. J3016-20169 published September 30, 2016, as well as earlier and future versions of this standard). The vehicle 800 may be capable of performing functions according to one or more of the autonomous driving levels 3 to 5. The vehicle 800 may have functions corresponding to one or more of the autonomous driving levels 1 to 5. For example, depending on the embodiment, the vehicle 800 may be capable of assisting the driver (level 1), partial automation (level 2), conditional automation (level 3), high automation (level 4) and / or full automation (level 5). The term "autonomous," as used herein, may include any and / or all types of endoscopy for the vehicle 800 or other machine, such as being fully autonomous, highly autonomous, conditionally autonomous, partially autonomous, providing assisting endoscopy, semi-autonomous, primarily autonomous, or other designation.The vehicle 800 may include components such as a chassis, a vehicle body, wheels (e.g., 2, 4, 6, 8, 18, etc.), tires, axles, and other components of a vehicle. The vehicle 800 may include a propulsion system 850, such as an internal combustion engine, a hybrid electric power plant, a pure electric motor, and / or another type of propulsion system. The propulsion system 850 may be connected to a powertrain of the vehicle 800, which may include a transmission to enable propulsion of the vehicle 800. The propulsion system 850 may be controlled in response to receiving signals from the throttle / accelerator 852.A steering system 854, which may include a steering wheel, may be used to steer the vehicle 800 (e.g., along a desired path or route) when the propulsion system 850 is operating (e.g., when the vehicle is in motion). The steering system 854 may receive signals from a steering actuator 856. The steering wheel can optionally be used for the complete automation (stage 5).The brake sensor system 846 may be used to actuate the vehicle brakes in response to receiving signals from the brake actuators 848 and / or brake sensors.A controller(s) 836, which may include one or more system-on-chips (SoCs) 804 (FIG. 8C ) and / or GPU(s), may (may) provide signals (e.g., representing commands) to one or more components and / or systems of the vehicle 800. For example, the controller(s) may send signals to actuate vehicle brakes via one or more brake actuators 848, to actuate the steering system 854 via one or more steering actuators 856, to operate the propulsion system 850 via one or more throttle / accelerator actuators 852. The controller(s) 836 may include one or more onboard (e.g., integrated) computing devices (e.g., supercomputers) that process sensor signals and issue operating commands (e.g., signals representing commands) to enable autonomous driving and / or to assist a human driver in driving the vehicle 800. The controller(s) 836 may include a first autonomous driving function controller 836, a second functional safety function controller 836, a third artificial intelligence (e.g., computer vision) function controller 836, a fourth infotainment function controller 836, a fifth emergency redundancy controller 836, and / or other controllers. In some examples, a single controller 836 may perform two or more of the above-mentioned functions, two or more controllers 836 may perform a single function, and / or any combination thereof. In some embodiments, sensor data processed by one or more controllers 836 for one or more sensors may be synthetically generated by controlling the driving environment simulation platform 100 to have lane surfaces that include wear-based visual artifacts generated by the tile surface texture map 130 described herein.The controller(s) 836 may provide the signals to control one or more components and / or systems of the vehicle 800 in response to sensor data received from one or more sensors (e.g., sensor inputs). The sensor data may be transmitted to (one) sensor(s) for global navigation satellite systems 858 (e.g., global positioning system sensor(s)), RADAR sensor(s) 860, ultrasonic sensor(s) 862, LiDAR sensor(s) 864, inertial measurement unit (IMU) sensor(s) 866 (e.g., accelerometer, gyroscope(s), magnetic compass(s), magnetometer, etc.), microphone(s) 896, stereo camera(s) 868, wide-angle camera(s) 870 (e.g., fish-eye cameras), infrared camera(s) 872, for example, and without limitation, In addition, the surround camera(s) 874 (e.g., 360 degree cameras), the remote and / or mid-range camera(s) 898, speed sensor(s) 844 (e.g., for measuring the speed of the vehicle 800), vibration sensor(s) 842, steering sensor(s) 840, brake sensor(s) (e.g., as part of the brake sensor system 846), one or more occupant monitoring system, or OMS, sensors 801 (e.g., one or more interior cameras), and / or other types of sensors may be received.One or more of the controllers 836 may receive input (e.g., represented by input data) from a cluster 832 of the vehicle 800 and provide output (e.g., represented by output data, display data, etc.) via a human machine interface (HMI) display 834, an acoustic detector, a speaker, and / or via other components of the vehicle 800. The outputs may include information such as vehicle speed, speed, time, map data (e.g., high definition ("HD") map 822 of FIG. 8C ), position data (e.g., the position of vehicle 800, e.g., on a map), direction, position of other vehicles (e.g., an occupancy grid), information about objects, and status of objects as perceived by controller(s) 836, etc. For example, the HMI display 834 may display information about the presence of one or more objects (e.g., a road sign, a warning sign, a changing traffic light, etc.) and / or information about driving maneuvers that the vehicle has performed, is performing or will be performing (e.g., now changing lanes, taking exit 34B in two miles, etc.). In some embodiments, the HMI display 834 may include the HMI 185 and present renderings of the runtime simulation output 180.The vehicle 800 further includes a network interface 824, which may use one or more wireless antenna(s) 826 and / or modem(s) to communicate over one or more networks. For example, network interface 824 may be capable of communicating via long term evolution ("LTE"), wideband code division multiple access ("WCDMA"), universal mobile telecommunications system ("UMTS"), global system for mobile communication ("GSM"), IMT-CDMA multi-carrier ("CDMA2000"), etc. The wireless antenna(s) 826 may also enable communication between objects in the environment (e.g., vehicles, mobile devices, etc.) using local area networks such as Bluetooth, Bluetooth Low Energy ("LE"), Z-Wave, ZigBee, etc., and / or low power wide area networks ("LPWANs") such as LoRaWAN, SigOx, etc.FIG. 8B is an example of camera locations and fields of view for the example autonomous vehicle 800 of FIG. 8A, in accordance with some embodiments of the present disclosure. The cameras and the respective fields of view are an example of an embodiment and are not intended to be limiting. For example, additional and / or alternative cameras may be provided and / or the cameras may be disposed at other locations on the vehicle 800.The camera types for the cameras may include, but are not limited to, digital cameras that may be configured for use with the components and / or systems of the vehicle 800. The camera(s) may / may operate according to Automotive Safety Integrity Level (ASIL) B and / or another ASIL. The camera types may achieve any image capture rate, e.g., 60 frames per second (fps), 120 fps, 240 fps, etc., depending on the embodiment. The cameras may use rolling shutters, global shutters, another type of shutter, or a combination thereof. In some examples, the color filter array may include a red clear clear clear color filter array (RCCC), a red clear clear blue color filter array (RCCB), a red blue green clear color filter array (RBGC), a Foveon X3 color filter array, a Bayer sensor color filter array (RGGB), a monochrome sensor color filter array, and / or another type of color filter array. In some embodiments, clear pixel cameras may be used to increase photosensitivity, such as cameras with an RCCC, an RCCB, and / or an RBGC color filter array.In some examples, one or more of the camera(s) may be used to perform advanced driver assistance systems (ADAS) functions (e.g., as part of a redundant or fail-safe design). For example, a multi-function monocamera may be installed that provides functions including lane keeping assist, road sign assist, and smart headlight control. One or more of the camera(s) (e.g., all cameras) may simultaneously record and provide image data (e.g., video).One or more of the cameras may be mounted in a mounting arrangement, such as a custom designed (three-dimensional ("3D") printed) arrangement, to eliminate stray light and reflections from the vehicle interior (e.g., reflections from the dashboard reflected in the windshield mirrors), which may interfere with the image data acquisition capabilities of the camera. When mounting exterior mirrors, the exterior mirrors can be three-dimensionally printed in a customer-specific manner, so that the camera mounting plate corresponds to the shape of the exterior mirror. In some examples, the cameras may be integrated into the exterior mirror. In side cameras, the cameras may also be integrated into the four pillars at each corner of the passenger compartment.Cameras having a field of view that involve portions of the environment in front of the vehicle 800 (e.g., front facing cameras) may be used for the environment view to help identify front facing paths and obstacles, as well as to help provide information, via one or more controllers 836 and / or control SoCs, that is critical for generating an occupancy grid and / or determining the preferred vehicle paths. Forward facing cameras may be used to perform many of the same ADAS functions as LiDAR, including emergency braking, pedestrian detection, and collision avoidance. Forward facing cameras may also be used for ADAS functions and systems such as lane departure warning ("LDW"), autonomous cruise control ("ACC")), and / or other functions such as traffic sign detection.A plurality of cameras may be used in a forward facing configuration, e.g., a monocular camera platform that includes a Complementary Metal Oxide Semiconductor ("CMOS")) type color imager. Another example is one or more wide-angle cameras 870 that can be used to detect objects that are viewed from the periphery (e.g., pedestrians, crossing traffic, or bicycles). Although only one wide-angle camera is shown in FIG. 8B, any number (including none) of wide-angle cameras 870 may be located on the vehicle 800. Moreover, any number of long range cameras 898 (e.g., a long range stereo camera pair) may be used for depth-based object detection, particularly for objects for which a neural network has not yet been trained. The long range camera(s) 898 may also be used for object detection and classification as well as for basic object tracking.Any number of stereo cameras 868 may also be included in a forward-facing configuration. In at least one embodiment, one or more stereo camera(s) 868 may include an integrated control unit that includes a scalable processing unit that may provide a programmable logic ("FPGA") and a multicore microprocessor with a controller area network (CAN) or Ethernet integrated interface on a single chip. Such a unit may be used to generate a 3-D map of the vehicle environment, including a distance estimate for all points in the image. An alternative stereo camera(s) 868 may include a compact stereo vision sensor or sensors that include two camera lenses (one left and right each) and an image processing chip that measure the distance between the vehicle and the target object and may use the generated information (e.g., metadata) to enable the autonomous emergency braking and lane keeping warning functions. Other types of stereo camera(s) 868 may be used in addition to or alternatively to those described herein.Cameras with a field of view that incorporate portions of the environment laterally of the vehicle 800 (e.g., side cameras) may be used for an environmental view that provides information used to generate and update the occupancy grid as well as to generate side impact warnings. For example, the surround camera(s) 874 (e.g., four surround cameras 874 as shown in FIG. 8B ) may be positioned on the vehicle 800. The surround camera(s) 874 may include wide-angle camera(s) 870, fisheye camera(s), 360-degree camera(s), and / or the like. For example, four fish eye cameras may be mounted on the front, rear, and sides of the vehicle. In an alternative arrangement, the vehicle may use three surround cameras 874 (e.g., left, right, and rear) and utilize one or more other camera(s) (e.g., a front facing camera) as a fourth surround camera.Cameras with a field of view that include portions of the environment behind the vehicle 800 (e.g., backup cameras) may be used for parking assist, environmental view, rear end collision warnings, and generating and updating the occupancy grid. A wide variety of cameras may be used, including, but not limited to, cameras also suitable as forward facing camera(s) (e.g., long range and / or mid range camera(s) 898, stereo camera(s) 868, infrared camera(s) 872, etc.) as described herein.Cameras having a field of view including portions of the interior environment within the vehicle cabin 800 (e.g., one or more OMS sensors 801) may be used as part of an occupant monitoring system (OMS), such as, but not limited to, a driver monitoring system (DMS). For example, OMS sensors (e.g., OMS sensor(s) 801) may be used (e.g., by controller(s) 836) to track a viewing direction, head posture, and / or blinking of an occupant and / or driver. This gaze information may be used to determine the level of attention of the occupant or driver (e.g., to detect drowsiness, tiredness, and / or distraction) and / or to take action to prevent damage to the occupant or driver. In some embodiments, data from OMS sensors may be used to enable gaze-controlled operations triggered by drivers and / or other occupants, such as cabin temperature and / or airflow adjustment, window opening and closing, cabin lighting control, entertainment system control, mirror adjustment, seat position adjustment, and / or other operations. In some embodiments, an OMS may be used for applications such as determining whether items and / or occupants have been left in a vehicle (e.g., by detecting the presence of occupants after the driver leaves the vehicle). In some embodiments, synthetic sensor data representing data from one or more of the cameras shown in FIG. 8B may be generated based on road surface rendering data 142 generated by the tile surface texture map 130.FIG. 8C is a block diagram of an example system architecture for the example autonomous vehicle 800 of FIG. 8A, in accordance with some embodiments of the present disclosure. It should be understood that these and other arrangements described herein are presented by way of example only. Other arrangements and elements (e.g., machines, interfaces, functions, orders, groupings of functions, etc.) may be used in addition to or in place of those illustrated, and some elements may be omitted altogether. In addition, many of the elements described herein are functional units that may be implemented as discrete or distributed components or in conjunction with other components and in any suitable combination and location. Various functions described herein, which are performed by units, may be performed by hardware, firmware, and / or software. For example, various functions may be performed by a processor executing instructions stored in a memory.All of the components, features, and systems of vehicle 800 in FIG. 8C are shown connected via bus 802. Bus 802 may include a controller area network (CAN) data interface (alternatively referred to herein as a "CAN bus"). A CAN bus may be a network within the vehicle 800 that is used to assist in controlling various features and functions of the vehicle 800, such as brake actuation, acceleration, braking, steering, windshield wipers, etc. A CAN bus may be configured to have dozens or even hundreds of nodes, each with its own unique identifier (e.g., a CAN ID). The CAN bus may be read to determine a steering wheel angle, a vehicle speed, an engine speed per minute (RPM), button positions, and / or other vehicle status indicators. The CAN bus may be ASIL B compliant.Although bus 802 is described herein as a CAN bus, this is not to be understood as limiting. For example, FlexRay and / or Ethernet can also be used in addition or as an alternative to the CAN bus. Although a single line is used to represent bus 802, this is not to be understood as a limitation. For example, there may be any number of buses 802, which may include one or more CAN buses, one or more FlexRay buses, one or more Ethernet buses, and / or one or more other types of buses having a different protocol. In some examples, two or more buses 802 may be used to perform different functions and / or may be used for redundancy. For example, a first bus 802 may be used for a collision avoidance function and a second bus 802 may be used for operation control. In any example, each bus 802 may communicate with any of the components of the vehicle 800, and two or more buses 802 may communicate with the same components. In some examples, each SoC 804, controller 836, and / or computer within the vehicle may have access to the same input data (e.g., inputs from sensors of the vehicle 800) and may be connected to a common bus, such as the CAN bus.The vehicle 800 may include one or more controllers 836 as described herein with respect to FIG. 8A. The controller(s) 836 may be used for a variety of functions (may be). The controller(s) 836 may be coupled to various other components and systems of the vehicle 800 and may be used (may) to control the vehicle 800, to artificial intelligence of the vehicle 800, to infotainment for the vehicle 800, and / or the like.The vehicle 800 may include one or more system(s) on a chip (SoC) 804. The SoC 804 may include CPU(s) 806, GPU(s) 808, processor(s) 810, cache(s) 812, accelerators 814, data storage 816, and / or other components and features not shown. The SoC(s) 804 may be(can) used to control the vehicle 800 in a variety of platforms and systems. For example, in a system (e.g., the vehicle 800 system), the SoC (or SoCs) 804 may be combined with an HD card 822, which may receive card refreshes and / or card updates from one or more servers (e.g., server(s) 878 of FIG. 8D ) via a network interface 824.The CPU(s) 806 may include a CPU cluster or complex (alternatively referred to herein as "CCPLEX"). The CPU(s) 806 may include a plurality of cores and / or L2 caches. In some embodiments, CPU(s) 806 may include, for example, eight cores in a coherent multiprocessor configuration. In some embodiments, the CPU(s) 806 may include four dual core clusters, each cluster having a dedicated L2 cache (e.g., a 2 MB L2 cache). The CPU(s) 806 (e.g., the CCPLEX) may be(can) configured to support concurrent clustering operation, thereby allowing any combination of clusters of the CPU(s) 806 to be active at a particular time.The CPU(s) 806 may implement power management functions that include one or more of the following features: individual hardware blocks may be automatically clock limited when idle to conserve dynamic power; each core clock may be limited when the core is not actively executing instructions due to execution of WFI / WFE instructions; each core may be independently current limited; each core cluster may be independently clock limited when all cores are clock limited or current limited; and / or each core cluster may be independently current limited when all cores are current limited. The CPU(s) 806 may further implement an enhanced power state management algorithm in which allowed power states and expected wake-up times are set and the hardware / microcode determines the best power state to take for the core, cluster, and CCPLEX. The processor cores may support simplified sequences for entering the power state in software, offloading work to microcode.The GPU(s) 808 may comprise an integrated GPU (alternatively referred to herein as "iG"). The GPU(s) 808 may be programmable and efficient for parallel workloads. The GPU(s) 808 may use an extended tensor instruction set in some examples. The GPU(s) 808 may include one or more streaming microprocessors, where each streaming microprocessor may include an L1 cache (e.g., an L1 cache with at least 96 KB storage capacity) and two or more of the streaming microprocessors may share an L2 cache (e.g., an L2 cache with 512 KB storage capacity). In some embodiments, the GPU(s) 808 may include at least eight streaming microprocessors. The GPU(s) 808 may use application programming interface(s) (API(s)) for computations. Moreover, the GPU(s) 808 may use one or more parallel computing platforms and / or programming models (e.g., CUDA from NVIDIA).The GPU(s) 808 may be energy optimized for best performance in automotive and embedded use cases. For example, the GPU(s) 808 may be fabricated on a fin field effect transistor (FinFET). However, this is not to be understood as limiting, and the GPU(s) 808 may (may) be fabricated using other semiconductor fabrication techniques. Each streaming microprocessor may include a number of mixed precision computing cores divided into multiple blocks. For example, 64 PF32 cores and 32 PF64 cores may be divided into four processing blocks, without being limited thereto. In such an example, each processing block may be allocated 16 FP32 cores, 8 FP64 cores, 16 INT32 cores, two mixed precision NVIDIA TENSOR COREs for deep learning matrix arithmetic, an L0 instruction cache, a warp scheduler, a dispatch unit, and / or a 64 KB register file. In addition, the streaming microprocessors may include independent parallel integer and floating point data paths to provide efficient execution of workloads with a mixture of computations and addressing computations. The streaming microprocessors may have independent thread scheduling capability to enable fine grain synchronization and cooperation between parallel threads. The streaming microprocessors may include a combined L1 data cache and shared memory unit to improve performance while simplifying programming.The GPU(s) 808 may include a high bandwidth memory (HBM) and / or a 16 GB HBM2 memory subsystem to provide a peak memory bandwidth of about 900 GB / second, in some examples. In some examples, in addition to or as an alternative to HBM memory, synchronous graphics random access memory (SGRAM) may be used, e.g., synchronous graphics dual data rate random access memory type 5 (GDDR5).The GPU(s) 808 may include unified memory technology with access counters to enable more accurate migration of memory pages to the processor that most frequently accesses them, thereby improving the efficiency of memory areas shared by the processors. In some examples, address translation services (ATS) support may be used to enable the GPU(s) 808 to directly access the page tables of the CPU(s) 806. In such examples, if the memory management unit (MMU) of the GPU(s) 808 detects an error, an address translation request may be transmitted to the CPU(s) 806. In response, the CPU(s) 806 may search in their page tables for the virtual-physical mapping for the address and return the translation to the GPU(s) 808. As such, unified memory technology may enable a single unified virtual address space for the memory of both the CPU(s) 806 and the GPU(s) 808, thereby facilitating programming of the GPU(s) 808 and porting applications to the GPU(s) 808.Moreover, the GPU(s) 808 may include an access counter that may track the frequency of access of the GPU(s) 808 to the memory of other processors. The access counter may help to move memory pages into physical memory from the processor that most frequently accesses the pages.The SoC(s) 804 may include any number of cache(s) 812, including those described herein. The cache(s) 812 may include, for example, an L3 cache available to both the CPU(s) 806 and the GPU(s) 808 (e.g., connected to both the CPU(s) 806 and the GPU(s) 808). The cache(s) 812 may include a write back cache that may track the states of lines, e.g., by using a cache coherency protocol (e.g., MEI, MESI, MSI, etc.). The L3 cache may be 4 MB or more, depending on embodiment, although smaller cache sizes may also be used.The SoC(s) 804 may include an arithmetic logic unit(s) (ALU(s)) that may be operatively deployed in performing processing related to any of a variety of tasks or operations of the vehicle 800, such as processing DNNs. Moreover, the SoC(s) 804(s) may include a floating point unit(s) (FPU(s)) or other mathematical coprocessors or numerical coprocessor types for performing mathematical operations within the system. For example, the SoC(s) 804(s) may include one or more FPUs integrated as execution units into a CPU(s) 806 and / or GPU(s) 808.The SoC(s) 804 may include one or more accelerators 814 (e.g., hardware accelerators, software accelerators, or a combination thereof). For example, the SoC(s) 804(s) may include a hardware acceleration cluster that may include optimized hardware accelerators and / or large on-chip memory. The large on-chip memory (e.g., 4 MB SRAM) may enable the hardware accelerator cluster to accelerate neural networks and other computations. The hardware accelerator cluster may be used to supplement the GPU(s) 808 and offload some tasks of the GPU(s) 808 (e.g., to enable more cycles of the GPU(s) 808 to perform other tasks). The accelerator(s) 814 may be used, for example, for targeted workloads (e.g., perception, convolutional neural networks (CNNs), etc.) that are stable enough to be accelerated. The term "CNN" as used herein may include all types of CNNs, including region-based or regional convolutional neural networks (RCNNs) and fast RCNNs (e.g., as used for object detection).The accelerator(s) 814 (e.g., the hardware accelerator cluster) may include a deep learning accelerator (DLA). The DLA(s)(s) may include one or more tensor processing units (TPUs), which may be configured to provide additional ten billion operations per second for deep learning applications and inferencing. The TPUs may be accelerators configured and optimized to perform image processing functions (e.g., for CNNs, RCNNs, etc.). The DLA(s)(s) may be further(s) optimized for a particular set of neural network types and floating point operations, as well as for inferencing. The design of the DLA(s) can provide more power per millimeter than a general purpose GPU and far exceeds the performance of a CPU. The TPU(s) may execute multiple functions, including a single instance convolution function that supports, for example, INT8, INT16, and FP16 data types for both features and weights, as well as postprocessor functions.The DLA(s) may quickly and efficiently execute neural networks, particularly CNNs, on processed or unprocessed data for a variety of functions including, for example and without limitation: a CNN for object identification and detection using data from camera sensors; a CNN for distance estimation using data from camera sensors; a CNN for emergency vehicle detection and identification and detection using data from microphones; a CNN for face detection and vehicle owner identification using data from camera sensors; and / or a CNN for safety-relevant events.The DLA(s)(s) may execute any function of the GPU(s) 808, and by using an inference accelerator, for example, a developer may employ either the DLA(s)(s) or the GPU(s) 808 for any function. For example, the developer may focus the processing of CNNs and floating point operations on the DLA(s) and leave other functions to the GPU(s) 808 and / or other accelerator(s) 814.The accelerator(s) 814 (e.g., the hardware accelerator cluster) may include a programmable image processing accelerator (PVA), which may alternatively be referred to herein as a computer vision accelerator. The PVA(s)(s) may be configured and configured to accelerate computer vision algorithms for advanced driver assistance systems (ADAS), autonomous driving, and / or augmented reality (AR) and / or virtual reality (VR) applications. The PVA(s) may provide a balance between performance and flexibility. For example, each PVA may include, for example and without limitation, any number of reduced instruction set computing (RISC) cores, direct memory access (DMA), and / or any number of vector processors.The RISC cores may interact with image sensors (e.g., the image sensors of any of the cameras described herein), image signal processors, and / or the like. Each of the RISC cores may include any amount of memory. The RISC cores may use any number of protocols depending on the embodiment. In some examples, the RISC cores may execute a real-time operating system (RTOS). The RISC cores may be implemented with one or more integrated circuit devices, application specific integrated circuit devices (ASICs), and / or memory devices. For example, the RISC cores may include an instruction cache and / or a close coupled RAM.The DMA may allow components of the PVA(s) to access system memory independent of the CPU(s) 806. The DMA may support any number of functions used to optimize the PVA, including, but not limited to, support multi-dimensional addressing and / or circular addressing. In some examples, DMA may support up to six or more dimensions of addressing, which may include block width, block height, block depth, horizontal block stepping, vertical block stepping, and / or depth stepping.The vector processors may be programmable processors that may be configured to efficiently and flexibly execute programming for computer vision algorithms and provide signal processing capabilities. In some examples, the PVA may include a PVA core and two vector processing subsystem partitions. The PVA core may include a processor subsystem, DMA engine(s) (e.g., two DMA engines), and / or other peripheral devices. The vector processing subsystem may operate as the primary processing unit of the PVA and may include a vector processing unit (VPU), an instruction cache, and / or a vector memory (e.g., VMEM). A VPU core may include a digital signal processor, e.g., a single instruction, multiple data (SIMD) and very long instruction words (VLIW). The combination of SIMD and VLIW may increase throughput and speed.Each of the vector processors may include an instruction cache and may be coupled to dedicated memory. As a result, in some examples, each of the vector processors may be configured to operate independently of the other vector processors. In other examples, the vector processors included in a particular PVA may be configured to use data parallelism. For example, in some embodiments, the plurality of vector processors included in a single PVA may execute the same computer vision algorithm, but on different regions of an image. In other examples, the vector processors included in a particular PVA may execute different computer vision algorithms on the same image simultaneously or even execute different algorithms on successive images or portions of an image. Among other things, any number of PVAs may be present in the hardware accelerator cluster and any number of vector processors may be included in each of the PVAs. Additionally, the PVA(s)(s) may include an additional error correcting code (ECC) memory to increase the security of the overall system.The accelerator(s) 814 (e.g., the hardware accelerator cluster) may include a computer vision network on a chip and SRAM to provide a high bandwidth, low latency SRAM to the accelerator(s) 814. In some examples, the memory on-chip may have at least 4 MB SRAM, which may be, for example and without limitation, eight field configurable memory blocks that may be accessible to both the PVA and the DLA. Each pair of memory blocks may include an advanced peripheral bus (APB) interface, configuration circuits, a controller, and a multiplexer. Any type of memory may be used. The PVA and DLA may access the memory via a backbone that provides the PVA and DLA with high speed access to the memory. The backbone may include a computer vision network on a chip that connects the PVA and the DLA to the memory (e.g., using the APB).The computer vision network on the chip may include an interface that determines that both the PVA and the DLA provide ready and valid signals prior to transmission of any control signals / addresses / data. Such an interface may provide separate phases and separate channels for the transmission of control signals / addresses / data as well as burst communication for continuous data transmission. This type of interface may comply with the ISO 26262 or IEC 61508 standards, although other standards and protocols may also be used.In some examples, the SoC(s) 804(s) may include a real-time ray tracing hardware accelerator as described in U.S. patent application Ser. No. 16 / 101,232, filed Aug. 10, 2018. The real-time ray tracing hardware accelerator may be used to quickly and efficiently determine the positions and extents of objects (e.g., within a world model), to generate real-time visualization simulations, for RADAR signal interpretation, for sound propagation synthesis and / or analysis, for simulation of SONAR systems, for general wave propagation simulation, for comparison with LiDAR data for purposes of localization and / or other functions, and / or for other uses. In some embodiments, one or more tree traversal units (TTUs) may be used for performing one or more ray tracing-related operations.The accelerator(s) 814 (e.g., the hardware accelerator cluster) has(have) a wide range of applications for autonomous driving. The PVA may be a programmable image processing accelerator that may be used for important processing levels in ADAS and autonomous vehicles. The capabilities of the PVA are well suited for algorithmic areas requiring predictable processing at low power and low latency. Therefore, the PVA lends itself well to semi-dense or dense regular computations, even for small data sets requiring predictable low latency, low power consumption runtimes. Thus, in the context of autonomous vehicle platforms, the PVAs are designed to execute classical computer vision algorithms because they are efficient at object detection and operate with integer math.For example, according to one embodiment of the technology, the PVA is used to perform computer stereo vision. A semi-global matching-based algorithm may be used in some examples, although this is not intended to be limiting. Many applications for autonomous driving of stages 3 to 5 require motion estimation / stereo matching during operation (e.g., structure of motion, pedestrian detection, lane detection, etc.). The PVA may perform a computer stereo vision function on inputs from two monocular cameras.In some examples, the PVA may be used to perform a dense optical flow. In accordance with processing raw RADAR data (e.g., using 4D fast Fourier Transform) to provide processed RADAR data. In other examples, the PVA is used for time-of-flight depth processing by processing raw time-of-flight data to provide processed time-of-flight data, for example.The DLA may be used to operate any type of network to improve control and driving safety, including, for example, a neural network that outputs a measure of confidence for each object detection. Such a confidence value may be interpreted as a probability or as a relative "weight" for each detection as compared to other detections. This confidence value allows the system to make further decisions regarding which detections should be considered true positive detections and which should be considered false positive detections. For example, the system may set a threshold for confidence and consider only the detections exceeding that threshold as true positive detections. In an automatic emergency braking (AEB) system, false positive detections would result in the vehicle automatically performing emergency braking, which is, of course, undesirable. Therefore, only the most trusted detections should be considered as triggers for AEB. The DLA may employ a neural network to regression the confidence value. The neural network may use as input at least a subset of parameters, such as dimensions of a bounding box, an estimate of the ground plane obtained (e.g., from another subsystem), an output of an inertial measurement unit (IMU) 866 that correlates with the orientation of the vehicle 800, a distance, an estimate of the 3D position of the object obtained from the neural network and / or other sensors (e.g., LiDAR sensor(s) 864 or RADAR sensor(s) 860), and others.The SoC(s) 804 may include one or more data stores 816 (e.g., memory). The data store(s) 816 may be an on-chip memory of the SoC(s) 804(s) that may store neural network(s) executing on the GPU and / or the DLA. In some examples, the capacity of the data store(s) 816 may be large enough to store multiple instances of neural networks for redundancy and security. The data store(s) 812 may include L2 or L3 cache(s) 812. A reference to the data store(s) 816 may include a reference to the memory associated with the PVA, DLA, and / or other accelerators 814 as described herein.The SoC(s) 804 may include one or more processor(s) 810 (e.g., embedded processors). Processor(s) 810 may include a boot and power management processor, which may be a dedicated processor and subsystem to handle the boot power and management functions and associated security enforcement. The boot and power management processor may be part of a boot sequence of the SoC(s) 804 and may provide runtime power management services. The boot power and management processor may provide clock and voltage programming, support for system transitions to a low power state, management of temperatures and temperature sensors of SoC(s) 804, and / or management of power supply states of the SoC(s) 804. Each temperature sensor may be implemented as a ring oscillator whose output frequency is proportional to temperature, and the SoC(s) 804 may use the ring oscillators to sense temperatures of the CPU(s) 806, GPU(s) 808, and / or accelerator 814. If it is determined that the temperatures exceed a threshold, the boot and power management processor may enter a temperature fault routine and place the SoC(s) 804 in a lower power state and / or place the vehicle 800 in a chauffeur-to-safe stop mode (e.g., place the vehicle 800 in a safe stop).Processor(s) 810 may further include a set of embedded processors, which may serve as an audio processing engine. The audio processing engine may be an audio subsystem that enables full hardware support for multi-channel audio over multiple interfaces and a wide and flexible range of audio I / O interfaces. In some examples, the audio processing engine is a dedicated processor core with a dedicated RAM digital signal processor.Processor(s) 810 may also include an "always on" processor machine that provides the necessary hardware functions to support low power sensor management and wake-up use cases. The "always on" processor engine may include a processor core, a close coupled RAM, supporting peripherals (e.g., timer and interrupt controller), various I / O controller peripherals, and routing logic.Processor(s) 810 may also include a safety cluster machine that includes a dedicated processor subsystem for the safety management of automotive applications. The safety cluster machine may include two or more processor cores, a close coupled RAM, supporting peripherals (e.g., timers, interrupt control, etc.), and / or routing logic. In a safety mode, the two or more cores may operate in a lockstep mode and function as a single core with comparison logic to detect any differences between their operations.Processor(s) 810 may further include a real-time camera machine, which may include a dedicated processor subsystem for handling real-time camera management.Processor(s) 810 may further include a high dynamic range signal processor, which may include an image signal processor that is a hardware machine that is part of the camera processing pipeline.The processor(s) 810 may include a video image combiner, which may be a processing block (e.g., implemented on a microprocessor) that implements video post-processing functions needed by a video playback application to generate the final image for the playback window. The video image combiner may make a lens distortion correction on the wide angle camera(s) 870, the surround camera(s) 874 and / or the sensors of the surveillance camera in the passenger compartment. The monitoring camera sensor in the passenger compartment is preferably monitored by a neural network running on another instance of the extended SoC that is configured to detect and react accordingly to events in the passenger compartment. A system in the cabin may perform lipread to activate a cellular service and place a call, dictate emails, change the vehicle destination, activate or change the infotainment system and the settings of the vehicle, or enable voice-controlled browsing on the Internet. Certain functions are available to the driver only when the vehicle is operating in an autonomous mode and are otherwise disabled.The video image combiner may have improved temporal noise rejection for both spatial and temporal noise rejection. For example, when movements occur in a video, the noise suppression weights the spatial information accordingly and reduces the weight of the information provided by adjacent frames. If an image or a portion of an image does not have motion, the temporal noise suppression performed by the video image combiner may use information from the previous image to reduce the noise in the current image.The video image combiner may also be configured to perform stereo rectification on input stereo frames. The video image combiner may also be used for user interface design when the operating system desktop is in use and the GPU(s) 808 are not needed to continually render new surfaces. Even if the graphics processor(s) 808 are (are) powered on and actively engaged in 3D rendering, the video image combiner may be used to offload the graphics processor(s) 808 to improve performance and responsiveness.In some embodiments, one or more of the video image processing functions of the SoC 804, the CPU(s) 806, the GPU(s) 808, and / or the processor / s 810 may be performed using renderings based on road surface rendering data 142 that includes wear-based visual artifacts generated by the tile surface texture map 130.The SoC(s) 804 may further include a Mobile Industry Processor Interface (MIPI) camera serial interface for receiving video and inputs from cameras, a high-speed interface, and / or a video input block that may be used for camera and related pixel input functions. The SoC(s) 804 may further include an input / output controller(s) that may be controlled by software (may) and used to receive I / O signals that are not bound to a particular role.The SoC(s) 804 may further include a wide range of peripheral interfaces to enable communication with peripheral devices, audio codecs, power management, and / or other devices. The SoC(s) 804 may(s) be used to process data from cameras (e.g., connected via gigabit multimedia serial link and Ethernet), sensors (e.g., LiDAR sensor(s) 864, RADAR sensor(s) 860, etc., which may be connected via Ethernet), data from bus 802 (e.g., speed of vehicle 800, steering wheel position, etc.), data from GNSS sensor(s) 858 (e.g., connected via Ethernet or CAN bus). The SoC(s) 804 may further include dedicated high-performance mass storage controllers, which may have their own DMA engines, and which may be used to offload the CPU(s) 806 from routine data management tasks.The SoC(s) 804 may(s) be an end-to-end platform with a flexible architecture spanning automation levels 3- 5 and thereby providing a comprehensive functional safety architecture that uses computer vision and ADAS techniques for diversity and redundancy, provides a platform for a flexible, reliable driving software stack along with tools for deep learning, and efficiently employs them. The SoC(s) 804 may(s) be faster, more reliable, and even more energy and space saving than conventional systems. For example, the accelerator(s) 814, when combined (are) with the CPU(s) 806, the GPU(s) 808, and the data store(s) 816(s), may form a fast, efficient level 3-5 autonomous vehicle platform(s).The technology thus offers possibilities and functions that cannot be achieved with conventional systems. For example, computer vision algorithms can be executed on CPUs that can be configured using high-level programming languages, such as the C programming language, to execute a variety of processing algorithms for a variety of visual data. However, CPUs are often unable to meet the performance requirements of many computer vision applications, e.g., execution time and power consumption. In particular, many CPUs are unable to execute complex object detection algorithms in real-time, which is a prerequisite for in-vehicle ADAS applications and a prerequisite for practical level 3-5 autonomous vehicles.In contrast to conventional systems, by providing a CPU complex, a GPU complex, and a hardware acceleration cluster, the technology described herein enables multiple neural networks to be executed simultaneously and / or sequentially and the results combined together to enable level 3-5 autonomous driving functions. For example, a CNN executing on the DLA or the dG (e.g., the GPU(s) 820) may have text and word recognition that enables the supercomputer to read and understand traffic signs, including signs for which the neural network has not been specifically trained. The DLA may further include a neural network capable of identifying, interpreting, and providing semantic understanding to the character and passing this semantic understanding to the path planning modules running on the CPU complex.As another example, multiple neural networks may be executed simultaneously, as required for driving level 3, 4, or 5. For example, a warning sign with the heading "Caution: flashing lights indicate ice smoothness" may be interpreted independently or jointly together with an electrical light from a plurality of neural networks. The sign itself may be identified as a traffic sign by a first deployed neural network (e.g., a neural network that has been trained), the text "flashing lights indicate ice smoothness" may be interpreted by a second deployed neural network that notifies the vehicle path planning software (preferably executing on the CPU complex) that when flashing lights are detected, ice smoothness exists. The turn signal light may be identified by operating a third neural network over multiple frames informing the path planning software of the vehicle of the presence (or absence) of turn signals. All three neural networks may run simultaneously, e.g., within the DLA and / or on the GPU(s) 808.In some examples, a CNN for face recognition and vehicle owner identification may use data from camera sensors to identify the presence of an authorized driver and / or owner of the vehicle 800. The "always on" sensor processing machine may be used to unlock the vehicle when the owner approaches the driver door and turn on the lights, and, in the security mode, to deactivate the vehicle when the owner leaves the vehicle. In this way, the SoC(s) 804(s) ensures security against theft and / or vehicle development.In another example, a CNN for emergency vehicle detection and identification may use data from microphones 896 to detect and identify sirens of emergency vehicles. Unlike conventional systems that use general classifiers to detect sirens and manually extract features, the SoC(s) 804 uses (use) the CNN to classify environmental and urban sounds as well as to classify visual data. In a preferred embodiment, the CNN running on the DLA is trained to detect the relative approach speed of the emergency vehicle (e.g., using the Doppler effect). The CNN may also be trained to identify emergency vehicles specific to the local area in which the vehicle is operating as identified by GNSS sensor(s) 858. For example, the CNN will attempt to detect European sirens in Europe, while in the United States it will attempt to identify only North American sirens. Once an emergency vehicle is detected, a control program may be used to execute an emergency vehicle safety routine, slow the vehicle, drive to the roadside, park the vehicle, and / or idle the vehicle using ultrasonic sensors 862 until the emergency vehicle(s) has(are) passed.The vehicle may include a CPU(s) 818 (e.g., discrete CPU(s) or dCPU(s)), which may be coupled to the SoC(s) 804 via a high-speed link (e.g., PCIe). The CPU(s) 818 may include, for example, an X86 processor. The CPU(s) 818 may be used to perform a variety of functions, including tuning potentially inconsistent results between ADAS sensors and the SoC(s) 804, and / or monitoring the status and state of the controller(s) 836 and / or the infotainment SoC 830, for example.The vehicle 800 may include a GPU(s) 820 (e.g., discrete GPU(s) or dG(s)), which may be coupled to the SoC(s) 804 via a high-speed link (e.g., NVIDIAs NVLINK). The GPU(s) 820 may(s) provide additional artificial intelligence functionality, for example, by executing redundant and / or different neural networks, and may be used (may) to train and / or update neural networks based on input (e.g., sensor data) from sensors of the vehicle 800.The vehicle 800 may further include the network interface 824, which may include one or more wireless antennas 826 (e.g., one or more wireless antennas for different communication protocols, such as a cellular antenna, a Bluetooth antenna, etc.). The network interface 824 may be used to enable wireless connection over the Internet to the cloud (e.g., to the server(s) 878 and / or other network devices), to other vehicles, and / or to computing devices (e.g., passenger client devices). To communicate with other vehicles, a direct connection between the two vehicles and / or an indirect connection may be established (e.g., via networks and via the Internet). Direct connections may be established via a vehicle-to-vehicle communication link. The vehicle-to-vehicle communication link may provide information to the vehicle 800 about vehicles in the vicinity of the vehicle 800 (e.g., vehicles in front of, beside, and / or behind the vehicle 800). This function may be part of a cooperative adaptive cruise control function of the vehicle 800.Network interface 824 may have an SoC that provides modulation and demodulation and allows controller 836 to communicate over wireless networks. The network interface 824 may include a radio frequency front end for up-conversion from baseband to radio frequency and down-conversion from radio frequency to baseband. The frequency transformations may be performed by known processes and / or by super-heterodyne processes. In some examples, the radio frequency front end function may be provided by a separate chip. The network interface may include wireless features for communicating over LTE, WCDMA, UMTS, GSM, CDMA2000, Bluetooth, Bluetooth LE, Wi-Fi, Z-Wave, ZigBee, LoRaWA and / or other wireless protocols.The vehicle 800 may also include data storage 828, which may also include off-chip memory (e.g., off-the-SoC 804). The data stores 828 may include one or more memory elements including RAM, SRAM, DRAM, VRAM, flash, hard drives, and / or other components and / or devices capable of storing at least one bit of data.The vehicle 800 may also include one or more GNSS sensors 858. The GNSS sensors 858 (e.g., GPS, assisted GPS sensors, differential GPS sensors (differential GPS - DGPS), etc.) assist in mapping, perception, generation of occupancy grids, and / or path planning. Any number of GNSS sensors 858 may be used, including, for example, a GPS device using a USB port with an Ethernet to Serial Bridge (RS-232).The vehicle 800 may also include one or more RADAR sensors 860. The RADAR sensor 860 can be used by the vehicle 800 for remote identification of vehicles, even in darkness and / or in weather. The functional safety levels of the RADAR may be ASIL B. The RADAR sensor 860 may use the CAN and / or bus 802 (e.g., to transmit the data generated by the RADAR sensor 860) to control and access data for object tracking, in some examples, Ethernet may be accessed to access raw data. A variety of RADAR sensor types may be used. For example, the RADAR sensors 860 can be freely used as front, rear, and side RADARs. In some examples, pulse Doppler RADAR sensors are used.The RADAR sensors 860 may include various configurations, e.g., narrow field of view long range, large field of view short range, short side coverage, etc. In some examples, a long-range RADAR may be used for adaptive cruise control. Long range RADAR systems can provide a wide field of view realized by two or more independent scans, e.g., within a range of 250 m. RADAR sensors 860 can aid in distinguishing between static and moving objects and can be used by ADAS systems for emergency brake assist and collision warning. Long-range RADAR sensors for long ranges may include monostatic multimode RADAR with multiple (e.g., six or more) fixed RADAR antennas and a high speed CAN and FlexRay interface. In a six antenna example, the central four antennas may generate a focused beam pattern that has been developed to record the environment of the vehicle 800 at higher speeds with minimal interference from traffic in adjacent lanes. The other two antennas can extend the field of view, making it possible to quickly recognize vehicles that are traveling into or leaving the lane of the vehicle 800.For example, mid range RADAR systems may include a range of up to 160 m (forward) or 80 m (rearward) and a field of view of up to 42 degrees (forward) or 150 degrees (rearward). Short range RADAR systems may include, without limitation, RADAR sensors that may be installed at both ends of the rear bumper. When installed at both ends of the rear bumper, such RADAR sensor systems can generate two beams that constantly monitor blind spots in the rear and adjacent the vehicle.Short range RADAR systems may be used in an ADAS system for blind spot detection and / or lane change assistance.The vehicle 800 may also include ultrasonic sensors 862. The ultrasonic sensors 862, which may be located front, rear, and / or at the sides of the vehicle 800, may be used to park and / or create and update an occupancy grid. A plurality of ultrasonic sensors 862 and different ultrasonic sensors 862 may be used for different detection areas (e.g., 2.5 m, 4 m). The ultrasonic sensors 862 may operate at the ASIL B level of functional safety.The vehicle 800 may include LiDAR sensors 864. The LiDAR sensors 864 may be used for object and pedestrian detection, emergency braking, collision avoidance, and / or other functions. The LiDAR sensors 864 may satisfy the functional safety level ASIL B. In some examples, the vehicle 800 may include multiple LiDAR sensors 864 (e.g., two, four, six, etc.) that may use Ethernet (e.g., to provide data to a gigabit Ethernet switch).In some examples, the LiDAR sensors 864 may provide a list of objects and their distances for a 360 degree field of view. Commercially available LiDAR sensors 864 may have an advertised range of about 800 m, an accuracy of 2 cm to 3 cm, and support for a 100 Mbit / s Ethernet connection, for example. In some examples, one or more non-protruding LiDAR sensors 864 may be used. In such examples, the LiDAR sensors 864 may be implemented as a small device that may be embedded in the front, rear, side, and / or corners of the vehicle 800. The LiDAR sensors 864 may provide up to 120 degree horizontal and 35 degree vertical field of view with a range of 200 m in such examples, even for low reflection objects. Front-mounted LiDAR sensors 864 may be configured for a horizontal field of view between 45 degrees and 135 degrees.In some examples, LiDAR technologies such as 3D flash LiDAR may also be used. 3D flash LiDAR uses a laser flash as a transmission source to illuminate the vehicle environment up to about 200 meters. A LiDAR flash unit includes a receptor that captures the transmission time of the laser pulse and the reflected light on each pixel, which in turn corresponds to the range from the vehicle to the objects. Flash LiDAR may allow for the generation of highly accurate and distortion-free images of the environment with each laser flash. In some examples, four LiDAR flash sensors may be employed, one on each side of the vehicle 800. Available 3D flash LiDAR systems include a solid state 3D staging array LiDAR camera without moving parts other than a fan (e.g., a non-scanning LiDAR device). The flash LiDAR device may use a Class I (eye proof) laser pulse at 5 nanoseconds per image and acquire the reflected laser light in the form of 3D point clouds and co-registered intensity data. By using flash LiDAR and because flash LiDAR is a solid state device without moving parts, the LiDAR sensor 864 may be less susceptible to motion blurs, vibrations, and / or shocks.The vehicle may also include IMU sensors 866. The IMU sensors 866 may be located in the center of the rear axle of the vehicle 800 in some examples. The IMU sensors 866 may include, for example, one or more accelerometers, magnetometers, gyroscopes, magnetic compasses, and / or other types of sensors. In some examples, such as in six-axis applications, the IMU sensors 866 may include accelerometers and gyroscopes, while in nine-axis applications, the IMU sensors 866 may include accelerometers, gyroscopes, and magnetometers.In some embodiments, the IMU sensors 866 may be implemented as a miniature GPS-aided inertial navigation system (GPS / INS) that combines micro-electro-mechanical systems (MEMS) inertial sensors, a high-sensitivity GPS receiver, and advanced Kalman filter algorithms to provide estimates of position, velocity, and inclination. In some examples, the IMU sensors 866 may allow the vehicle 800 to estimate heading without input of a magnetic sensor by observing and correlating the changes in speed from the GPS directly on the IMU sensors 866. In some examples, IMU sensors 866 and GNSS sensors 858 may be combined into a single integrated unit.The vehicle may be equipped with microphones 896 placed in and / or around the vehicle 800. The microphones 896 may be used to identify emergency vehicles, among other things.The vehicle may also include any number of camera types, including stereo cameras 868, wide-angle cameras 870, infrared cameras 872, surround cameras 874, long-range and mid-range cameras 898, and / or other camera types. The cameras can capture image data around an entire periphery of the vehicle 800. The types of camera used depend on the embodiments and requirements for the vehicle 800, and any combination of types of camera may be used to ensure the required coverage around the vehicle 800. Moreover, the number of cameras may vary depending on the embodiment. For example, the vehicle may include six cameras, seven cameras, ten cameras, twelve cameras, and / or another number of cameras. The cameras may support gigabit multimedia serial link (GMSL) and / or gigabit Ethernet, for example and without limitation. Each camera is described in this document with reference to FIGS. 8A and 8B.The vehicle 800 may also include vibration sensors 842. The vibration sensors 842 may measure vibrations of components of the vehicle, e.g., axles. Changes in the vibrations can indicate, for example, a change in the road surfaces. In another example, when two or more vibration sensors 842 are used, the differences between the vibrations may be used to determine friction or slippage of the lane surface (e.g., when the difference in vibration exists between an electrically driven and a freely rotating axle).The vehicle 800 may include an ADAS system 838. The ADAS system 838 may include a SoC in some examples. The ADAS system 838 may include autonomous / adaptive / automatic cruise control (ACC), cooperative adaptive cruise control (CACC), forward crash warning (FCW), automatic emergency braking (AEB), lane departure warning (LDW), lane keep assist (LKA), blind spot warning (BSW), rear cross-traffic warning (RCTW), collision warning systems (CWS), The features and functionalities may include lane centering (LC) and / or other features and functionalities.The ACC systems may use RADAR sensors 860, LiDAR sensors 864, and / or cameras. The ACC systems may include longitudinal ACC and / or lateral ACC. The longitudinal ACC monitors and controls the distance to the vehicle immediately in front of the vehicle 800 and automatically adjusts the vehicle speed to maintain a safe distance to the preceding vehicles. The lateral ACC performs the distance measurement and notifies the vehicle 800 to change lanes as needed. Lateral ACC is related to other ADAS applications such as LCA and CWS.CACC uses information from other vehicles that may be received via network interface 824 and / or wireless antenna(s) 826 from other vehicles via a wireless connection or indirectly via a network connection (e.g., via the Internet). Direct connections may be provided via a V2V (vehicle-to-vehicle) communication link, while indirect connections may be an I2V (infrastructure-to-vehicle) communication link. The communication concept V2V typically informs about the immediately preceding vehicles (e.g., vehicles immediately in front of and on the same lane as the vehicle 800), while the communication concept I2V provides information about the further preceding traffic. CACC systems may include one or both of I2V and V2V information sources. Given the information about the vehicles in front of the vehicle 800, CACC could be more reliable and have the potential to improve traffic flows and reduce road jams.FCW systems have been developed to alert the driver of a danger for the driver to take corrective action. FCW systems use a front-facing camera and / or RADAR sensors 860 coupled to a dedicated processor, DSP, FPGA, and / or ASIC electrically coupled to driver feedback, e.g., a display, speaker, and / or vibrating component. FCW systems may issue a warning, e.g., in the form of sound, visual warning, vibration, and / or a rapid brake pulse.AEB systems detect an imminent impact with another vehicle or object and may automatically apply the brakes when the driver does not take corrective action within a particular time or distance parameter. AEB systems may use front-facing cameras and / or RADAR sensors 860 coupled to a dedicated processor, DSP, FPGA, and / or ASIC. When the AEB system detects a hazard, it normally first alerts the driver to take corrective action to avoid the collision. If the driver does not take corrective action, the AEB system may automatically apply the brakes to prevent, or at least mitigate, the effects of the predicted collision. AEB systems may include techniques such as dynamic brake assist and / or emergency braking.LDW systems provide visual, audible, and / or tactile warnings, such as steering wheel or seat vibrations, to warn the driver when the vehicle 800 crosses the lane markings. An LDW system is not activated when the driver indicates an intentional lane change by activating a blinking signal. LDW systems may use front-facing cameras coupled to a dedicated processor, DSP, FPGA, and / or ASIC electrically coupled to driver feedback, e.g., a display, speaker, and / or vibrating component.LKA systems are a variant of LDW systems. LKA systems provide steering inputs or brakes to correct the vehicle 800 when the vehicle 800 exits the lane.BSW systems recognize and warn the driver of vehicles in the blind spot of an automobile. BSW systems may issue a visual, audible, and / or tactile alert indicating that merging or changing lanes is uncertain. The system may issue an additional warning when the driver uses a turn signal. BSW systems may use rear-facing cameras and / or RADAR sensors 860 coupled to a dedicated processor, DSP, FPGA, and / or ASIC electrically coupled to driver feedback, e.g., a display, speaker, and / or vibrating component.RCTW systems may provide visual, audible, and / or tactile notifications when an object outside of the range of the rear camera is detected as the vehicle 800 is backing up. Some RCTW systems have AEBs to ensure that the vehicle's brakes are activated to avoid an accident. RCTW systems may use one or more rear-facing RADAR sensors 860 coupled to a dedicated processor, DSP, FPGA, and / or ASIC electrically coupled to driver feedback, e.g., a display, speaker, and / or vibrating component.Conventional ADAS systems may tend to have false positives, which may be annoying and distracted to the driver, but are generally not catastrophic, as the ADAS systems alert the driver and allow the driver to decide whether a safety condition is actually present and act accordingly. However, in an autonomous vehicle 800, the vehicle 800 itself, in conflicting results, must decide whether to consider the result of a primary or secondary computer (e.g., a first controller 836 or a second controller 836). In some embodiments, the ADAS system 838 may be, for example, a backup and / or secondary computer to provide perception information to a rationality module of the backup computer. On the backup computer rationality monitor, redundant, varied software can be executed on hardware components to detect perception errors and dynamic driving tasks. Outputs from the ADAS system 838 may be provided to a higher level MCU. When outputs from the primary computer and the secondary computer conflict, the parent MCU must determine how the conflict can be matched to ensure safe operation.In some examples, the primary computer may be configured to provide the parent MCU with a confidence value that indicates the confidence of the primary computer in the selected result. If the confidence value exceeds a threshold, the parent MCU may follow the direction of the primary computer regardless of whether the secondary computer provides an conflicting or inconsistent result. If the confidence value does not meet the threshold and the primary and secondary computers indicate different results (e.g., conflict), the parent MCU may decide between the computers to determine the appropriate result.The parent MCU may be configured to run a neural network configured and configured to determine conditions under which the secondary computer issues false alarms based on the outputs of the primary computer and the secondary computer. Thus, the neural networks in the parent MCU may learn when the output of the secondary computer is trusted and when not. For example, if the secondary computer is a RADAR-based FCW system, neural networks in the parent MCU may detect when the FCW system identifies metallic objects that are not actually hazardous, such as a drain grill or a manhole cover that triggers an alarm. If the secondary computer is a camera-based LDW system, a neural network in the parent MCU may learn to override the LDW when cyclists or pedestrians are present and a lane change is actually the safest maneuver. In embodiments that include a neural network executing on the parent MCU, the parent MCU may include at least one DLA or GPU suitable for operating the neural network with the associated memory. In preferred embodiments, the parent MCU may be included and / or included as part of the SoCs 804.In other examples, the ADAS system 838 may include a secondary computer that executes the ADAS functionality using conventional computer vision rules. Therefore, the secondary computer may use classic computer vision rules (if-then), and the presence of a neural network in the parent MCU may improve reliability, security, and performance. For example, the multiple implementation and intentional nonidentity make the overall system more fault tolerant, particularly to faults caused by the functionality of the software (or software-hardware interface). For example, if there is a software fault or error in the software on the primary computer and the non-identical software code on the secondary computer provides the same overall result, the parent MCU may have more confidence in the overall result and the fault in the software or hardware on the primary computer does not cause a significant error.In some examples, the output of the ADAS system 838 may be fed to the primary computer perception block and / or the primary computer dynamic driving task block. For example, if the ADAS system 838 indicates an impact warning due to an object immediately ahead, the perception block may use this information in identifying objects. In other examples, the secondary computer may have its own trained neural network, thus reducing the risk of false positive results, as described herein.The vehicle 800 may also include the infotainment SoC 830 (e.g., an in-vehicle infotainment system (IVI)). Although the infotainment system is shown and described as a SoC, it may not be a SoC and may include two or more separate components. The infotainment SoC 830 may include a combination of hardware and software that may be used to provide audio (e.g., music, a personal digital assistant, navigation instructions, messages, radio, etc.), video (e.g., TV, movies, streaming, etc.), phone (e.g., hands-free function), network connectivity (e.g., LTE, Wi-Fi, etc.), and / or information services (e.g., navigation systems, rear parking assist, a radio data system, vehicle-related information such as fuel level, total distance traveled, brake fluid level, oil level, door up / to, air filter information, etc.) to the vehicle 800. For example, the infotainment SoC 830 may include radios, CD players, navigation systems, video players, USB and Bluetooth connectivity, carputers, in-car entertainment, Wi-Fi, steering wheel audio controls, hands-free voice control, a heads-up display (HUD), an HMI display 834, a telematics device, a control panel (e.g., for control and / or interaction with various components, functions, and / or systems), and / or other components. The infotainment SoC 830 may also be used to provide information (e.g., visual and / or audible) to users of the vehicle, e.g., information from the ADAS system 838, autonomous driving information such as scheduled vehicle maneuvers, trajectories, environmental data (e.g., intersection information, vehicle information, road information, etc.), and / or other information.The infotainment SoC 830 may include GPU functionality. The infotainment SoC 830 may communicate with other devices, systems, and / or components of the vehicle 800 via the bus 802 (e.g., CAN bus, Ethernet, etc.). In some examples, the infotainment SoC 830 may be coupled to a parent MCU such that the infotainment system GPU may perform some self-driving functions if the primary controller 836 (e.g., the vehicle 800 primary and / or backup computer) fails. In such an example, the infotainment SoC 830 may place the vehicle 800 in the safe stop mode as described herein.The vehicle 800 may also include a cluster 832 (e.g., a digital dashboard, an electronic cluster, a digital instrument panel, etc.). The instrument cluster 832 may include a controller and / or supercomputer (e.g., a discrete controller or supercomputer). The instrument cluster 832 may include a number of instruments such as tachometer, fuel level, oil pressure, tachometer, odometer, turn signal, shift position indicator, seatbelt warning light(s), parking brake warning light(s), engine fault indicator(s), airbag (SRS) system information, lighting controls, safety system controls, navigation information, etc. In some examples, information may be displayed and / or shared between infotainment SoC 830 and instrument cluster 832. Therefore, instrument cluster 832 may be included as part of infotainment SoC 830 or vice versa.FIG. 8D is a system diagram for communication between cloud-based servers and the example autonomous vehicle 800 of FIG. 8A, in accordance with some embodiments of the present disclosure. The system 876 may include servers 878, networks 890, and vehicles including vehicle 800. The servers 878 may include a plurality of GPUs 884(A)-884(H) (collectively referred to as GPUs 884), PCIe switches 882(A)-882(H) (collectively referred to as PCIe switches 882), and / or CPUs 880(A)-880(B) (collectively referred to as CPUs 880). The GPUs 884, the CPUs 880, and the PCIe switches may be connected to high speed links such as the NVLink interfaces 888 developed by NVIDIA and / or PCIe connections 886. In some examples, the GPUs 884 are connected via NVLink and / or NVSwitch SoC, and the GPUs 884 and the PCIe switches 882 are connected via PCIe connections. Although eight GPUs 884, two CPUs 880, and two PCIe switches are depicted, this is not intended to be limiting. Depending on the embodiment, each server 878 may include any number of GPUs 884, CPUs 880, and / or PCIe switches. For example, servers 878 may each include eight, sixteen, thirty-two, and / or more GPUs 884.Servers 878 may receive image data representative of images showing unexpected or altered road conditions, such as recently initiated road operations, via networks 890 and from the vehicles. The servers 878 may transmit, via the networks 890 and to the vehicles, neural networks 892, updated neural networks 892, and / or map information 894, including information about traffic and road conditions. The updates to the map information 894 may include updates for the HD map 822, such as information about construction sites, pinholes, detours, floods, and / or other obstacles. In some examples, neural networks 892, updated neural networks 892, and / or map information 894 may result from new training and / or experiences, represented in data from any number of vehicles in the environment, and / or based on training performed at a data center (e.g., using servers 878 and / or other servers).The servers 878 may be used to train machine learning models (e.g., neural networks) based on training data. The training data may be generated by the vehicles and / or generated in a simulation (e.g., using a game engine). In some examples, the training data is marked (e.g., when the neural network benefits from supervised learning) and / or undergoes other preprocessing, while in other examples, the training data is not marked and / or preprocessed (e.g., when the neural network does not require supervised learning). Training may be performed according to one or more classes of machine learning techniques including, but not limited to, courses such as: supervised training, semi-supervised training, unsupervised training, self-learning, reinforcement learning, federated learning, transfer learning, feature learning (including principal component and cluster analyses), multilinear subspace learning, multilinear learning, representation learning (including replacement dictionary learning), rule-based machine learning, anomaly detection, and any variants or combinations thereof. After training the machine learning models, the machine learning models may be used by the vehicles (e.g., transmitted to the vehicles via the network 890) and / or the machine learning models may be used by the servers 878 to remotely monitor the vehicles.In some examples, the server 878 may receive data from the vehicles and apply the data to current real-time neural networks to enable real-time smart inferences. The servers 878 may include deep learning supercomputers and / or dedicated AI computers with GPUs 884, such as DGX and DGX station machines developed by NVIDIA. However, in some examples, the servers 878 may include deep learning infrastructure that uses only CPU-powered data centers.The deep learning infrastructure of the servers 878 may enable fast real-time inference and utilize this function to assess and verify the state of the processors, software, and / or associated hardware in the vehicle 800. For example, the deep learning infrastructure may obtain periodic updates from the vehicle 800, such as a sequence of images and / or objects that the vehicle 800 has localized to this sequence of images (e.g., through computer vision and / or other techniques for classifying machine learning objects). The deep learning infrastructure may operate its own neural network to identify the objects and compare them to the objects identified by the vehicle 800. If the results do not match and the infrastructure concludes that the AI in the vehicle 800 is faulty, the server 878 may send a signal to the vehicle 800 instructing a fail-safe computer of the vehicle 800 to take control, notify passengers, and perform a safe parking maneuver.For inferencing, the servers 878 may include the GPUs 884 and one or more programmable inference accelerators (e.g., NVIDIA TensorRT). The combination of GPU-based servers and inference acceleration may enable real-time responsiveness. In other examples, e.g., with less critical performance, servers with CPUs, FPGAs, and other processors may be used for inference.EXAMPLE COMPUTING DEVICEFIG. 9 is a block diagram of an example computing device 900 suitable for use in implementing some embodiments of the present disclosure, including one or more functions of the driving environment simulation platform 100 and / or the tile surface texture mapping function 130. Computing device 900 may include an interconnect system 902 that directly or indirectly couples the following devices: memory 904, one or more central processors (CPUs) 906, one or more graphics processors (GPUs) 908, a communication interface 910, input / output (I / O) ports 912, input / output components 914, a power supply 916, and one or more presentation components 918 (e.g., displays), and one or more logic units 920. In at least one embodiment, computing device(s) 900 may include one or more virtual machines (VMs) and / or each of their components may include virtual components (e.g., virtual hardware components). As non-limiting examples, one or more of the GPUs 908 may include one or more vPUs, one or more of the CPUs 906 may include one or more vCPUs, and / or one or more of the logic units 920 may include one or more virtual logic units. Computing device(s) 900 may include discrete components (e.g., a full GPU for computing device 900), virtual components (e.g., a portion of a GPU for computing device 900), or a combination thereof.Although the various blocks of FIG. 9 are shown as being connected to lines via the connection system 902, this is not intended to be limiting and is for clarity only. For example, in some embodiments, a presentation component 918, such as a display device, may be considered an I / O component 914 (e.g., when the display is a touch screen). As another example, CPUs 906 and / or GPUs 908 may include memory (e.g., memory 904 may be representative of a storage device other than the memory of GPUs 908, CPUs 906, and / or other components). In other words, the computing device from FIG. 9 is merely illustrative. Categories such as "workstation," "server," "laptop," "desktop," "tablet," "client device," "mobile device," "handheld device," "game console," "electronic control unit (ECU)," "virtual reality system," and / or other device or system types are not distinguished, as all are within the scope of the computing device of FIG. 9.The interconnect system 902 may represent one or more interconnects or buses, e.g., an address bus, a data bus, a control bus, or a combination thereof. The interconnect system 902 may include one or more types of buses or interconnects, such as an industry standard architecture (ISA) bus, an extended industry standard architecture (EISA) bus, a video electronics standards association (VESA) bus, a peripheral component interconnect (PCI) bus, a peripheral component interconnect (PCIe) bus, and / or another type of bus or interconnect. In some embodiments, there are direct connections between components. As an example, the CPU 906 may be directly connected to the memory 904. In addition, the CPU 906 may be directly connected to the GPU 908. In the case of direct or point-to-point interconnection between components, the interconnect system 902 may include a PCIe connection for performing the interconnection. In these examples, a PCI bus need not be included in computing device 900. In some embodiments, one or more of the functions of the driving environment simulation platform 100 and / or the tile surface texture mapping function 130 described herein may be performed by the CPU 906 and / or the GPU 908.The memory 904 may include a variety of computer readable media. The computer readable media may be any available media that can be accessed by the computing device 900. The computer readable media may include both volatile and non-volatile media, as well as removable and non-removable media. By way of example, and not limitation, the computer readable media may include computer storage media and communication media.The computer storage medium may include both volatile and non-volatile media and / or removable and non-removable media implemented in any method or technology for storing information such as computer readable instructions, data structures, program modules, and / or other types of data. For example, memory 904 may store computer readable instructions (e.g., representing one or more programs and / or program elements, e.g., an operating system. Storage media for computers include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVDs) or other optical media, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by computing device 900. As used herein, the storage media for computers do not include signals per se.The storage media of the computer may include computer readable instructions, data structures, program modules, and / or other types of data in a modulated data signal, such as a carrier wave or other transport mechanism, and includes any information media. The term "modulated data signal" may refer to a signal that has adjusted or altered one or more of its characteristics to encode information in the signal. By way of example, and not limitation, the computer storage media may include wired media such as a wired network or direct wired connection, as well as wireless media such as acoustic, RF, infrared, and other wireless media. Combinations of the above should also be included within the scope of computer readable media.The CPUs 906 may be configured to execute at least some of the computer readable instructions to control one or more components of the computer 900 to execute (e.g., processed by the driving environment simulation platform 100 and / or the tile surface structure mapping function 130) one or more of the methods and / or processes described herein. The CPUs 906 may each include one or more cores (e.g., one, two, four, eight, twenty-eight, seventy-two, etc.) capable of processing a plurality of software threads simultaneously. CPUs 906 may include any type of processor and may include different types of processors (e.g., processors with fewer cores for mobile devices and processors with more cores for servers), depending on the type of computing device 900 implemented. Depending on the computing device 900, it may be, for example, an advanced RISC machine (ARM) processor with reduced instruction set computing (RISC) or an x86 processor with complex instruction set computing (CISC). Computing device 900 may include one or more CPUs 906 in addition to one or more microprocessors or additional coprocessors, such as mathematical coprocessors.The GPUs 908 may be further or alternatively configured by the CPUs 906 to execute at least some computer readable instructions to control one or more components of the computer 900 to perform one or more of the methods and / or processes described herein. One or more GPUs 908 may be an integrated GPU (e.g., with one or more CPUs 906) and / or one or more GPUs 908 may be a separate GPU. In embodiments, one or more GPUs 908 may be a coprocessor of one or more CPUs 906. The GPUs 908 may be used by the computing device 900 to render graphics (e.g., 3D graphics) or perform general computations. For example, the GPUs 908 may be used for general purpose computing on GPUs (GPGPUs). The GPUs 908 may include hundreds or thousands of cores that may process hundreds or thousands of software threads simultaneously. The GPUs 908 may generate pixel data for output images in response to rendering commands (e.g., rendering commands from the CPUs 906 received via a host interface). The GPUs 908 may include graphics memory, such as display memory, for storing pixel data or other suitable data, such as GPGPU data. The display memory may be included as part of the memory 904. The GPUs 908 may include two or more GPUs operating in parallel (e.g., via a connection). The connection may connect the GPUs directly (e.g., via NVLINK) or connect the GPUs via a switch (e.g., via NVSwit). When combined together, each GPU 908 may generate pixel data or GPGPU data for different portions of an output or for different outputs (e.g., a first GPU for a first image and a second GPU for a second image). Each GPU may contain its own memory or share memory with other GPUs.The logic units 920 may be further or alternatively configured by the CPUs 906 and / or the GPUs 908 to execute at least some computer readable instructions to control one or more components of the computer 900 to perform one or more of the methods and / or processes described herein. In embodiments, the CPUs 906, the GPUs 908, and / or the logic units 920 may perform, discretely or collectively, any combination of the methods, processes, and / or portions thereof. One or more of the logic units 920 may be part of one or more CPUs 906 and / or GPUs 908 and / or one or more of the logic units 920 may be discrete components or otherwise external to the CPUs 906 and / or the GPUs 908. In embodiments, one or more logic units 920 may be a coprocessor of one or more CPUs 906 and / or one or more GPUs 908.Examples of the logic units 920 include one or more processor cores and / or components thereof, such as computing units (DPUs), tensor cores (TCs), tensor processing units (TPUs), pixel visual cores (PVCs), vision processing units (VPUs), graphics processing clusters (GPCs), texture processing clusters (TPCs), streaming multiprocessors (SMs), tree traversal units (TTUs), artificial intelligence (AIAS), Adders (AIAS), deep learning adders (DLAs), arithmetic logic units (ALUs), application specific integrated circuits (ASICs), floating point units (FPUs), input / output (I / O) elements (input / output - I / O), peripheral component interconnect (PCI) or peripheral component interconnect express (PCIe) elements, and / or the like.Communication interface 910 may include one or more receivers, transmitters, and / or transceivers that enable computing device 900 to communicate with other computing devices over an electronic communication network, including wired and / or wireless communication. The communication interface 910 may include components and functionality that facilitate communication over a variety of networks, e.g., wireless networks (e.g., Wi-Fi, Z-Wave, Bluetooth, Bluetooth LE, ZigBee, etc.), wired networks (e.g., communication over Ethernet or InfiniBand), low-power wide area networks (e.g., LoRaWA, Sigfox, etc.), and / or the Internet. In one or more embodiments, logic unit(s) 920 and / or communication interface 910 may include one or more computing devices (DPUs) to directly transmit data received over a network and / or over connection system 902 to one or more GPU(s) 908 (e.g., to a memory thereof).I / O ports 912 may enable computing device 900 to be logically coupled to other devices, including I / O components 914, presentation component(s) 918, and / or other components, some of which may be incorporated (e.g., integrated) into computing device 900. I / O components 914 include a microphone, a mouse, a keyboard, a joystick, a game pad, game controllers, satellite dish, scanner, printer, wireless device, etc. The I / O components 914 may provide a natural user interface (NUI) that processes air gestures, voice, or other physiological inputs generated by a user. In some cases, inputs may be transmitted to a suitable network element for further processing. An NUI may implement any combination of speech recognition, tactile recognition, facial recognition, biometric recognition, gesture recognition on both the screen and near the screen, air gestures, head and eye tracking, and touch recognition (as described in more detail below) connected to a display of computing device 900. The computing device 900 may include depth cameras, such as stereoscopic camera systems, infrared camera systems, RGB camera systems, touch screen technology, and combinations thereof, for gesture detection and recognition. In addition, computing device 900 may include accelerometers or gyroscopes (e.g., as part of an inertial measurement unit (IMU)) that enable motion detection. In some examples, the output of the accelerometers or gyroscopes may be used by computing device 900 to represent immersive augmented reality or virtual reality.The power supply 916 may include a hardwired power supply, a battery power supply, or a combination thereof. Power supply 916 may provide power to computing device 900 to enable the components of computing device 900 to operate.The presentation components 918 may include a display (e.g., a monitor, a touch screen, a television screen, a heads-up display (HUD), other types of display, or a combination thereof), speakers, and / or other presentation components. The presentation components 918 may receive data from other components (e.g., GPUs 908, CPUs 906, GPUs, etc.) and output the data (e.g., as image, video, sound, etc.). In some embodiments, the HMI 185 may be implemented using one or more presentation components 918.EXAMPLE DATA CENTERFIG. 10 shows an example of a data center 1000 that may be used in at least one embodiment of the present disclosure (e.g., to remotely execute each of the components described herein). Data center 1000 may include a data center infrastructure layer 1010, a framework layer 1020, a software layer 1030, and / or an application layer 1040. In some embodiments, one or more of the driving environment simulation platform 100 and / or tile surface texture mapping function 130 functions described herein may be performed by the data center 1000.As shown in FIG. 10, data center infrastructure layer 1010 may include resource orchestrator 1012, grouped computing resources 1014, and node computing resources ("node CRs") 1016( 1)- 1016(N), "N" representing any integer positive number. In at least one embodiment, node C.R.s 1016( 1)- 1016(N) may include, but are not limited to, any number of central processing units (CPUs) or other processors (including DPUs, accelerators, field programmable gate arrays (FPGAs), graphics processors or graphics processing units (GPUs), etc.), memory devices (e.g., dynamic read-only memories), data storage devices (e.g., solid state or hard disk drives), network input / output (NW I / O) devices, network switches, virtual machines (VMs), power modules, and cooling modules, etc. In some embodiments, one or more node C.R.s among node C.R.s 1016( 1)- 1016(N) may correspond to a server having one or more of the computing resources mentioned above. Moreover, in some embodiments, the nodes C.R.s 1016( 1)- 1061(N) may include one or more virtual components, such as vPUs, vCPUs, and / or the like, and / or one or more of the nodes C.R.s 1016( 1)- 1016(N) may correspond to a virtual machine (VM). In at least one embodiment, grouped computing resources 1014 may include separate groupings of node CR 1016 residing in one or more racks (not shown) or in many racks residing in data centers at different geographic locations (also not shown). Separate groupings of node CR 1016 within the grouped computing resources 1014 may include grouped computing, network, memory, or storage resources, which may be configured or allocated to support one or more computing loads. In at least one embodiment, multiple node CR 1016, including CPUs, GPUs, DPUs, and / or processors, may be grouped into one or more racks to provide computing resources to support one or more computational loads. The one or more racks may also include any number of power modules, cooling modules, and network switches in any combination. In some embodiments, one or more of the functions of the driving environment simulation platform 100 and / or the tile surface texture mapping function 130 described herein may be performed by one or more of the node CRs 1016( 1)- 1016(N).The resource orchestrator 1012 may configure or otherwise control one or more node CR 1016( 1)- 1016(N) and / or grouped computing resources 1014. In at least one embodiment, resource orchestrator 1012 may include a software design infrastructure (SDI) manager for data center 1000. The resource orchestrator 1012 may include hardware, software, or a combination thereof.In at least one embodiment, as shown in FIG. 10, framework layer 1020 may include a task scheduler 1032, a configuration manager 1034, a resource manager 1036, and a distributed file system 1038. The framework layer 1020 may include a framework to support software 1032 of the software layer 1030 and / or one or more application(s) 1042 of the application layer 1040. Software 1032 or application(s) 1042 may include web-based service software or applications, such as provided by Amazon Web Services, Google Cloud, and Microsoft Azure. The framework layer 1020 may be any type of free and open source software web application framework, such as, but not limited to, Apache SparkTM (hereafter "Spark"), which may use a distributed file system 1038 to process large amounts of data (e.g., big data). In at least one embodiment, task scheduler 1032 may include a spark driver to facilitate scheduling workloads supported by different layers of data center 1000. The configuration manager 1034 may be capable of configuring different layers, e.g., the software layer 1030 and the framework layer 1020 including spark and the distributed file system 1038, to support large volume processing. The resource manager 1036 may be capable of managing clustered or grouped computing resources allocated or allocated to support the distributed file system 1038 and the task scheduler 1032. In at least one embodiment, clustered or grouped computing resources may include grouped computing resource 1014 at data center infrastructure layer 1010. The resource manager 1036 and the resource orchestrator 1012 may coordinate to manage these allocated or allocated computing resources.In at least one embodiment, software 1032 included in software layer 1030 may include software used by at least portions of node CR 1016( 1)- 1016(N), grouped computing resources 1014, and / or distributed file system 1038 of framework layer 1020. One or more types of software may include, but are not limited to, Internet web page search software, email virus scan software, database software, and streaming video content software.In at least one embodiment, application(s) 1042 included in application layer 1040 may include one or more types of applications used by at least portions of node CR 1016( 1)- 1016(N), grouped computing resources 1014, and / or distributed file system 1038 of framework layer 1020. One or more types of applications may include, but are not limited to, any number of a genomics application, a cognitive computing application, and a machine learning application, including training or derivation software, machine learning framework software (e.g., PyTor, TensorFlow, Coffee, etc.), and / or other machine learning applications used in connection with one or more embodiments.In at least one embodiment, any of configuration manager 1034, resource manager 1036, and resource orchestrator 1012 may implement any number and type of self-modifying actions based on any amount and type of data captured in any technically feasible manner. Self-modifying actions may relieve a data center operator of data center 1000 from making potentially bad configuration decisions and may avoid unutilized and / or malfunctioning portions of a data center.Data center 1000 may include tools, services, software, or other resources to train one or more machine learning models or predict or derive information using one or more machine learning models, in accordance with one or more embodiments described herein. For example, a machine learning model(s) may be trained by computing weight parameters according to a neural network architecture using software and / or compute resources described above with respect to data center 1000. In at least one embodiment, trained or deployed machine learning models corresponding to one or more neural networks may be used to infer or predict information using resources described above with respect to data center 1000 by using weighting parameters calculated by one or more training techniques described herein.In at least one embodiment, data center 1000 may use CPUs, application specific integrated circuits (ASICs), GPUs, FPGAs, and / or other hardware (or corresponding virtual computing resources) to perform training and / or inferencing with resources described above. Moreover, one or more of the software and / or hardware resources described above may be configured as a service that allows the user to train or infer information such as image recognition, speech recognition, or other artificial intelligence services.EXAMPLE NETWORK ENVIRONMENTSNetwork environments suitable for use in implementing embodiments of the disclosure may include one or more client devices, servers, network attached storage (NAS), other backend devices, and / or other device types. The client devices, servers, and / or other device types (e.g., each device) may be implemented on one or more instances of the computing device(s) 900 of FIG. 9-e.g., each device may include similar components, features, and / or functions of the computing device(s) 900. When backend devices (e.g., servers, NAS, etc.) are implemented, the backend devices may also be part of a data center 1000, an example of which is described in more detail in FIG. 10 herein.Components of a network environment may communicate with each other over one or more networks, which may be wired, wireless, or both. The network may include multiple networks or a network of networks. For example, the network may include one or more wide area networks (WAN), one or more local area networks (LANs), one or more public networks such as the Internet and / or a public switched telephone network (PSTN), and / or one or more private networks. If the network includes a wireless telecommunications network, components such as a base station, a communication tower, or even access points (as well as other components) may provide wireless connectivity.Compatible network environments may include one or more peer-to-peer network environments - in this case, a server may not be included in a network environment - and one or more client-server network environments - in this case, one or more servers may be included in a network environment. In peer-to-peer network environments, the functionality described herein with respect to one or more servers may be implemented on any number of client devices.In at least one embodiment, a network environment may include one or more cloud-based network environments, a distributed computing environment, a combination thereof, etc. A cloud-based network environment may include a framework layer, a job scheduler, a resource manager, and a distributed file system implemented on one or more servers, which may include one or more core network servers and / or edge servers. A framework layer may include a framework to support software of a software layer and / or one or more applications of an application layer. The software or application(s) may each include web-based service software or applications. In embodiments, one or more of the client devices may use the web-based service software or applications (e.g., by accessing the service software and / or applications via one or more application programming interfaces (API)). The framework layer may be a type of free and open source software web application framework, such as, but not limited to, a distributed file system for large volume data processing (e.g., big data).A cloud-based networking environment may provide cloud computing and / or cloud storage that performs any combination of computing and / or storage functions described herein (or one or more portions thereof). Each of these various functions may be distributed across multiple locations of central or core servers (e.g., from one or more data centers, which may be distributed across a state, region, country, globe, etc.). If a connection to a user (e.g., a client device) is relatively close to one or more edge servers, one or more core servers may assign at least a portion of the functionality to the edge server or servers. A cloud-based network environment may be private (e.g., limited to a single organization), may be public (e.g., available to many organizations), and / or a combination thereof (e.g., a hybrid cloud environment).The client device(s) may include at least one of the components, features, and functionality of the computing device(s) 900 described herein with reference to FIG. 9. By way of example, and not limitation, a client device may be a personal computer (PC), laptop computer, mobile device, smart phone, tablet computer, smart watch, portable computer, personal digital assistant (PDA), MP3 player, virtual reality headset, global positioning system or device (GPS), video player, video camera, monitoring device or system, vehicle, boat, airship, virtual machine, drone, robot, portable communication device, hospital device, gaming device or system, entertainment system, vehicle computer system, embedded system controller, remote control, home appliance, consumer electronics device, workstation, edge device, Any combination of these outlined devices or any other suitable device may be implemented.The disclosure may be described in the general context of computer code or machine-usable instructions, including computer-executable instructions, such as program modules, executed by a computer or other machine, such as a personal data assistant or other handheld device. Generally, program modules including routines, programs, objects, components, data structures, etc., refer to code that performs particular tasks or implements particular abstract data types. The disclosure may be practiced in a variety of system configurations, including handheld devices, consumer electronics, general purpose computers, more specific computing devices, etc. The disclosure may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network.As used herein, a recitation of "and / or" with respect to two or more elements should be construed to mean only one element or a combination of elements. For example, "element A, element B, and / or element C" may include only element A, only element B, only element C, element A and element B, element A and element C, element B and element C, or elements A, B, and C. In addition, "at least one of element A or element B" may include at least one of element A, at least one of element B, or at least one of element A and at least one of element B. Further, "at least one of element A and element B" may include at least one of element A, at least one of element B, or at least one of element A and at least one of element B.The subject matter of the present disclosure is specifically described herein to meet legal requirements. However, the description itself is not intended to limit the scope of this disclosure. Rather, the inventors have contemplated that the claimed subject matter could be practiced otherwise to include other steps or combinations of steps similar to those described herein in connection with other current or future technologies. Moreover, although the terms "step" and / or "block" may be used herein to refer to various elements of the methods used, the terms should not be construed to imply a particular order among or between various steps disclosed herein unless the order of the individual steps is explicitly described.References included in the specificationThis list of documents cited by the applicant has been produced in an automated manner and is only included for the better information of the reader. The list is not part of the German patent application or utility model application. The DPMA does not take any adhesion for any faults or omissions.Patent Literature citedUS 16 / 186,473

[0061] US 16 / 366,506

[0063] US 62 / 644,385

[0066] US 62 / 644,386

[0066] US 62 / 644,601

[0066] US 62 / 644,806

[0066] US 16 / 354,983

[0066] US 16 / 355,214

[0066] US 16 / 101,232

[0151] Cited Non-Patent LiteratureTaxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles" (Standard No. J3016-201806 published June 15, 2018, Standard No. J3016-20169 published September 30, 2016

[0108]

Claims

One or more processors, comprising processing circuitry to: correlate one or more surfaces of an environment represented by map data with one or more regions of a three-dimensional, 3D, polygonal topology network corresponding to the environment; determine one or more boundary lines corresponding to one or more lanes of the one or more surfaces based at least on the map data; calculate one or more surface lines associated with the one or more lanes based at least on the one or more boundary lines; generate a texel image representing a surface texture appearance for the one or more lanes, wherein individual texels of the texel image are adjusted based on at least one function of distance to at least one surface line of the one or more surface lines; generating a rendering of the one or more surfaces in a simulation environment based at least on mapping the individual texels of the texel image to one or more vertices of the 3D polygon topology network.The one or more processors of claim 1, wherein the one or more processors are further configured to generate a surface texture for at least a portion of the simulation environment based at least on the 3D polygon topology network.The one or more processors of claim 1 or 2, wherein the texel image comprises a texture map.The one or more processors of any preceding claim, wherein the one or more processors are further configured to: assign UV coordinates to the one or more vertices of the 3D polygon topology network, wherein the texel image is generated in a UV coordinate space; and map the one or more vertices of the 3D polygon topology network to the texel image based at least on the UV coordinates.The one or more processors of any preceding claim, wherein to generate the texel image, the one or more processors are further configured to disassemble at least one segment of the 3D surface topology network into a plurality of segments and adapt the plurality of segments to the boundaries of the texel image using a UV packaging method.The one or more processors of any preceding claim, wherein individual vertices of the one or more vertices comprise a data structure that describes one or more visual artifacts, wherein the one or more visual artifacts are used to adjust an appearance of the one or more surfaces based at least on the individual texels of the texel image.The one or more processors of any preceding claim, wherein the individual texels of the texel image represent a combination of a base texture image and one or more texture masking characteristics that adjust the base texture image in appearance based at least on the function of distance to one or more of the one or more surface lines.The one or more processors of any preceding claim, wherein the one or more surface lines are associated with discoloration of the one or more surfaces based on at least one of: tire debris, vehicle fluid leaked contamination, contact damage, or accumulated road debris.The one or more processors of any preceding claim, wherein the one or more processors are further configured to: collect the rendering in a dataset of renderings of a plurality of surfaces; and train a machine learning model to operate an ego vehicle based at least on the dataset of renderings.The one or more processors of any preceding claim, wherein the one or more processors are further configured to generate a scene description data file representing the rendering of the one or more surfaces; and execute the simulation environment rendering the rendering of the one or more surfaces based at least on the scene description data file.The one or more processors of any preceding claim, wherein the processing circuitry is included in at least one of: an autonomous or semi-autonomous machine control system; an autonomous or semi-autonomous machine perception system; a system for performing simulation operations; a system for performing digital twin operations; a system for performing light transport simulation; a system for performing collaborative content generation for three-dimensional assets; a system for performing deep learning operations; a system for performing remote operations; a system for performing real-time streaming; a system for generating or presenting one or more of augmented reality content, virtual reality content, or mixed reality content; a system implemented using an edge device; a system implemented using a robot; a system for performing conversation AI operations; a system implementing one or more vision language models, VLMs; a system implementing one or more large language models, LLMs; a system for generating synthetic data; a system for generating synthetic data using AI; a system including one or more virtual machines, VMs; a system implemented at least partially in a data center; or a system implemented at least partially using cloud computing resources.A system comprising one or more processors to: generate a set of texels representing a surface texture for one or more surfaces of a simulated environment, wherein individual texels of the set of texels are adjusted based on at least one function of distance to one or more surface lines derived from map data representing one or more drivable surfaces of the simulated environment; and generate a rendering of the one or more drivable surfaces based on at least one mapping of the individual texels of the set of texels to one or more vertices of a 3D polygon topology network representing a surface structure for at least a portion of the simulated environment.The system of claim 12, wherein the one or more processors are further configured to: assign UV coordinates to the one or more vertices of the 3D polygon topology network, wherein the set of texels is generated in a UV coordinate space; and map the one or more vertices of the 3D polygon topology network to the individual texels from the set of texels based at least on the UV coordinates.The system of claim 12 or 13, wherein the individual texels of the set of texels represent a combination of a baseline texture image and one or more texture masking characteristics that adjust the baseline texture image in appearance based at least on the function of distance to at least one surface line of the one or more surface lines.The system of any of claims 12 to 14, wherein to generate the set of texels, the one or more processors are further configured to disassemble at least one segment of the 3D surface topology network into a plurality of segments and adapt the plurality of segments to the boundaries of the set of texels using a UV packaging method.The system of any of claims 12 to 15, wherein the one or more processors are further configured to perform modulation in the intensity of adjustments in appearance along a direction of travel of one or more drivable surfaces of the one or more surfaces.The system of any of claims 12 to 16, wherein the one or more processors are further configured to apply a decrease to appearance adjustments based at least on the function of distance to the one or more surface lines.The system of any of claims 12 to 17, wherein the one or more processors are further configured to: store the rendering in a dataset of renderings; and train a machine learning model to operate an ego vehicle based at least in part on the renderings of the dataset of renderings.The system of any of claims 12 to 18, wherein the system is included in at least one of: an autonomous or semi-autonomous machine control system; an autonomous or semi-autonomous machine perception system; a system for performing simulation operations; a system for performing digital twin operations; a system for performing light transport simulation; a system for performing collaborative content generation for three-dimensional assets; a system for performing deep learning operations; a system for performing remote operations; a system for performing real-time streaming; a system for generating or presenting one or more of augmented reality content, virtual reality content, or mixed reality content; a system implemented using an edge device; a system implemented using a robot; a system for performing conversation AI operations; a system implementing one or more vision language models, VLMs; a system implementing one or more large language models, LLMs; a system for generating synthetic data; a system for generating synthetic data using AI; a system including one or more virtual machines, VMs; a system implemented at least partially in a data center; or a system implemented at least partially using cloud computing resources.A method comprising: generating a textured rendering of one or more road surfaces in a simulated environment based at least on mapping one or more individual texels to one or more vertices of a 3D polygon topology network representing a surface texture for at least a portion of the simulated environment, wherein the one or more individual texels are adjusted based on at least one function of distance to one or more surface lines derived from map data representing one or more drivable road surfaces.

Images