Currently, the navigation mesh encodes a 3D representation of the otherwise 2D world. here could be multiple polygons that contain a single point that project to the same location on the canonical ground plane. Therefore, when defining the position of an element, it's simple "(x, y)" position may be insufficient.
This issue has given rise to the NavMeshGenerator. This generator is essentially the explicit generator but with some additional guidance about the navigation mesh "group" that would be favored in positioning the agent.
However, that's a very clunky solution (and certainly doesn't afford setting up regular grids of agents on multiple levels -- i.e., other agent generators are useless in this regard.
Furthermore, it doesn't solve the problem of goal placement. The position of a goal could like on one of multiple layers and likewise needs to be informed of how it disambiguates those levels. (The current behavior is to pick the "highest" applicable layer.)
Proposed solution
Every element that may have to be placed w.r.t. to something (nav meshes, roadmaps, whatever) will be accompanied by "placement hints". In essence, a placement hint is a key-value pair. The element being placed knows nothing about the semantics of the key-value pairs; it simply stores them. When placing an element, the placing structure queries it for placement hints based on its (possibly) unique key. Or, if not unique, the key(s) that it has documented it cares about. It then retrieves the corresponding value and attempts to parse it according to its own logic.
An element can end up possessing multiple key-value pairs. None of them might be used during any given simulation. At this point, it seems it would be a feature of AgentGenerator and Goal instances (possibly GoalSets with some kind of Goal inheritance). Its syntax would look something like:
In the example, some generic Generator tag has two children PlacementHint tags. One with the nav_mesh key and one with the other_thing key. The values are arbitrary -- a list of strings or a range of values in the two cases, respectively.
Problem
Currently, the navigation mesh encodes a 3D representation of the otherwise 2D world. here could be multiple polygons that contain a single point that project to the same location on the canonical ground plane. Therefore, when defining the position of an element, it's simple "(x, y)" position may be insufficient.
This issue has given rise to the
NavMeshGenerator. This generator is essentially the explicit generator but with some additional guidance about the navigation mesh "group" that would be favored in positioning the agent.However, that's a very clunky solution (and certainly doesn't afford setting up regular grids of agents on multiple levels -- i.e., other agent generators are useless in this regard.
Furthermore, it doesn't solve the problem of goal placement. The position of a goal could like on one of multiple layers and likewise needs to be informed of how it disambiguates those levels. (The current behavior is to pick the "highest" applicable layer.)
Proposed solution
Every element that may have to be placed w.r.t. to something (nav meshes, roadmaps, whatever) will be accompanied by "placement hints". In essence, a placement hint is a key-value pair. The element being placed knows nothing about the semantics of the key-value pairs; it simply stores them. When placing an element, the placing structure queries it for placement hints based on its (possibly) unique key. Or, if not unique, the key(s) that it has documented it cares about. It then retrieves the corresponding value and attempts to parse it according to its own logic.
An element can end up possessing multiple key-value pairs. None of them might be used during any given simulation. At this point, it seems it would be a feature of
AgentGeneratorandGoalinstances (possiblyGoalSets with some kind ofGoalinheritance). Its syntax would look something like:In the example, some generic
Generatortag has two childrenPlacementHinttags. One with thenav_meshkey and one with theother_thingkey. The values are arbitrary -- a list of strings or a range of values in the two cases, respectively.