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

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