I'm sure this has been thought through, just wanting a walk through as a new user!

But anyway: components within MoI...Could/do they exist on some level? I know Rhino uses blocks, which I find a little clunky after the quite streamlined way SkUp deals with them (this is one of the joys of that program I find). Is it something MoI could benefit from?

- Rich

Hi Rich, yup definitely MoI would benefit from a component / instance / block type mechanism. Right now they do not exist in MoI but that is definitely on my list to add in.

I've been kind of conflicted whether I should do something the same as Rhino and then have compatibility with it, or whether I should try to do something more like SketchUp actually, where the component can be directly combined into an object. But I'm also not sure whether the combination part should really be more a part of a history function rather than something that the component mechanism tries to handle itself.

I think in SketchUp a component can only be merged onto one target face, is that correct? That kind of works out well for SketchUp since it's overall more focused on making boxy objects and doesn't really have much focus on doing curved objects, but MoI is not so focused only on boxy stuff like that.

Or are you referring more to the overall component management UI in SketchUp?

- Michael

Components like sketchup would be awesome =)

Hierarchy would suit me better

Parent_Group ; (Joined Surfaces or Solids)
... Child_Surface ; (Faces or Surfaces)
........ Geometric History ; (As it says)
........ Surface_Style_Name
........ Surface_Token_Name
... Child_Surface
........ Geometric History
........ Surface_Style_Name
........ Surface_Token_Name

Just my 2c

Martin

Michael,
From what I recall, in SU, a component was like a group of objects by itself, but once copied, acted like clones.
You could manage them, but where their special ability came in - if you edited one (didn't matter which), all "clones" of the the component would update automatically. SU allows you to manage these components in a library system along with all kinds of other special features.
In SU, if you un-grouped a component, it would separate into the base object with no connection to the behavior of the original instance.

But what would really only be needed is more like an instancing or clone type control over what could be considered a group.
Make your single or multiple objects a group - and you would be allowed to make instances or clones of that group.
Altering one would change all.
Un-group one and it would be considered an individual set of regular objects with no linked editing action or history.

A huge advantage to a 'component' or 'instance' is the amount of file size space you could save because of the reference to one whole-original.

One bolt or 'widget' object could become hundreds! It would only occupy the amount of space in the file that it took to surface that object.
The only limitation would be had in the video card tessellation.


I don't know how, personally, this would translate to the 3dm/Rhino-compatible formatting... it sure would have become handy when I made that Cutangus tank thing!


On the issue of groups, I would love to see that come to fruition. If for anything, it makes object management easier.
Working with groups is a kin to moving you home contents to another house. Sure, it's nice to tell the movers: pick all the red items, a red book, a red dish, a red vacuum. And yes, you could tell the movers to grab all the 'chairs' and 'tables', but boxes (or groups) really help make a home move more manageable of course. ;-)

The great thing is, that you wouldn't loose the naming of your objects in the bargain of naming larger selections of objects.

> Hierarchy would suit me better

You could read into groups with a hierarchy, and it could be compatible with MoI's current object list structure.
Corel and Illustrator allow you to manage your objects>groups in a hierarchy list.

So really a hierarchy list is just a written description of the structure to your groups and objects within groups within groups and so forth...

Hi Martin,

> Hierarchy would suit me better

I think that will come from a "Group" mechanism which will be a separate thing from an "instancing" mechanism.

Components/instancing will be focused on making copies of a base object in such a way that the copies are lighter weight and can have their base object changed and have all the instances then update to reflect the change.

So far at least I've been thinking that a Group mechanism with hierarchy would be separate from that. Although maybe there is some possibility to combine things together but not if those combined mechanisms become too complex an unwieldy with too many options compared to how separate mechanisms would function.

- Michael

Hi Mike, yeah so the way I've been thinking of proceeding so far has been to add both Groups and "Instances" (still not sure whether to call it "Instances", "Blocks", "Components", or "Templates" but kind of leaning towards "Compoments") as 2 different mechanisms.

A group would be kind of closer to the current object name - a group would be a kind of named container label that you could create and assign objects or other groups to, and the group within a group would provide for a hierarchical organization.

That would be a separate thing from instances/components - the instancing mechanism would be more focused on generating a bunch of duplicates of some base object template, in such a way that the main objects are only defined once and so it reduces file size since each instance does not have a full copy of all the base geometry and would also allow having the base definition be edited and have all the instances get updated.

Having these as separate mechanisms I think will allow for more flexibility - you'll be able to use Groups for just pure organizing of objects into hierarchies, and the instancing mechanism would be more focused on some additional stuff like a base object edit mechanism.

But I'm still not quite 100% certain if that's the way to go - there is some overlap between these concepts because what if someone makes a group and then copies that group, were they then expecting it to behave like an "instance"... I guess that maybe I should not worry about that since usually grouping in 2D illustration programs does not form instances with that process anyway (when just copying a group).

- Michael

That great Michael, groups and instances will be a very welcome addition.

In Corel, there are these entities called 'Clones'. They're not groups, but you can 'clone' groups or objects, it doesn't matter.
When you change what's called the 'master', the 'slaves' change and reflect whatever is considered that master.

It's how I can set up things like business cards or stickers where I can go and change a part of the graphic or type and everything else changes without having to copy and place everything again and again.
Sometimes, I'll make a little graphic element like a 3D looking star shape, with an extrusion added to it, I can SCALE them and move clone all around.
No matter what the scale, rotation or orientation is, if I need to change a color or the shape, all of the 'slave' clones will follow suit. A big time saver, and the file is smaller as you make point of.

Good luck on its development whatever you're inspired to come up with.

Mike

Hi Michael ...

> I think that will come from a "Group" mechanism which will be a separate thing from an "instancing" mechanism.

And so it should be. :)

