JDHill wrote:So just please try to keep in mind that you are not dealing with SubD subdivision, and instead with control over what has more generally been called micro-poly displacement.
There's no way of keeping something in mind which was nowhere documented.
Yeah, mixing up what MW calls subdivision with the concept, common place in mesh-modelling applications
and especially Digital-Sculping-Applications is really to be expected. I am sure that apart from a handful
initated users noone really knows how that beast works. As said before - for as long as MW does not subdivide
with a quad scheme it would be helpful to know more about what it does currently.
I have a perfect idea of to be expected Polygon-Load when using Catmull-Clark. With Maxwell I have no clue.
Subdivision in mesh-programs gets used used for the exact same purpose as in the renderer.
But while Maxwell uses the same word it in fact does something entirely different.
The fact that other renderers indeed
apply the Catmull-Clark subdivision-scheme (quads in - quads out) certainly doesn't help
And to address the previously mentioned Rhino vs vector displacement problem, it is not a problem. Base geometry with a scale factor will result in scaled vector displacement; while it is natural for an application like Cinema (and I assume Maya) or Studio to deal with [geometry * transformation], that is not the case in Rhino -- scaling geometry in Rhino yields physically scaled geometry, still in world space. A way of dealing with this is to block the base geometry, and then scale instances of the block; this works because instances are an exception in Rhino -- they are the only case in which it uses [geometry * transformation].
I'm happy and thankful that you found this trick to deal with this matter!
Still - from a users-perspective I would not call this "not a problem".
Having to turn stuff with VD to blocks means that the feature does not work out of the box and
means a complication in the workflow and something to learn. The object being a Block certainly had
consequences, e.g. when introducing File-Linking such as GoZ or similar bridges where the idea is update both
geometry and maps.
I perfectly realize that you can't do anything about these fundamental differences between Rhino and mesh-applications
but I as a user would of course prefer the not having to thing about anything solution
found in Studio
or other hosts.