"Loading the default MoI down with a bunch of different shortcut keys that are not of general use would make it _more_ esoteric, not less."


"I don't recognize the MoI philosophy that you are talking about, as far as I can tell what you are talking about is "jam in as much stuff as possible even if it is not useful to everyone" - that is the opposite of the actual Philosophy"

Michael
Who suggested that all --or any-- of those items needed to be actually downloaded/installed?------ "Jam in as much as possible"?????----- I really am dissapointed. (Obviously my 77 years of English is at fault)

Sorry if I do not accept the us and them philosophy either.

Anyway--I don't care--I only expect a few months more---I am trying to get you to understand the broad usage of MoI that COULD be universally accepted IF!

Goodby

Brian

<>>>>>No, the opposite, what you're talking about there is like a feature history tree, where you can turn fillets and holes on and off.
>>>>
Yes, I've never used a true parametric feature history based package, but that sounds like that.

Anyway, I would feel more accomplished if I was barking up the same tree as you!

Respect,
Burr

Hi Michael,

After understanding your intentions with the object browser and using styles as layers in its simplest form, the thing that I can't get my head around is if we use style as material assignment to an object how is that going to map out to layers upon export ?
If I was to export a cube that that was modelled in red and I applied fillets in blue, would the fillets export to one layer and the rest of the faces of the cube, another ?
I've actually been using object name as the layers, so I have 'construction' named under objects where I can have a number of different styled construction curves under that name and so on with other objects, that way I can isolate 'construction' and then manage that area with the style section of the browser, so it makes more sense to me that the object name section of the browser = layers.

I also have a request if it's possible, to create an object name or a new style without having a selected object or any object at all.

-

Hi Danny,

For exports to formats that have a type of layer system where it is not allowed to have sub-objects (edges or faces) on different layers than the parent solid, my current plan is to just use the style of the parent solid as the layer assignment.

There isn't really much other choice if the target format does not have any way to assign different layers to sub-objects.

This will apply to 3DM, IGES, and STEP exporting (for 3DM to programs other than MoI).


> If I was to export a cube that that was modelled in red and I
> applied fillets in blue, would the fillets export to one layer and
> the rest of the faces of the cube, another ?

Not to these 3 formats - you would end up with the whole thing in the red layer, since I believe those formats do not natively have the ability to have one sub-piece of a solid on a different layer than other pieces of the same solid.


> I've actually been using object name as the layers, so I have
> 'construction' named under objects where I can have a number
> of different styled construction curves under that name and so
> on with other objects, that way I can isolate 'construction' and
> then manage that area with the style section of the browser,

Yup, that's why there is more than one system available, so you can use them in combination like this if you want.


> so it makes more sense to me that the object name section
> of the browser = layers.

Well, most of the time in other programs the layer is not just a name, it also controls the color of the objects that are on the layer.

That's why it seems that styles are a good mapping to layers, since they also control the color of objects.


The mis-match is that MoI allows for more flexibility than some export formats can hold, with the possibility of having different parts of a solid assigned to different styles instead of a solid being one atomic colored thing.

If you export to a format that does not support that level of flexibility then some of those assignments will be lost.

I've been thinking that maybe I should include a switch that you could set to optionally turn off this extra level of flexibility in MoI, which could help you more easily work within those confines if that is a main goal for you. Of course then you will also lose some of the capabilities that I mentioned earlier, like being able to set up styles on an individual object like a knob and having it then persist through many operations including when it is booleaned on to another piece.


> I also have a request if it's possible, to create an object
> name or a new style without having a selected object or
> any object at all.

Yeah for Styles I've been planning on having Add and Edit buttons that show up inside of the browser.

But for object name that isn't really possible - the object name is a property of an object, that's kind of like saying that you want to edit the width of something without there being a selection.

But if I understand what you want, I think that the Groups section will behave more like that - groups will be like a container of objects, and you will be able to make a group with no selection, it will be an empty group that you could then fill up with objects.

- Michael

Hi Michael,

> But if I understand what you want, I think
> that the Groups section will behave more
> like that - groups will be like a container of
> objects, and you will be able to make a group
> with no selection, it will be an empty group
> that you could then fill up with objects.

