Hi Martin,

> This looses me somewhat ... Hierarchy to me would only be suitable for combining objects into
> a manageable "group", where as i see no point in "instancing" a single face or surface, a copy
> or mirror is plenty good enough for that kind of thing (I hope),

It's more like - say you take a bunch of different objects which together make a chair. If you take that and then "Group" them into a group named chair, should that right there be enough to define an instance so that if you copied the chair group you would have 2 instances of the same base chair, or should it be that when you copy the group it forms a totally separate "Chair #2" group that is just a plain copy of the other one and not connected to it as instances are.

I guess the main thing is that there's enough similarity between selecting a bunch of things and saying "make a group of them" and selecting a bunch of things and saying "make these a base definition for instances" that maybe those could be combined...


> Instancing a Group would be a huge plus for moi, but certainly not like Rhino blocks - they suck.

But is it more just the copying of archaic AutoCAD type commands and workflow for dealing with them that mostly is a problem there, or are there limitations in the actual mechanism itself that's the biggest problem. Because if it's mostly the workflow that is a problem that's something that I don't need to worry about so much since I'll develop a totally different UI for that part but if there is a fundamental limitation in the mechanism itself then that's a bigger issue.

Like for example one big limitation in Rhino blocks is that once you create an instance you can't then select it to be used in boolean commands and things like that - but that's probably fairly easily avoidable. But in SketchUp you can have instances that are not just independent objects, they can actually be a sub part of a larger object and automatically cut the larger object where they touch it. Trying to do that would probably require a really separate base level mechanism for the instances than what Rhino does. But I'm not so sure that it's not better to have that kind of thing done more at a history editing level and less at the instancing level itself...


> but I assume that the notes and annotation text blocks that Rhino uses must have an area in
> the *.3dm file to hold these things. Since MOI does not seem to use these at present, could
> you not use that space for a database type thing holding data\history for the named geometry
> to prevent complexity ?

Well it's pretty easy to add totally custom data to 3DM files so I'm not worried about just finding a place to put stuff. But custom data will not be read by other applications, so for better inter-application data transfer support it can be good to just use the already existing mechanism instead of doing something different. But maybe not if that's not going in a good direction.

- Michael