Right - to me it seems like having the substitution be hard coded is a weakness that could be overcome with a meta-command extension.
With hard coding there is a dependency between supporting apps and changes in the library. A part author cannot create new low-detail sub-parts and have them be used without every program developer changing some kind of proprietary list, possibly in code.
The stud is the obvious example of low hanging fruit for LOD optimization, but:
- This cuts both ways - what about a high-LOD variant of studs.
- What about other parts that have high vertex count and are strong candidates for low-vertex approximation (if such parts even exist)?
So essentially what I am asking is: if we were to have meta data for low-fi variants of parts, what other meta data would we need, e.g. usage guidelines or metrics.
With hard coding there is a dependency between supporting apps and changes in the library. A part author cannot create new low-detail sub-parts and have them be used without every program developer changing some kind of proprietary list, possibly in code.
The stud is the obvious example of low hanging fruit for LOD optimization, but:
- This cuts both ways - what about a high-LOD variant of studs.
- What about other parts that have high vertex count and are strong candidates for low-vertex approximation (if such parts even exist)?
So essentially what I am asking is: if we were to have meta data for low-fi variants of parts, what other meta data would we need, e.g. usage guidelines or metrics.