Changes between Initial Version and Version 1 of Ticket #9447, comment 6
- Timestamp:
- Oct 4, 2021, 9:30:01 AM (5 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #9447, comment 6
initial v1 1 The main issue is that it breaks the assumptions of how property assignment works in a command to a filter - for every other sendcmd settable property they can be set to a value tested by passing that property to the filter directly and expect to see the filter behave as if that value were provide r directly as a prameter during that command interval - and as a result interpolation functions can be evaluated in the sendcmd expressions to smooth or distribute value changes over time.1 The main issue is that it breaks the assumptions of how property assignment works in a command to a filter - for every other sendcmd settable property they can be set to a value tested by passing that property to the filter directly and expect to see the filter behave as if that value were provided directly as a parameter during that command interval - and as a result interpolation functions can be evaluated in the sendcmd expressions to smooth or distribute value changes over time. 2 2 3 3 It may very well help with the issue of avoiding gimbal lock but that's at the expense of what you can express with the filter commands - this does regress the behaviour that the filer previously displayed by giving these properties unique behaviours - if the ability to specify a relative offset for these properties is required why not expose the adjustments of these values as separate rel_yaw, rel_roll, rel_roll as adding this unique behaviour to existing parameters breaks previous behaviour, developer expectations and the utility of sendcmd for setting these properties.
