I know I may seem silly but I just can not see, in keeping with the MoI philosophy, why ALL the stuff/Petr's MoI page included, is not simply listed and accessed from something like this.
(This "Brian" principle seems in keeping with vertually every other app I use!)



Brian

Brian, we've been over this before quite a few times...

Custom scripts are things that I put out all the time to help people do some specific task.

I cannot foretell the future so it is not possible for me to put every single possible script that will ever be needed into the software all in advance.

There will always be new ones that I develop to help someone do a particular task at hand.

This is a great feature of MoI, that is is able to have this kind of flexibility to have it get extended instead of it only being locked into what is possible with the default install.


In the future, I may migrate some of those things into the default install. But most of them are not particularly of use to everyone, many of them are specialized things and only of use to someone doing a particular task.

By having those things separate, it helps to keep the default MoI install to be simple and less "esoteric".

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.


That is part of the overall MoI philosophy to try and keep the main program streamlined and easy to use and not load it down with a bunch of things which are not of use to a majority of users.

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

Hi Brian,

> (This "Brian" principle seems in keeping with
> vertually every other app I use!)

Yup, and that is probably why you like to use MoI, since it is so focused on trying to keep things streamlined and easy to use!

That is not often a focus for other apps.

- Michael

To get back onto the original subject......

Burr,

> To do it that way would require that if all layers were
> turned off or blanked, except the original, then you
> would see the original, untouched model, even after
> the fillets and booleans were applied. And this I havnt seen. :)

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.

This is how I see it, if you have a solid cube and apply a fillet and a hole, I still consider the cube with fillets and hole as one item so it should be under one style/layer, not to be confused with one entity.

For Michael's example:
>.....if you do a blend between 2 edges,
> should the newly created blend surface
> (which is an independent surface object)
> get the active style applied to it, or if the
> 2 input objects to the blend had the
> same style should it get that one applied to it?

I would expect the blend to be under the active style because it is a single item that I made under that style.
Now if I was to join those 3 surfaces, I am making it one item, so I would expect it to be under the active style, if I separated them, I think they should resort back to the original styles that I modeled them in ( if it's possible, coding wise, with MoI) or they all separate under the active style, which I don't mind either.

Hope this makes sense.

-

Hi Danny,

> I would expect the blend to be under the active style
> because it is a single item that I made under that style.

What about an extrusion?

Say you extrude a curve with Style=Red - what should the generated surface/solid have - Style=Red, or the Active style?

Most people seem to expect to have the styles inherit in this situation too (so output solid has Style=Red, regardless of the active style), but this is again the kind of case where there will likely be some kind of setting to choose which behavior you want.


> Now if I was to join those 3 surfaces, I am making it one item,
> so I would expect it to be under the active style,

I'm pretty sure that it won't work like this part though - when you have geometry that comes from a direct copy of an ancestor piece, right now it is intended that the styles will persist the same on the copied piece as the original.

Otherwise there is just too much chance that you could lose material assignments that you may have spent some time working on setting up.

For example imagine with that detailed camera model that you had, that you want one piece of a solid to be a different material (for example some extruded text geometry to be silver or something like that), so you set those faces to have your own style. Now later on you want to separate that part out and do a bit of modification to it and re-join it later, if I did what you mention here your original assigned styles would be lost.


> if I separated them, I think they should resort back to the
> original styles that I modeled them in ( if it's possible,
> coding wise, with MoI)

That would require some kind of additional property tracking that is not currently being done.


> or they all separate under the active style, which I don't mind either.

Right now the plan is that separate will work like copying, the separated piece will retain the same style that it had when inside the solid. This should be working already in the current beta.

Otherwise again there would be materials information that would be lost with that kind of automatic modification.

- Michael

I see what your saying Michael,

I'm still thinking in layers and forgot the flexibility of the system implemented in MoI, material assignments, of course! silly me. I think I'll have to do a combination of styles and object names to achieve the logic that I explained.

Thanks for the realisation.

Hi Danny - yeah the styles are kind of similar to layers in several aspects, but not quite identical.

It is a big focus to be able to use them to control the visual appearance of your model, including setting it up for a rendering. That's why there is this feature of having faces within a solid able to have different styles assigned to them, rather than the whole solid only being one elemental material.

Having that limitation of "entire solid is on one layer/style", would have much more the kind of behavior that you are talking about, but it can cause a lot of difficulties when you want to render, maybe forcing you to use some entirely different mechanism to handle render styles, or maybe forcing you to modify your geometry to break it into smaller sets if you want to have different faces to have different materials. I'm hoping to avoid the need for that kind of stuff.

We'll have to see how different the styles behave in practice to layers - I think that there is enough similarity that it will likely work well for many things to use them in a similar fashion to layers but we'll see.

But yeah in addition to Styles you'll have groups and named objects that you can also use... I've thought a little bit about possibly having the idea of an "Active group" that you could set as well, but I'm not quite sure.

- Michael

Hi Danny - just to give you some more info, the idea is to be able to do stuff like this:


Set active style to "Silver".

Create Text geometry (Draw solid / Text)

Position the text in relation to your existing model, where the existing model has Style = "Black paint".

Do a Boolean to either cut the text or make raised text from your model.

The result will be Text pieces being "Silver", and the parts of your main object that were set to "Black paint" still have "Black paint", even though it is all one solid now.


With some strategic use like that, it should make it easier to have things all set up to render. In your rendering program you just need to adjust the material definitions for "Silver" and "Black paint" (from the simple color that MoI will have set to instead be actual textures and stuff) but you don't need to assign them to objects, they are already all assigned.


If the render visual appearance does not work for the kind of structural arrangement that you want for controlling hiding/showing, then you would probably want to use groups or named objects to supplement the organization rather than only using styles.


- Michael

Hi Michael,
I follow now.
There is now another element involved when modeling in MoI, material assignment.
What I mean is, I haven't used Model/Render packages much, my thought was you model, then assign materials after you finished the modeling project.
In what your saying with styles, I will be assigning materials as I'm modeling, on the fly.
I don't know if this a good thing or a bad thing I'll have to try this approach with my next modeling project, concentrate on modeling alone and then assign the materials or assign the materials on the fly as I'm modeling, let us see.

As long as you include the inherit switch in the .ini :)

Cheers

Hi Danny,

> In what your saying with styles, I will be assigning materials
> as I'm modeling, on the fly.

Yup, that's the concept. (I just posted another example above, right at the same time you posted your last message).

However, I do also hope that they are similar enough to layers that they can be generally used in a similar way if you want to use them just for organizing things as well.


You can kind of get the idea though that you may be able to save a lot of time in by incorporating the render organization right up front.

For example say you want to Boolean some array of 100 knobs on to something. Instead of having to pick those 100 sub-pieces later on, if you assign a Style="Knob" to the original knob before arraying it you will be all done...

The original style will replicate to the array results, and then inherit to the pieces of the knobs that survive the Boolean.

- Michael

Sounds good, I'll have to put into practice to see how it feels.
Thanks for clearing this up for me, again!

Cheers

"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