Hi Michael, is it me or I can no longer use Object Snap if the object is covered by another object? Is there a way around it?

Hi Val -

> Hi Michael, is it me or I can no longer use Object Snap
> if the object is covered by another object? Is there a
> way around it?

Do you have the hidden line display enabled or disabled? In v2 check under the View tab here:



It is one of the new features in v2 that when hidden lines are disabled, hidden object snaps are also suppressed. Some details on that here:
http://moi3d.com/forum/display.php?webtag=MOI&msg=1621.35

But if you have hidden-lines enabled, then osnaps should be working on them - if you do have it enabled, make sure that Object Snap is not disabled itself (it should be highlighted in orange in the bottom toolbar when it is on), and you might want to check the object snap menu (the arrow that pops up when you move your mouse over the object snap button) to make sure that you haven't turned off all the individual types of snaps.

Otherwise, if you are having a problem with a particular model, could you please post it or e-mail it to me at moi@moi3d.com ?

- Michael

Sweet, thanks Michael!

I finally cought the bug I talked about before, but it happened a little differently than I described. It was a union between the two cylinders on the sides and the one that has holes.

Working on this project I found it difficult to readjust the angles on the device. It would be nice to have some simple rigging tools. Like one parts rotates the other moves with it but is kept with respect to x direction, etc..

Hi Val, thanks for reporting the problem!

It does look like it is probably a bug, but I'm not sure if there is much possibility to get a good result from that exact situation.

If you hide these 2 pieces here:



You can see that the center part is not a solid, it is an open surface:



If you actually select that open surface and run Construct / Planar to cap it off to be a solid, then you can get a proper union between it and the other piece like this:



When it is an open solid, the union is basically creating a sort of "squished together" slit in the objects rather than being able to separate them into different volumes.

In general the booleans are oriented mostly around working with volumes, so you may get some slightly unpredictable behavior similar to this when doing volume operations on non-closed objects that do not define a full volume.

If you solidify that open object first, you can avoid this problem.


> It would be nice to have some simple rigging tools. Like one parts rotates the
> other moves with it but is kept with respect to x direction, etc..

Unfortunately a rigging system is pretty difficult to add, even a simple one would require a substantial amount of UI - it is really something that is normally part of an animation system. The amount of work involved will probably make it prohibitively expensive to get that into MoI anytime soon I'm afraid...

- Michael

While it's obviously no easier, the ability to add constraints would probably work for what most people are looking for there, given the nature of parts designed in MoI. That said, with all of the new geometric intercepts, you're most of the way there. Possible, you could leverage the new style and group system -- pull up an object in there, get a list of all of its existing geometric relationships, and tell the system to enforce some of them. If you added a way to have construction planes, lines, and points stick around more, that would get you most of the rest; you could even do distance bounding constraints as being between two points on a cline. There'd still be some things that wouldn't cover, of course -- relative size constraints, for instance, although most of those cases could probably be handled by showing a list of the other constraints the current constraint could establish a relationship with.

That said, yes, big, big chunk of work, and probably a v4+ thing, I'm sure, but I'm another person who would love it, especially coupled with API additions aimed at making generative shape creation easier.

Hi Ella - yeah constraints would be great to have, but they are also a lot more involved than just enforcing a couple of things, it requires a pretty sophisticated solving engine that can deal with problems like over-constrained systems.

> especially coupled with API additions aimed at making
> generative shape creation easier.

One of the things that I would like to work on for v3 is a deeper history function, that would chain together a deeper set of actions than the current history function. That would then let you manipulate the original input objects and have your sequence of commands that you used replayed to recalculate the result.

That works to a certain extent right now, for example you can do an extrude and then edit the source curve and the extrusion will update. But it is currently limited, the history chain can get broken easily if there is any command applied which deletes (including delete + replace) an object in it. If I can make history survive through such actions it would be a big step towards that kind of generative design stuff.

- Michael

Right, I'd forgotten about the solving engine. Is that licenseable? I mean, it may not be worth while, any time soon, especially if it's an expensive license, but that seems like it might help; integration coding is probably easier than writing the core from scratch.

Having a more robust history and having it available programatically would be great. Honestly, it'd be nice to have it explicitly represented in the UI, too -- if you had an available, editable history, that might actually do a lot of the same work you'd lean on a constraint system for, at least in the trivial cases.

/Ella

Oh, thanks. I didn't realize the cylinder didn't have a surface, that is my fault.

As for the rigging, how about just a constraint system in the object properties. Where I can just say I want this to move only in X,Y,Z, or only rotate about XYZ? Is that a possible solution?

Hi Ella,

