{"id":752,"date":"2021-07-25T16:00:00","date_gmt":"2021-07-25T15:00:00","guid":{"rendered":"https:\/\/www.geonatives.org\/?p=752"},"modified":"2022-01-03T21:02:00","modified_gmt":"2022-01-03T20:02:00","slug":"rules-vs-reality-procedural-environment-generation","status":"publish","type":"post","link":"https:\/\/www.geonatives.org\/?p=752","title":{"rendered":"Expert Talk with AnteMotion: Rules vs Reality – Procedural Environment Generation"},"content":{"rendered":"\n

(4 min read)<\/sub><\/p>\n\n\n\n

As so often in life, rules may clash with reality. But in simulation and geodata business, rules are an essential part of creating reality\u2019s digital twin. Applied on a larger scale in a tool chain, rule-based procedural environment generation is a convenient way of increasing the amount of data for developing, training, and testing mobility systems.<\/em><\/p>\n\n\n\n

In early July 2021, GEONATIVES met online with Luca Gasbarro of AnteMotion<\/a> to talk about his experience and strategy with respect to procedurally generated environments. <\/p>\n\n\n\n

\"\"<\/figure><\/div>\n\n\n\n

AnteMotion is a provider of, but not limited to, a simulation platform that consists of a simulation framework, an Unreal-based render engine, and a procedural environment generation toolset. Everything is accompanied by corresponding engineering services.<\/p>\n\n\n\n

Our main interest was on the procedural generation tools. As we learned, AnteMotion is following four different paths:<\/p>\n\n\n\n

  1. Scrape sources of GIS data (i.e., HERE HD Live Maps, TomTom HD Maps, etc.) to create automatically the OpenDRIVE road network file.<\/li>
  2. Use an (either manually modelled or from automatical scraper) OpenDRIVE file\u2019s semantic road information up to the sidewalks (inclusive) to generate a virtual world around this core network based and high level semantical rules, so that the same roads may be surrounded by residential, industrial, urban and other content; lane attributes, road marks, traffic signs and traffic lights are extracted from the OpenDRIVE file itself. The pipeline can be extended and personalized by including custom procedural rules. (For more details, see “Procedural Worlds – Modeling of infinite 3D scenario variations for virtual AV\/ADAS testing<\/a>“)<\/li>
  3. Use the same information as above (2), plus other OpenDRIVE file\u2019s information about objects (OpenDRIVE comes with object tags for elements in the general 3d environment which are not relevant to the so-called \u201croad logics\u201d). For various customers, \u201cuser data tags\u201d may be included in the files that allow for the specification of certain road-side features and for the harmonization of libraries of 3d objects. \u201cUser data tags\u201d in the OpenDRIVE file can be customized on user needs to specific road-side features or for the harmonization of 3d assets libraries.<\/li>
  4. Start with the same pipeline as in point (2), including also other sources for extra data information (e.g. GIS databases, OpenStreetMap, terrain elevation maps, etc.) to create a \u201cdigital sibling\u201d of the environment.<\/li><\/ol>\n\n\n\n

    For more in-depth technical explanation the functionality of the pipeline, see “Procedural Worlds – How It Works (In-Depth Overview<\/a>“).<\/p>\n\n\n\n

    The key to any of these paths \u2013 and one of our key questions concerning procedural generation \u2013 is the definition of the applicable rules. AnteMotion is performing their own development with a more-or-less generic approach also in terms of country-specific adaptation. This means, that, as of now, surroundings do not represent a specific country\u2019s features \u2013 they look quite Western European, though \u2013 but aim to provide an object composition that feels \u201cnatural\u201d to the driver \u2013 and the sensors. In the long term, more country feature packages could be added.<\/p>\n\n\n\n