That's right! the utility belt's missing the batarang, no wonder I can't climb building walls yet, holy missing feature Gibson! :)

Cheers

Hi Danny, yes the missing batarang is a big problem! :)

One thing that I've been thinking about is whether Groups and Objects should be kind of merged together a bit more in the UI somehow.

Like maybe there could be a special group called "Named objects" that would contain all named objects within it, then that would make the current "Objects" section at the top level to not be necessary. But then after thinking about that some, maybe that is not good to have a special group that may behave a little different than the other groups in how you add/remove things from it...

- Michael

I had the same feeling Michael, at the moment you can name as many objects you want with the same name and treat it like a group.
The only thing I can think of is, one object, one name, so if you use that name again MoI will state 'name in use' then you either give the object another name or place an extra digit, eg. rim 1, rim 2 which would go into the 'wheel' group.

>One thing that I've been thinking about
> is whether Groups and Objects should
> be kind of merged together a bit more
> in the UI somehow.

The way NX 6 handles naming, is with what they call categories, we name a category and assign what ever layers to it, we either treat it as an individual object or a group or a mixture of both.

-

> I had the same feeling Michael, at the moment you can
> name as many objects you want with the same name and
> treat it like a group.

Yup, but one thing missing though with relying on just that for groups is being able to set up some kind of parent/child hierarchy.


> The only thing I can think of is, one object, one name, <...>

One problem with enforcing only a single name per object, is that probably having multiple objects with the same name is going to be useful for certain aspects of polygon mesh exporting, where I will make all objects with the same name get a kind of glued together mesh.


> The way NX 6 handles naming, is with what they call
> categories, we name a category and assign what ever layers
> to it, we either treat it as an individual object or a group or
> a mixture of both.

I'm not quite following how that actually works - for instance what do the layers assignment do to the category? I mean do the layers have an on/off state that controls the category being on/off, and does the color of the layers control the colors of the category?

- Michael

Hi Michael,

> I'm not quite following how that actually works
> - for instance what do the layers assignment do
> to the category? I mean do the layers have an
> on/off state that controls the category being
> on/off,

The category becomes the parent to the layers, where you can control on/off of individual layers or turn on/off the category which contains those layers.

> and does the color of the layers control
> the colors of the category?

Colors don't come under any of them, that's controlled separately with a combination of 'object preferences', 'edit object display' the filtering system and hide/show.

If you need more info I'll be glad to show you pictorially to explain it once I get home.

Cheers

Hi Danny, yeah I could definitely use some more information, that whole system is not at all clear to me currently.

> The category becomes the parent to the layers, where you
> can control on/off of individual layers or turn on/off the
> category which contains those layers.

I'm not really following... Like for example what if you have "Category A" which is a parent of "Layer 1" and "Layer 2". Then you have "Category B" which is a parent of "Layer 1" and "Layer 5".

Now you set Category A to be turned off, and Category B to be turned on.

What happens to things on "Layer 1" - should things on layer 1 be turned off like Category A says, or should they be turned on like Category B says?

Or do objects not belong to a layer and instead belong to a category, or something like that?

I think your layer system there is kind of different than what I am used to thinking of as "traditional" layers - to me traditional layers means a system like AutoCAD where you have a list of layers, each of which has a name, a color, and an on/off state (and other properties like line type, etc...). Objects reside on one layer and they take on the appearance and properties of the layer that they are on.

If what you refer to as "layers" do not have properties like colors associated with them, I guess they may be a kind of different concept or something... ?

- Michael

>What happens to things on "Layer 1"
> - should things on layer 1 be turned off
> like Category A says, or should they be
> turned on like Category B says?

Layer 1 actually turns off with that category, but you can switch that individual layer back on, then you'll have a mixed state of Category A.
We don't really use categories in this way, we control that sort of grouping stuff with the component assembly tree where you have sub assemblies under a parent assembly.
I know it sounds complicated but it isn't really once you understand the logic of it all, and no, it's not like Autocad or Rhino layer system, I think it's more for a Mech eng cad system.

> I could definitely use some more information.
No Problem, I'll have something up tomorrow for you.

Cheers
~Danny~

Hi Michael,

It seems we've got different interpretations and experiences in what we think a traditional layer system is.
Unigraphics (NX) was first developed in the '70's so there was no influence from Autocad which came out in the '80's.
Mechanical cad systems that I've worked with have always been 256 layers, some called them levels. I'll explain how NX handles object organisation, in a single 3d space and history free, parametric modelling and using sub assemblies within assemblies is also used for object organisation but that's a different story.

Layers in NX is just a container for an object or objects, it does not control the object attributes, like colour, line thickness, etc. all you can do with a layer is control the object interactive/visual state on the screen, like; Work(active), Selectable, Visible Only, Invisible.
Colours and the other object attributes are per object and controlled separately with the object preferences window, so you can have as many objects with different attributes for each, under one layer.

The basic layer window, layers on the right and what categories those layers are in on the left, note layer 62 is in 2 different categories.
when you right click on a layer you get the visual options.



Then when you tick the box that says 'Category Display' you get the categories in a hierarchy tree showing layers are under each category.



To change the object attributes for the work (active) layer you bring up the 'Object Preferences' window (left picture), to edit object attributes you right click on the object and pick 'edit object display' and that will bring up the 'edit object' window (right picture).




Once you've assigned layers and attributes to an object, it's a matter of using the layers, the filter system and hide/show to manage you work.

This is the filter system, which you can filter objects by types, colours, layers, etc.



'Type' selection filter.



'Colour' selection filter.


That's it in a nutshell. It would be easier and clearer if I actually showed the system on screen in action.

Any questions, feel free.

Cheers

Hi Danny,

> It seems we've got different interpretations and experiences
> in what we think a traditional layer system is.
> Unigraphics (NX) was first developed in the '70's so there was
> no influence from Autocad which came out in the '80's.

The AutoCAD layer system tends to be the one that is much more commonly used by quite a range of PC CAD software...

Certainly a system that originated off of a PC will tend to have a different history, and although there is nothing necessarily wrong with that system that you are showing there, I think it would be hard to incorporate that exactly since it is just not what the much wider majority of people would expect when you use the term "layers".

Here are some examples of layer systems from other CAD-ish programs currently on my machine:

Rhino:



SketchUp:



DoubleCAD XT:



ViaCAD:



Alibre 2D drawing module:




Notice how they all general fit the same pattern where a "layer" is an entity that has a name, and certain properties such as color and linetype.


It's just by far the most common thing that is done...


One big problem that would prevent me from adopting the system that you are showing there would be having colors assigned as an individual object property, rather than the color coming as a kind of named entity.

That's because one big purpose of setting this up in MoI is to translate that into material assignments. It is easier to control materials when there is a list of available named materials, and you can assign an object to belong to one of those rather than just a color value directly, because you may want to do things like set up materials like "Spaceship hull damaged", "Spaceship hull 1", "Spaceship hull 2", to have things arranged into different categories but not necessarily mess with having different actual colors set to them quite yet, until later when you are altering the materials in your rendering program.

So for instance it would not be unusual for someone to have set up 3 "styles" in MoI all of which are black currently but still have a separate identity. If all things that were Black had the same "material identity", it would prevent that kind of workflow...


At any rate, the Groups mechanism is meant to be a kind of container system, it may more closely align to the layers that you are accustomed to.

- Michael

Hi Michael,

I understand what you are trying to do with MoI and I agree that the layer systems you're showing there are restrictive, the reason why I couldn't understand where you were coming from, is because I was used to a whole different system.
The layer system that most other cad vendors have followed is from Autocad, which I don't think has ever evolved from the 2d world of past. I wonder how Autodesk handled Mechanical Desktop's layer system.

> At any rate, the Groups mechanism is meant to be
> a kind of container system, it may more closely align
> to the layers that you are accustomed to.

No doubt when Groups are implemented, MoI will be flexible enough to accommodate different ways of object organization, keep up the good work.

Cheers

Hi Danny, yeah they are kind of restrictive which is why I didn't want to jump right into having only that system for organizing objects and nothing else...

However on the other hand, those kinds of layers are pretty simple and easy to understand, and also are very widely used to control color.

It's that common connection with color that I was trying to demonstrate with those screen shots from various other programs.


So anyway, that's why mapping styles in MoI to layers in certain CAD-type export formats seems to be a good matchup.

- Michael