> Right, I'd forgotten about the solving engine. Is that licenseable?

Yup, there are some libraries that can be licensed. But the most commonly used one tends to be rather expensive.


> Having a more robust history and having it available programatically
> would be great. Honestly, it'd be nice to have it explicitly represented
> in the UI, too -- if you had an available, editable history, that might
> actually do a lot of the same work you'd lean on a constraint system
> for, at least in the trivial cases.

Yup, I would like to have a UI for the history... But it is a bit early yet, I'm not quite sure how it will all shake out.

- Michael

Hi Val,

> As for the rigging, how about just a constraint system in
> the object properties. Where I can just say I want this to
> move only in X,Y,Z, or only rotate about XYZ? Is that a
> possible solution?

Actually you can already do those simple kinds of constrained moves or rotates...

For example to move only in x, y, or z just turn on "Straight Snap" (make it highlighted in the bottom command bar), and then when you drag you will get snap lines which will constrain the movement to one of those axis directions when you move the mouse nearby them, here is an example:



Note that those labels "x", "y", and "z" will appear when those constraints are kicking in - the constraints are activated just by moving your mouse near to their directions when dragging objects with Straight Snap enabled.

Straight Snap is generally what you want to turn on if you want to do things constrained to different axes - it also allows similar things in other commands, for example when drawing a line if you want to constrain it to one axis make sure straight snap is enabled and you will be able to get the constraint when drawing the line as well.

Similarly you can already rotate around only the x, y, or z axes by using either the rotation grip on the object edit frame in v2, or the Transform/Rotate command. The axis is controlled depending on which view you do it in - if you want to rotate around the z axis for example, go to the Top view and do the rotation there.

- Michael

Ooops I don't know what I was thinking.

>>>One of the things that I would like to work on for v3 is a deeper history function, that would chain together a deeper set of actions than the current history function.

Are there any plans for MoI to adapt the New "trend" of history Free/Direct Modeling approach ?
Will History Based Modeling be a thing of the past?
Or a combination of the two methods in a correct manner is the best solution?

If we look the market it seem to me almost everyone digs History Free, Direct Modeling. I mean CoCreate acquired by PTC (a company with Parametric in its name), SpaceClaim, Siemens Synchronous Technology Autodesk Inventor Fusion etc.
History Free, Direct Modeling it appears to be the best thing ever happened since I have been involved with Cad. The funny think is that the tech is always been there, just someone made the wrong call twenty year ago... But hey is here now and I think is the way to go IMO...


Some articles to whom is interested on the topic.
http://www.sycode.com/publications/white_papers/cad_20.pdf
http://p-hamilton.blogspot.com/2008/10/key-capabilities-of-history-free.html
http://manufacturing.cadalyst.com/manufacturing/News/Siemens-Breaks-Free-from-History/ArticleStandard/Article/detail/511937
http://www.evanyares.com/the-cad-industry/2008/9/23/can-proe-be-made-easy-to-learn-and-remember.html

Hi neo,

> Are there any plans for MoI to adapt the New "trend" of history
> Free/Direct Modeling approach ?

I would like to work on some stuff for that in the future, but I plan to tackle a deeper history function first.

The direct modeling type approach tends to require a very sophisticated analysis and feature recognition type mechanism, that is a complex thing to make work well, and even then it is kind of limited in the things that can be recognized.


> Will History Based Modeling be a thing of the past?

No, this is not very likely as there are many kinds of models that are made up of more freeform surfaces that cannot be easily recognized by the direct modeling type approaches.

For one example, just check out the MoI Pod video here:
http://moi3d.com/1.0/docs/pod.htm

Check out around the 12:00 mark, where I edit the inputs to the sweep to tweak the shape, for example moving some of the points on the scaling rail and watching the sweep update.

You're not really going to see that particular kind of editing possible in a "direct modeling" approach because it is just too difficult to reverse engineer a complex freeform surface back into its original inputs, especially when multiple profiles and shaping influences have been applied to it.

For things like circles, holes, extrusions, primitives, that kind of stuff tends to be a better fit with the direct modeling approach, and many times mechanical parts are made up of only those kinds of structures, so that's why direct modeling is mostly oriented towards mechanical part design currently.


> Or a combination of the two methods in a correct manner is the best solution?

Yes, I think this is likely to be the case for very general purpose things.

But it does depend on what you are trying to do - if your goal is to only work on mechanical parts where there are no freeform surfaces in it at all, then there is a lot more chance that pure direct modeling with no history would work really well for that.

If you want to incorporate more stylized freeform surfaces into your design, that tends to make it more likely that you would need a history-based mechanism if you wanted to allow for adjusting the inputs to those freeform surfaces and have them update.


That Pod video should give you a good example on why direct editing can't just be applied as a complete blanket replacement for history - I believe you will be unable to repeat that scaling rail editing part of the Pod video in any current direct modeling system.

- Michael

Hi neo,

> Some articles to whom is interested on the topic.
> <....>

Just keep in mind that probably those articles are implicitly referring to only a specific kind of modeling, like mechanical part design.

Don't get me wrong - that is certainly an important area of modeling! But there are also other kinds of design work out there as well different from that.

- Michael

>>>No, this is not very likely as there are many kinds of models that are made up of more freeform surfaces that cannot be easily recognized by the direct modeling type approaches.

You are wright I did demo SpaceClaim some time ago and I must say I was not pleased with the way was handling surfaces from MoI or Rhino...Except that the workflow was very promising...
Thanks for the info I was not aware of it to be a general limitation...

>>>Don't get me wrong - that is certainly an important area of modeling! But there are also other kinds of design work out there as well different from that.

Not at all, "blobism" is part of what I do, so that creates more questions about the whole possess.

Perhaps DannyT could give us some info on how it works with Synchronous Technology in NX? (waiting for my demo). Ill Keep you posted.

Hi neo,

> You are wright I did demo SpaceClaim some time ago and I
> must say I was not pleased with the way was handling surfaces
> from MoI or Rhino...

I would think it should be able to import the surfaces fine, but if your model is mostly made up of freeform things, it probably won't exactly fit very well with how things work for editing.

But if your model has at least some portion of mechanical type shapes, I would think its editing should work well on those areas.


> Except that the workflow was very promising...

Certainly! And just generally since it has a different way of working than either MoI or Rhino it can be a pretty nice tool to have to use in combination with them.

- Michael

Hi neo,

> Perhaps DannyT could give us some info on how it works with Synchronous Technology in NX

Synchronous in NX is great for modifying models from other cad programs that are imported with no feature history, but as Michael mentions;

All our modeling is done in house, we rarely receive non native or parameterised models from outside, so we only use history based modeling, but in our line of work we need to model with history. In NX you can model in a number of different ways; with history, history free or a mixture of both, we do use Synchronous for convenience but I'd say it's used 2% for our modeling.

Also, depending on the imported data it can fail because of how other cad packages build surfaces and how those surfaces are translated, but all in all it does work like you see in the demos that you can find on youtube.

Cheers

Danny thanks for you reply, much appreciated.

Hi Michael!

I just wanted to say that from what i have seen and tested so far this is an awesome piece of software and I'm glad it takes path of the SketchUp (which I think is another brilliant software) and MoI has even better interface!! (and its very important factor as well - thing which turn us away from rhino)
SketchUp has been a problem for us (revit users) for its being a mesh editor while we need smooth SAT nurbs therefore MoI SAT export opens a lot of opportunities for us. A Nurbs editor similar to Sketchup (in simplicity of use) as damn good idea which I though was not possible..

But the most important factor (for purchase) is that the author is exposed to its users which cannot be overestimated, and the reasonable price which will definitely pay itself off many times.. I'm planning to buy it asap..

ps as for the future I wish that possible bugs and modeling needs are first addressed - as annotation and render&mats are not a problem and in majority of cases will be reassigned after export.. (and competition is really strong there)
Another point is re SketchUp outliner which has been extremely useful and kept very simple - just one list - yet very powerful obj management - something I wish MoI end up with

regards
I

Hi Igor - thanks, I'm glad that you are liking MoI!!

> Another point is re SketchUp outliner which has been extremely
> useful and kept very simple - just one list - yet very powerful
> obj management -

Actually, I thought that some of the object management tools in SketchUp were kind of separate things?

For example in SketchUp there is also a "Layers" window that you can pull up which is another list separate from the Outliner window. Do you mean that you never use Layers in SketchUp and only use the Outliner?

At any rate, a set of new object management tools is one of the major new features coming for MoI version 2.0, the first batch of which are included in the most recent v2 beta. Here is a screenshot:



This new browser has a few different sections that allow you to manage objects by making it much easier to process a predefined set of objects all in one click.

There are some different sections that use some different methods of organization but behave similarly.

For example if you want to do something to all curves, that can be handled in the "Types" section - that section allows you to target all objects of a certain type, like all solids, all curves, all edges, etc...

"Objects" allows you to refer to objects that have been assigned a name.

"Styles" allows you to refer to all objects that have been assigned a particular style (kind of like a layer or material assignment).

All sections allow you to do the same kinds of actions, like hide/show/isolate/select/deselect that set of objects with one click.

- Michael