You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Player space targets are targets that are specified in spawn eccentricity (azimuth/elevation) relative to the player view direction at spawn time as opposed to being fixed in the world. Note that currently player space targets do not track the player if they move, so in a way they are also "world space" coordinates.
Originally our assumption was that all targets would eventually be specified in world space, but recent discussions have indicated a desire to maintain support for player-space targets. We can still choose to drop support for player space targets, but if so we should formalize this to discourage continued use of their specification.
If we decide to continue to support player space targets we should consider:
Adding support for keeping the targets locked to the player if they are allowed to move around the scene
Adding support for directly recording target azim/elev from the view position as opposed to just cartesian coordinates
Providing the size/distance/motion/jump/spawn location for the target in consistent units (i.e. ° and °/s)
Allowing for alternate specifications of size and spawn eccentricity including:
Support for circular/elliptic spawn regions (as opposed to rectangular), interacts w/ "coupled spawn constraints" below
Support for ID-based spawn mechanics (ID + width or ID + eccentricity)
Support for coupled horizontal/vertical spawn constraints to create continuous regions (if eccX > X0, eccY ∈ [Y0, Y1] else eccY ∈ [Y2, Y3])
Note that implementing much of this will break support for the exact target motion provided in previous experiments. It may be worth formalizing this in documentation and referring to older releases to reproduce historical target motion as opposed to continuing to support it directly.
Some of the concepts described above (specifically logging target angular position and specifying target ID as opposed to width) might also be interesting to consider for adoption in world-space targets as well, though it is not entirely clear how some of this could be implemented (constant ID would require the target resize as it moves away from the camera).
The text was updated successfully, but these errors were encountered:
In addition to the feature described above it might be nice to add an eccMode parameter to allow us to control how spawn eccentricity is controlled. This would allow us to implement a "circular" mode in addition to the 2 modes described above (if desired).
This circular model could work as described below, where ecc[0] and ecc[1] could reuse either the eccH or eccV array value, but does not allow both to be specified (or ignores one). Alternatively, we could implement an elliptical model that allows eccH/V to both be specified and produces an elliptical spawn region instead.
Player space targets are targets that are specified in spawn eccentricity (azimuth/elevation) relative to the player view direction at spawn time as opposed to being fixed in the world. Note that currently player space targets do not track the player if they move, so in a way they are also "world space" coordinates.
Originally our assumption was that all targets would eventually be specified in world space, but recent discussions have indicated a desire to maintain support for player-space targets. We can still choose to drop support for player space targets, but if so we should formalize this to discourage continued use of their specification.
If we decide to continue to support player space targets we should consider:
if eccX > X0, eccY ∈ [Y0, Y1] else eccY ∈ [Y2, Y3]
)Note that implementing much of this will break support for the exact target motion provided in previous experiments. It may be worth formalizing this in documentation and referring to older releases to reproduce historical target motion as opposed to continuing to support it directly.
Some of the concepts described above (specifically logging target angular position and specifying target ID as opposed to width) might also be interesting to consider for adoption in world-space targets as well, though it is not entirely clear how some of this could be implemented (constant ID would require the target resize as it moves away from the camera).
The text was updated successfully, but these errors were encountered: