Hi Michael,
You might of missed this in the 'V2 beta Apr-12-2009 available now' post, because it's so big.

I noticed that if you create a feature on an object, that feature takes on the current active style, e.g. if a cylinder has style=green and the active style is red and you apply a fillet to the cylinder the fillet takes on style=red, I would prefer that the fillet inherit the style of that cylinder no matter what colour is active, when working on an object I don't want to always check if I have the same style active as the object I'm working on, maybe an ini option,
'inherit tool style' - 'inherit target style'.

Cheers

Hi Danny yeah I saw that, sorry haven't answered yet due to "thread fatigue" ;)

I do intend to modify it to work like you were expecting.

That situation where the newly created surface is a sub-object of an existing brep (such as with Fillet), that is pretty clear that it should inherit the style of the parent brep like you are talking about.

Right now those are kind of getting caught up in a general dragnet that applies the active style to all things that did not otherwise get a style assigned to them, but I will be able to fix that up pretty easily.

The ability to have sub-objects be assigned various different styles than the parent brep has had some side effects like this that need some tuning up.


I will probably be adding in a .ini switch similar to what you mention though, because there are some other situations where it is not quite as clear, like 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 know from developing Rhino that this can go either way, there are some people who like to have the output objects generated using the "current layer" so that they can make things all arranged where they want them to go without having to always be altering things.

But I think that wanting to inherit in cases like this tends to be more commonly expected so probably inheriting will be the default.


It probably won't take too long for me to roll out another beta with some tune-ups like this in it.

- Michael

I'll take over here Michael to give you a break!!! (not really...I could hear the whole forum groan!)

Just my input here though, if you think of styles as coloring, then what Danny said makes sense and should go that way. But it you are looking at Styles as "Layers" then it is operating as it should, as I want all operations im doing to be associated with the active layer and its my responsability to be aware of what layer I'm working on. So like I want to extract all my edges to the current active layer, I dont want a bunch misc styles all over.

But I think Michaels experience just said that "Both" are desirable for different situations.

Anyway....

Don't people realise that there is the learning young/new and the learning old maybe?

So much of the "edges" of MoI are ---well---- esoteric! All is cured within an .ini or something which needs a university degree to access?.
(The weakness of such an otherwise brilliant app.)

Sorry--I just saw a post on what is coming in another Beta maybe--the first item that I would think should have been in this one rather than the Browser..

Brian

Hey, I cant use any other app for modelling now---despite my grumbles!

Hi Brian, I guess I don't quite understand what you're complaining about here...

Have you needed to edit the .ini file yourself? If not then what is the problem?

Sometimes I put options in the .ini file to make it possible for advanced users to tune MoI to have some special behavior that helps their specific type of work.

If I didn't do such things like that, the other options available to me are to either tell those advanced users that they are just out of luck, or to jam in a whole bunch of advanced and specialized options directly into the regular UI, which would make MoI more difficult to use for beginners.

So putting things that beginners never need to mess with as a .ini option actually helps make MoI easier for you to use...

Hopefully that may help to explain the reasoning behind this stuff to you a bit more.

- Michael

Hi Burr,

> But it you are looking at Styles as "Layers" then it is operating as it should
> as I want all operations im doing to be associated with the active layer and
> its my responsability to be aware of what layer I'm working on.
> So like I want to extract all my edges to the current active layer,
> I dont want a bunch misc styles all over.

I understand what your saying, but in a layer system if you model a cube in layer 1, a cylinder in layer 2 and now your active layer is 2, if you go back to your cube and apply a fillet and make a hole, do you want the fillet and the hole surfaces on the cube to be on the same layer as the cylinder?

-

"Have you needed to edit the .ini file yourself?"---I don't understand Michael!

"make it possible for advanced users"---as I said-- an esoteric approach!

I know I am plowing a dead avenue----but I must be true to myself.

The post elsewhere that we may not need, soon, an electron microscope--and LONG temper-- to cure/find unknown/overlaid selection/joints searching of problems---whacco.

And, I still can not reason why all this "ini" or whatever could not be, automatically, added to a common simple short cut file is a worry to me. The current approach seems--not MoI principles?
Anyway, I try!
Brian
(I am repeating myself I know but it's hard to justify MoI to my friends with these critical few "different" system approaches. Maybe, from a Rhino or similar background it all may feel more natural?))

Hi Brian,

> "Have you needed to edit the .ini file yourself?"---
> I don't understand Michael!

Well, I don't really know how to ask it much more simply than that...

The question is - have you ever needed to edit the .ini file to set an option that you personally needed to use.


> "make it possible for advanced users"---as I said--
> an esoteric approach!

I'm not quite sure what you mean by this.... Do you mean that I should tell advanced users that they can't do what they need with MoI?

Please realize that MoI is used by a variety of people, including both beginners/hobbyists like yourself as well as people doing very specific and advanced use.

Some functions in MoI are targeted at advanced users, but I have put in a lot of effort to keep the main UI easy to use, that's why advanced users may need to edit the .ini file to turn on some things of particular interest to them, so that it won't make the UI seem like a 747 dashboard to beginning users.

Some discussions in this forum will be about advanced uses of MoI - if these discussions are confusing to you, then my best advice to you is to just skip over them if they don't apply to what you want to use MoI for.


> The post elsewhere that we may not need, soon, an electron
> microscope--and LONG temper-- to cure/find unknown/overlaid
> selection/joints searching of problems---whacco.

I really have not the faintest idea what you are talking about here Brian...

What electron microsope? What other post, could you give a link to it? What joints? What about overlaid selection?

I don't remember anything along these subjects that was recently discussed.

Are you sure you're not talking about a message from some other forum or something like that??


If you find it to be unacceptable that MoI accomodates advanced users by letting them set options in the moi.ini file, then I'm afraid that MoI is just not going to be the right tool for you. Many times options like that are added as a courtesy to other users to help them with particular tasks, but not get in the way of beginning users. This kind of effort that I put in to help people get their jobs done is not going to be going away anytime soon. I mean most people appreciate that a lot, I don't understand why you find it to be a problem...

- Michael

>>>>>if you model a cube in layer 1, a cylinder in layer 2 and now your active layer is 2, if you go back to your cube and apply a fillet and make a hole, do you want the fillet and the hole surfaces on the cube to be on the same layer as the cylinder?
>>>>

Well, Yes!

I've never used a layer system that automatically changed based on the object I selected. It is always me that changes what layer I am working on.

But I think I see what your saying too. Seems some things need to be independent of the layer system, otherwise the only way to propogate the seperation of layering would be to create "duplicates upon duplicates" to preserve the original layer. Things like booleans and fillets on an object need to be tied to that object, not necessarily a layer. I wonder if there is a set criteria for what constitutes "layer only" or "object only" type operations?

Anyway I see what your saying now as I tried putting it into practice with some other packages. Certain operations like "extracting the edges" of a solid model to do profiling operations, respected the layering, but a boolean (obviously) did not and was applied at the original object and original objects layer, regardless of the active layer at the time.

Seems there is a split somewhere as to what can layer out and what cant. The question is, is this arbitrary and set by michael, or is it a "theory set" that comes along with this type of system, that needs to be adhered to?

Talk later

Danny,
And just so you're clear on my "well Yes" answer. 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. :)

Hi Brian,

I actually find the .ini file easier to navigate than going through a multi tabbed option box with numerous tick boxes, because when it comes down to it, that's all the .ini is, a record of all those tick boxes you've ticked and unticked in all the other software you use.
So if you've gone through the options box in other programs you are actually changing the .ini file.

Cheers
~Danny~

Two wishes for the ini file:

* I would like to see the ini file stored in the MoI programm dir - or can I simple move it?

* the ini could get some Space line between the different sections

Hi Brian,

Also bear in mind that we are discussing beta software here. These betas are so stable that one can forget that they are still work in progress. As things show up Michael has been including them in the options rather than the .ini file. For example the LWO scaling used to be in the .ini, there is now a checkbox for it :-)

Hi!

1. If anyone desires so, I can whip up a quick'n'dirty "MoI Hidden Options" program that would offer a nice tickbox driven GUI to moi.ini, to help any textophobes use those options with more ease. MoI's development cycle is nicely paced so keeping up to date shouldn't prove hard.

2. That cheat sheet that Brian linked to scares me! It reminds me of Emacs, the only editor in the world with in-built psychiatrist! Also, web server, remote function call system and a kitchen sink, all accessible via some esoteric Meta-Control-Super-Shift-Letter function key combo...

To sum it up:
http://catb.org/jargon/html/S/space-cadet-keyboard.html#crunchly73-05-19

Cheers,

Jacob.

Hi Micha,

> * I would like to see the ini file stored in the MoI programm
> dir - or can I simple move it?

You can just move it there if you want. When MoI starts up it looks for one in that location first and will use it from there if it finds it.

It is not placed there by default because Microsoft recommends that programs should not create or modify files in the \Program Files folder during regular program use (other than install times).

That's actually more than just a recommendation - it is enforced in other situations, like if you are logged in as a limited user (with no administrator rights on the machine), any attempt to modify \Program Files will fail, and under Windows Vista it will pop up one of those UAC "Do you want to allow" dialogs for a normal user.

So MoI places the .ini file by default in that other location to be compatible with these situations.


> * the ini could get some Space line between the different sections

You can just hit Enter at the end of any line to add in as many spaces as you want.

I wish that they were added by default, but MoI just uses the standard Windows functions to write the options to the .ini file, and when Windows adds a section it does not put a space before it. You would need to talk to Microsoft to update that behavior.

- Michael

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