Multiple targets

[joohwankimNV]

It seemed easy at first, but soon I realized it requires changes across many parts. We should the decisions on them based on a high level philosophy, and then implement it. As a starting point of discussion here are the local changes needed.

• Health point tracking.
  • Currently m_targetHealth is one member variable in the App class. Probably we want to move away from it and have each entity track its own health.
• Hit detection mechanism in the App class.
  • Do we want to define multiple FlyingEntity's or JumpingEntity's and destroy each of it when health becomes 0? Or we keep all the entities but set the health values to 0 when cleared, but destroy them altogether at the end of a trial? In the latter case, we would need to check health value after checking intersection of the ray.
• Log writing method in the Logger class.
  • Arbitrary number of objects can be in one trial, and objects can get destroyed in an arbitrary order. How can we capture individual objects' trajectory in the log? Generate tables as many as the maximum number of objects? Or multiple columns in one table? Or multiple values in one column in one table (e.g. comma-separated values inside one column)? How should we handle objects cleared before a trial ended?
• Configuration format in .Any files.
  • What's the optimal way of doing it? My first idea is to define motion types as we do now, and use a nested dictionary format inside the "id" field in "sessions" / "trials".
• Configuration loading methods in various Config classes.
  • This depends on the new configuration format.

[bboudaoud-nv]

Agreed on health point tracking. We could also easily move towards using the target to control its own motion. Multiple target spawning has a bit more complex dynamics to think through, but certainly an interesting option. We should discuss this a bit more in the development plan

[bboudaoud-nv]

I now consider this issue to be largely addressed (though some small issues remain). I'll answer the questions from the original issue in order below:

• Health point tracking
  FlyingEntity and JumpingEntity now inherit a common TargetEntity class that provides two simple public routines for getting the health (TargetEntity::health()) and doing damage (TargetEntity::doDamage()). Each target now manages its own health. There is currently no mechanism to "restore" target health, but this isn't an issue since we destroy our targets when we're done w/ them.

• Hit Detection in the App
  For now we're destroying the target (in a G3D sense) as soon as its health is 0. All logging is still put off until the end of the trial (when all targets are destroyed)

• Logging
  The solution here is probably the most complicated. The Conditions table has been converted to the Targets table, with 1 row for each target, but also the trial_id and target_id for each target used. The target_id is comprised of [session_name]_[target idx] currently. The Player_Action and Target_Trajectory tables have a (matching) added target_id row to indicate which target is being referred to. For now the Trials table is unaffected, but I'm guessing eventually we want to make targets unique to the Trial rather than the session.

• Any File Configuration
  The adopted approach minimally impacts the experimentconfig.Any file. What was previously the id field of each element in the trials list within the sessions array is now the ids field. This field takes an array of target names from the valid targets described below in the file. These are the targets that will be simultaneously spawned for each trial. If you just want a single target this is an array of 1-element. The SAMPLEexperimentconfig.Any has been updated to demonstrate this.

The affiliated configuration changes (mostly moving from target parameters to arrays of target parameters) has been completed.

Open items include:

• Making sure target names are correctly unique across sessions and deciding whether using trial ids might be a better approach
  • Think about including the target "id" from the targets array input
  • Create trial names or just use indexes?
  • Allow the user to parse the Player_Action and Target_Trajectory output tables w/o references to know what session/trial/target type we are seeing
• Instrument/check results for target destruction to make sure this doesn't impact timing at high frame rates
• Fire test large target count trials and see where we hit limits
• Fix success_failure field to be more representative (currently reports destroyed target count, but we don't know the total)
• Consider updating the Trials table to include the simultaneous target count and other relevant info

[bboudaoud-nv]

Since we've implemented arbitrary target models I've added support for logging target model names as of a recent commit. This is part of the changes affiliated with logging outlined above.

[bboudaoud-nv]

A recent commit moves towards using trial indexes together with session ids, and with target ids/indexes to make each target's name fully unique. I will consider this part done for now. Similarly success_failure has been updated to remaining_targets to address the issue referenced above.

Once we complete testing on the impacts of removing at hit and large target counts we can probably close this issue unless additional info needs to be added to the logs.

[joohwankimNV]

Tested system performance using our latency tool the impact of target clear and multiple targets.

• Target clear does not have observable system performance impact. Probably faster than 1 ms.
• Multiple targets do have system performance impact. Having 40 targets increased end-to-end latency by ~10 ms.

[bboudaoud-nv]

Thanks to @joohwankimNV for confirming performance. I believe all the core issues here are now addressed. Let's close this issue here and open new issues for any specific additional items we might need.