I'm not arguing the validity of the terms. Although naming has always been given consideration and there is somewhat of an overall naming scheme in place, the names have largely been chosen for their appropriateness to the underlying functionality, not necessarily as analogues to existing terms or functions in other applications. In this particular case these terms may be specific simply because my explanations are *approximate* - the actual terms of "Lead-in scale", etc. are likely more accurate than "maximum scale" and the like. So whether we should name them accurately or with "familiar" names is not necessarily an easy decision, but it's something we'll be considering heavily before the final release of course, and it is very likely that things will be more intuitively named and cohesive in the final product. That is not to say the names will necessarily match up with other applications, but we'll certainly do that where appropriate for the sake of consistency and ease of migration.
For now my fundamental point was that despite the terms being potentially confusing and unconventional, they *are* adequately explained in the existing documentation. As we are all aware this is a Technology Preview and the main intent was not to preview the UI in anything near a polished, final state, but rather to give people an idea of the fundamental working concepts (network-based) and the capabilities of the renderer itself. Beyond that almost everything is subject to change and will almost certainly do so.
But to reiterate, long story short, I found those names confusing too and they will be reevaluated for appropriateness before the final release, along with all other setting names. For now I simply suggest referencing the documentation for any confusing terms.
- Oshyan