> So far at least I've been thinking that a Group mechanism with hierarchy would be separate from that. Although maybe there is some possibility to combine things together but not if those combined mechanisms become too complex an unwieldy with too many options compared to how separate mechanisms would function.

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), Instancing a Group would be a huge plus for moi, but certainly not like Rhino blocks - they suck. I am no expert at these things, I just like playing, 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 ?

Martin

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

Hi Michael ...

> 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.

Now to me, and it's just the way i think, and it may well be flawed, but if you have the grouped objects to create an instance. With the Hierarchy structure in place, if you want an instance of a group, then you should request it in some way, instance along a curve and how many etc, ideal for tank tracks etc. If wheels, then mirror instance. The "Parent" group or original could then have an icon in the objects list to signify that it is a parent of instanced objects.

Rhino's handling of the blocks was alien and non sensible ... Create a group, convert to a block - Bye bye geometry, now import it back in and then say where you want it and if you need it rotating this way or offset here or inserted there ... YUGH!!!

In your analogy of the chair group then the first one created would remain as a tangible group, any further copies would have to be decided upon by the end user as to whether they needed instanced geometry or if they can afford the resources of having a direct copy. Instances to me are just a memory/speed saving measure which is of course highly desired within a 32bit environment. I don't like throwing spanners into the mixing bowl, but since MOI has no ray trace rendering engine, and most models are therefore exported to the likes of MAX, C4D, Blender et al then you could in reality leave instancing to those applications as most already do it. It would be harsh but understandable, and I would really like to see instances in MOI.

Martin

Hi Martin,

> Instances to me are just a memory/speed saving measure which is of course
> highly desired within a 32bit environment.

They're definitely used for that a lot, but other people also use them for pretty separate things from that - either to be able to do modifications and have all shared instances get updated, and also to have the components list be a "bill of materials" that just keeps track of how many of each part are in there.

So most likely the components UI will have some stuff oriented around these other uses of instancing as well.


> I don't like throwing spanners into the mixing bowl, but since MOI has no ray trace
> rendering engine, and most models are therefore exported to the likes of MAX, C4D,
> Blender et al then you could in reality leave instancing to those applications as most
> already do it. It would be harsh but understandable, and I would really like to see
> instances in MOI.

Even when MoI does have instances (I definitely expect to have them at some point), you still may want to do the instancing in your rendering programs instead in many cases since many of the somewhat older mesh file formats do not have any instancing mechanism in the file format structure itself. For example OBJ format does not have any kind of instancing in it. Instances will have to get converted into regular copies when doing a transfer through one of those kinds of file formats.

- Michael

> Even when MoI does have instances (I definitely expect to have them at some point)

This is the news I was looking for - can't wait.

My 2c:

- I feel that as a reference you should use SU, it is pretty solid...In terms of being able to group an object(s) so it is in a nice little packet and then have the option to create a component instance out of it. I don't feel that a hierarchy output/list is needed (keeping the 'artist' in mind - would an artist have the need for such a complicated Maya-ish display?)

- The strength of components for me lies in the ability to change geometry and have it update easily across a project, fast. It is a time saver, and when dealing with symmetrical objects the ability to alter one side and have the other automatically update is fantastic. Just ignoring the bringing the model size down for a second - this doesn't strike me as being a huge issue within MoI.

- As there are many different ways to approach this across many different softwares - does it need to be a feature that remains valid upon export? Maybe a focus on intuitive UI would be where the time is best spent? This is probably selfish as I import to Rhino and have no idea how this would work anyway.

- Rich

Being able to select a whole group in the viewport would be nice.
You click on the group and it selects all the objects.


Xara has some practical examples of object organization, several kind are possible:

Groups: Cluster of objects like described above, possibility of nested groups.

Soft Groups: Stacking Objects can be spanned across several layers and reorganized afterward, does not change stacking order.

Named objects: Object or group of objects can be named and they can belong to several different names tags, making cross-association possible. An example here:
http://moi3d.com/forum/index.php?webtag=MOI&msg=2127.47

Live copies: Instancing.

There's also Clipview but that wouldn't apply much to 3d.


Ctrl+Clicking on a group will select an object inside a group, Ctrl+alt+Clicking will select nested groups inside, repeating will cycle through them...


Marc

Vectorworks uses a system of Groups, Symbols, Classes and Layers, which is very powerful.

Groups act as 'boxes', organising the drawing into discrete sections. A duplicate group is independent from the original. Groups aren't named, they're simply a drawing tool that allows disparate objects to be linked for convenience.

Symbols are clones - similar to a SU component. Change any symbol and it updates across the file. Useful for repetitive elements (obviously), such as standard size doors, they're named and organised in a library (which can be referenced from an external file). Symbols can be automatically inserted into walls in the manner of SU, but this is complex and not that important in practice - it's the ease of updating that's particularly useful.

Classes are the equivalent of Moi names. Classes can set global properties - colours, lineweights, opacity, visibility and so on. Classes operate drawing-wide, affecting members of groups and elements. Useful for grouping materials.

Layers are the equivalent of separate drawing sheets overlaid (storeys of a building for example). They can probably be discounted here.

The system works well, and would certainly help me in my use of Moi - I find it too easy to change something by accident..

In your futur system of Instance
like in SKetchup if you modify any copy of a component all same components will be modified ?
And a possibility to make an instance of component "Unic" ?

Hi Pilou,

> like in SKetchup if you modify any copy of a component all same components will be modified ?

Yup, that would definitely be part of it.



> And a possibility to make an instance of component "Unic" ?

Sorry I'm not sure what this part means.

- Michael

Unique?

So "different" - not "genderless". ;-0