--Viewer : minor bugs; refactor drawEvent

[jturner65]

Motivation and Context

This PR addresses a few minor bugs in viewer, where values that should have been mapped from constants were being mapped via magic numbers, or else not being mapped at all (such as the agent's dims if navmesh recalc is requested).

drawEvent functionality was also refactored to not recreate the Sensor Key string every frame when it only changed if sensorMode_ or visualizeMode_ changed.

How Has This Been Tested

It's Viewer! It Always Works!

Types of changes

• Docs change / refactoring / dependency upgrade
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have completed my CLA (see CONTRIBUTING)
• I have added tests to cover my changes.
• All new and existing tests passed.

[aclegg3]

Agreed that settings should come from any loaded config. Not sure about the hard-coded slope fix here. I understand why we should change it, but maybe it should be a change in the NavMesh default settings instead.

Also note we have the python viewer application here. Should these be expected to behave the same way? Open to thoughts here.

[aclegg3]

Danger here is that users will load the asset in viewer and everything looks good, but using the defaults in the episode generator for training won't produce the same results.

[jturner65]

Well, we do need to map the agentConfig values to the navMeshSettings, i think - if we are allowing folks to change agent geometry in viewer then we should have the navmesh synth process track that.
As for the hardcoded max slope, I actually don't wan to have this here, primarily I just wanted to start a conversation about it.

[jturner65]

Agreed that settings should come from any loaded config. Not sure about the hard-coded slope fix here. I understand why we should change it, but maybe it should be a change in the NavMesh default settings instead.

Yeah, that would be the ideal situation, but not sure if folks are prepared for any changes that might entail.

Also note we have the python viewer application here. Should these be expected to behave the same way? Open to thoughts here.

I think they should, especially for these particular value-driven quantities (if we are recomputing the navmesh and have locally defined agent specs, we really should use those to build the navmesh, I think)

[aclegg3]

LGTM, thanks.

[jturner65]

Got rid of a bunch of needless if checks building the string sensor key in drawEvent, and streamlined the draw/render process a bit.