Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Element placement in velocity components #143

Open
curds01 opened this issue Dec 30, 2019 · 0 comments
Open

Element placement in velocity components #143

curds01 opened this issue Dec 30, 2019 · 0 comments
Assignees

Comments

@curds01
Copy link
Collaborator

curds01 commented Dec 30, 2019

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 AgentGenerator and Goal instances (possibly GoalSets with some kind of Goal inheritance). Its syntax would look something like:

...
 <Generator ...>
    <PlacementHint key="nav_mesh">group1, group2</PlacementHint>
    <PlacementHint key="other_thing">1-10</PlacementHint>
 </Generator>

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.

@curds01 curds01 self-assigned this Dec 30, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant