Yes it should, considering that the cage control points only represent a matrix of spatial relationships.

All of the control points, and other surface-related coordinated would simple conform to the manipulation of the cage space. (??)

The cage would be made of a X by Y by Z lattice of control points, meaning that you could manipulate the cage points lying within the interior arrangement of the cage and allow for warping of your objects throughout.

Understandable. Although that seems to be just postponing the inevitable doesn't it? As the versions of Moi get "heavier" it will become more difficult I suppose. Just something that I've been seeing often lately with the newest v3 Beta Build while trying to export some heavy models with the "Insufficient memory" error coming up often. Or maybe this is related to the Beta itself? I don't recall having problems with exporting in the past, but maybe I just hadn't been working with heavier models. Moi is still my go to app for converting surface models to polys, but I also don't imagine that the models will get any "lighter" in the future.

Cage editing = "Soft selection" for MoI's points.

Hi Tree,

> Understandable. Although that seems to be just postponing
> the inevitable doesn't it?

Yes, but it's not like that's unusual at all - postponing things that require a lot of work is a normal part of the software development process, particularly when working with very limited resources.


> Or maybe this is related to the Beta itself?

Not as far as I am aware of.


> I don't recall having problems with exporting in the past, but maybe I just hadn't
> been working with heavier models.

Yeah it's probably that.


> Moi is still my go to app for converting surface models to polys, but I also
> don't imagine that the models will get any "lighter" in the future.

You should be able to avoid the problem by selecting just some portion of your objects (just half of them is a good thing to try at first), and then using File > Export to write those out. Export is short for "Export selected" and it writes only the selected objects out rather than everything all at once. Then after you've exported one half invert the selection and export the other half to a different file, then in your rendering program import both of those files and then you should have it all transferred over.

MoI is really more primarily focused on being a modeling tool where you create stuff in, it's somewhat more of a side effect that it happens to be good at converting existing CAD assemblies to polygons as well.


I think it will be possible in v3 for me to tune a couple of things up in some of the intermediate processing stages that will help to reduce memory consumption somewhat though. There are also other feature areas like instancing that can actually help out a lot more which I would probably be working on before trying to tackle 64-bit.

- Michael

Does it possible to have the generator's curves in a different color than default color?

Hi Pilou,

> Does it possible to have the generator's curves in a different
> color than default color?

By default colors of objects are controlled by what style they are assigned to, so if you want curves to be a particular color assign them the style you want.

- Michael

I can make that :)

I have remarked than using the Blend function this last want not works, because curve generators were again present and were selected against the real edges of surface!
So a different color should warn the user that 2 curves are overlaped!

Hi Pilou,

> So a differnet color should warn the user that 2 curves are overlaped!

But it is a feature of MoI that you are free to choose the colors of objects as you desire so that you can use style colors for your own organization scheme.

This kind of "use automatic color for certain objects" type of system like you are describing would be in conflict with the "you are able to set object colors as you wish" system that is currently used.

- Michael

So I must think at each time to draw alone curves in a different colors! :)

Hi Michael,

What Pilou is discribing is handy but not a necessity, in some CAD systems you can define a default style/colour to certain entities, it helps during modelling where just at a glance you can tell what the entity is for example; true lines=green, true arcs=blue, solids=magenta, surfaces=cyan, splines=olive etc. the user would have to set up the style/colour and then you would save that file as a template.

-

Hi Danny, it's more oriented in MoI that you might use the style colors for different kinds of structural grouping, not really as a type of diagnostic code like you're kind of describing. I don't really like to use colors in that type of a way (at least as a default) because like I described earlier I try to keep the colors available for you to use as your own labels and each color that is reserved for some kind of special meaning detracts some from the set that you can use for your own purposes without confusion.

Also if such a system is set in advance with some myriad of colors being displayed by default each having some special meaning, the special meaning for each one is totally lost on new users who just see a bunch of different colors with no idea what they all actually mean.

But in the future I do want to add some different kinds of view modes that you would be able to switch between, and each view mode will likely override the default display and then use colors for some specific diagnostic purpose at that time. Some different preset ones will probably be showing back faces and showing zebra stripes, and I guess a sort of "visually show object type" mode like you're describing could also fit into that kind of category. Those won't have anything to do with "styles" exactly since those view modes will override the regular display mechanism that by default shows objects in their style color.

But if you happen to like the way a particular diagnostic view mode functions it would probably be something that you'd be able to just leave on if you wanted your regular working display to work like that.

The idea for the view modes is that they'll also probably each be able to have their own lighting/shading settings that will override the default ones so that you'll be able to flip a view mode to easily see everything as gray matte or blue or red shiny/reflective and then back to standard mode by flipping just one view mode setting instead of having to manipulate a bunch of different settings and then reset them all.

- Michael

Hi Michael,

> it's more oriented in MoI that you might use the style colors
> for different kinds of structural grouping, not really as a type
> of diagnostic code like you're kind of describing.

It's not really a diagnostic code it's more of a pre-labling system, it's a setting where you either set a style colour to any entity being, arcs, sheet bodies, points etc. or leave everything as the default style colour or a mixture of both and still be able to manually assign any style colour you want, for beginners MoI will behave exactly as it is now, as you get more experienced and start delving deeper the option is there.

As I said, it's not a necessity but it's a nice feature.

Cheers

Hi Danny, I can see some complications from trying to intertwine style assignment based on object type - for one it's possible for a single object to change from an arc to a line for example if you turn on control points and delete all interior control points leaving only the end ones. Would you then expect for that control point deletion to also automatically change the style of the curve object from the "arc" style to the "line" style? And then on top of that it would not change if you had directly assigned a specific style to it? That seems like quite a mess of potentially confusing behavior and special cases...

If it's pre-labeling you want, you can make any object that you are about to draw to go on the particular style that you want by setting the "active style" by right-clicking on the style color swatch in the scene browser. So for example if you want to create some arcs on one particular style, set that one as the active style and then when you draw your arcs that's where they will go... Basically you set up pre-labeling by setting the active style by that right click on a color swatch.

I guess it could also be possible for you to use a custom modified arc command that had some additional script code placed in it that would put arcs onto a specific hard coded style initially instead of the active style, would that help for the kind of thing you're asking about? That will probably get pretty unmaintainable quickly though if you would want a dozen modified basic commands like that because then it's difficult to merge together any other updates or changes in new releases down the road. In the future I'd like to make a sort of hook mechanism where it will be possible to have a separate piece of script that can be set to attach itself to a particular command to just process its output or some specific piece of it without it having to actually modify the command script itself, it should help for some more kinds of customization with better resilency to updates and changes in the main command itself.

- Michael

Hi Michael,

> for one it's possible for a single object to change
> from an arc to a line for example if you turn on
> control points and delete all interior control points
> leaving only the end ones. Would you then expect
> for that control point deletion to also automatically
> change the style of the curve object from the "arc"
> style to the "line" style?

It's just an initial colour coding it's not expected to change if the entity changes.

I'll give an example where it's used, when curves are extracted or generated from a section of a part model that we need to use to model a mating or complimentary part we would like to see what the curves are made up of, usually the CAM guy's prefer lines and arcs for ease of cutter path generation and smaller data files especially on comlpex shapes, when we see splines generated we try and simplify them into basic joined lines and arcs, so you could imagine if there are 100's of curves generated from a section and there were only two or three splines in there to be simplified you would have to pick on each seperate entity generated to see if it was a line, arc, spline or even an ellipse.

To tell you the truth Michael, I don't think I would use this with MoI because I use MoI for different type of models compared to my everyday software, I just tagged along with Pilou's first post on this topic and didn't really want to stretch the subject this far, thanks for your interest anyway :)

Cheers

Hi Danny, so from your example that you mention there that definitely sounds like it's being used as a diagnostic tool. I mean if you're using it as a visual method for determining object type, that's a diagnostic or analysis type function...

Why wouldn't a view mode that temporarily changed the display to show colors by object type (like I was describing earlier as a potential thing in the future) give you what is needed for that particular kind of examination?

- Michael

Hi Michael,

> Why wouldn't a view mode that temporarily
> changed the display to show colors by object
> type (like I was describing earlier as a potential
> thing in the future) give you what is needed for
> that particular kind of examination?

Yep! that sounds good to me........now waiting for the future :)

Cheers

Hi Michael,

Please consider an improvement: Auto-panning while making a selection box or holding objects.

You know how when you pan with the mouse and run off the side of the screen and the viewport automatically tracks in that same direction?

CorelDRAW does that whenever you are holding objects or points too, or when you are making a selection box. It just auto-pans the same way MoI does it when you are using the mouse to pan.

Can MoI possibly do this too?

Iit would be helpful if you are trying to box select a small sliver of objects that go off the screen, but you don't want to have to figure out how to select more of the same area after panning.
Or in other words, it would help if MoI would pan as soon as you run out of viewport, especially when you are holding an object or points.

Right now, it just hits the wall and goes thud. And when MoI has teased you with it's groovy auto-pan (while panning) feature, it's kinda a bummer. :-/


... or am I missing something.

Thanks.

Mike

PS... I figured out that when you are moving objects and points, you can simply click and drag with the mouse key for panning and re-adjust.
That still doesn't work when making a selection box.

Yep - I'm a Corel Draw user too and auto-pan when you run out of screen would be great for MoI. Especially MoI under WIN8 on a MS Surface :)

Ed

Hi Mike, so there is actually a complication with that which involves the perspective view.

When the perspective view pans, it actually changes what would have been displayed in the now off-screen portion of the selection box. So it makes it kind of awkward to do things that try to work with screen space like selection boxes while allowing panning in perspective.

The auto pan that does currently work is only focused on changing the view and not on simultaneously trying to track some containment in screen coordinates at the same time, so that's why that one is feasible.

Perspective views have this kind of weird non-linear behavior that can complicate some kinds of things like that, like a small movement of perspective view panning can move some things on the screen much more than others - things that are close to your eye point will whiz by and things that are far away move only a small amount on the screen.


re: while holding objects, you mean doing an auto pan for dragging objects? There is a different complication with that, which is that it's currently possible to work in split view and grab an object in the Top view where you can get it more easily but then actually move your mouse over to the Front view and thus move it upwards in elevation. The thing that makes that possible is being able to continue the drag in a different viewport - if dragging did not ever let you leave the viewport you started in and instead panned the view it would then eliminate that function.

- Michael

Hmmm...

I see right now that when you move and object and cross over into another viewport, you find yourself holding the object in a different orientation according to where your cursor is relative to that new viewport.

For an auto-pan to work, while dragging an object, MoI would know to not allow you to cross over into the adjacent viewport, but you would stay in the intended viewport with the panning now taking place.

- just like it does now when you simply hold the mouse button for pan and drag the cursor point through the boundary edge.

It should work in perspective view as well if the pan movement is focused on the relative course dictated by the cursor movement. Where as, with a mouse pan in the opposite direction does this currently.
Since the aspect of the perspective view may change as you pan wherever your cursor is sitting, so would the carried object.

There might need to be some figuring to make it move right if done in a perspective view, but I think it would work fine in the ortho views.

When I think about it, if I'm moving an object (at least in the ortho views) my eyes want to work in that view, when it jumps somewhere else because it crossed over and it is now in a new frame of view... well, I don't know, is bouncing around with the same object from one view to another a common workflow practice? :-/


So, to clarify. (in theory), the object and cursor would stay in the intended view (by which the mouse key was held down) and the viewport would pan in that relative direction - instead of crossing over into the next view and jumping the object somewhere else. - relative to the way the focus remains in the intended viewport when the pan is held down.