What is exactly the finality of the Object system?
Just a great "selector" for easy use of complex objects or also something for manage them ("Copy" / "Move" / "Delete" etc...) inside the arborescence?

Hi Pilou,

> What is exactly the finality of the Object system?

The main goal is to make it easier to work on a more complex project that has many different pieces in it, by allowing certain basic functions like hide/show/isolate/select/deselect work on a predefined batch of objects.

But you still use it in combination with the regular tools, for example it is not meant to replace every single tool such as Move/Copy/Fillet, etc...

You can use it to more easily select objects that are used in those tools though, and really its overall main purpose is to make it easy to manage visibility so you can turn off different sets of objects quickly to make it easier to work one smaller area of a complex model at a time.

- Michael

Hi Michael,

sorry for getting back to you so late.

I think the new look fits MoIs overall style better.
I'm not sure about the divider line though. I think BurrMan is basically right: Normally if you use tabs, the opened tab has no dividerline towards the open area of the tab.
But I tried it out in Photoshop, and without the line the heading is pretty weak...

And somehow I am still missing consistency with the rest of the GUI (which I like a lot).
I'm not sure if you need to introduce new elements at all.

So I went to explore the existing elements some more in Photoshop...

First I created a header for the Scene Browser (without a + sign) that would be collapsible like the other toolboxes to be consistent there.
In this form it doesn't take much space when collapsed (see the top of the image below) and I think that one line doesn't take away too much screen estate while it helps the overall consistency. Also, you can collapse the Browser with one click, equal how many of the sub-tabs are open.

Then I took the existing idea that you use in the headers of all other toolboxes and played with them. They aren't exactly "tabs", but work very well for me as headers for the toolboxes.
Putting them completely inside the existing frame of the scene browser would create a doubleframe which would be a bit overdone, so I tried using the rounded corners "connected" to the outer frame directly and well - works for me and fits in pretty well with the rest of the GUI IMHO ;-)



No new elements needed, the headers are clearly visible and divide the groups very well while being light on the eye and no problems with the tab-divider-line.
I also wasn't too hot on the light blue header color (again more a consistency thing).

What do you think?

Best Regards!

Thomas

P.S. I think Pilou brings up an interesting point. Being able to create hierachies of named objects (move the parent and it will move the child as well) like it works in many other 3D tools could be helpful. Also having some basic "file-like operations" in the right mouse menu would be interesting (copy, paste, delete...).

Hi Thomas, thanks for the feedback!

> I'm not sure if you need to introduce new elements at all.

Well, those are some new controls that have some different behavior than previous elements. So having a look that is in the same general theme but slightly different is actually something I consider to be a positive thing - things that work a little differently but look exactly identical tends to cause problems. A lot of people will assume that things that look identical should behave in an identical fashion as well.

The main issue is when the browser is in "inside" mode, where the browser is another palette located inside the side pane with the other tools such as Construct, Draw curve, etc... In this mode, the browser sections are child elements inside of the "Scene browser" palette, and clicking on the "Scene browser" palette header hides or shows the entire browser palette, while clicking on one of those child sections only expands that sub-section.

If there was no "inside" mode, and only an "adjacent" mode, then I would have very likely have done it right along the lines of what you are showing.

But there is an "inside" mode to consider as well.


> First I created a header for the Scene Browser (without a + sign)
> that would be collapsible like the other toolboxes to be consistent
> there.

It looks like you are talking about a collapsible title for the "adjacent" mode there?

But what purpose would be served by collapsing that?

When collapsed you would then have a panel that was nothing but empty space inside of it, I don't really see what would be the gain from having that... If there is no purpose for something, it can be nice to just not have it - and there are actually benefits to having less UI, for example having that header means that there is not as much space for the actual browser items, there would be something like one less item able to be shown before getting a scroll bar.

In the future at some point I may be able to have some purpose to have a title section there, like 2 different panel options to switch between (like Browser / History), so it is something that may be good to add in the future, but only when it actually serves a useful purpose.

When in "inside" mode, there is a title there because it may be useful to collapse the browser there since it is sharing space in the side pane with other palettes in that mode.


> <..> works for me and fits in pretty well with the rest of the GUI IMHO ;-)

It does work well for the "adjacent" mode like you are showing - I'm pretty sure that if that was the only way, that I would like to set it up like that.

But with "inside" mode, having the child sections look the same as the parent one is not good - they look too much like they are siblings on some kind of equivalent level rather than the palette being the parent and the sections being children and distinct from the palette header.


> I also wasn't too hot on the light blue header color (again more
> a consistency thing).

Yup - again too much identical consistency between the parent header and the child sections in "inside" mode is a bad thing - that's the reason for the intentional difference there.


> Also having some basic "file-like operations" in the right
> mouse menu would be interesting (copy, paste, delete...).

Actually, right-click actions are already filled up - right-click on an eye will do an "isolate" where it shows only that item and hides others, right-click on a style swatch will set it as the active style, and right-click on an item's text will do an "isolate selection" which will select just that item and deselect others.

So making right-click put up a menu would mean sacrificing some of this other existing functionality.

But in the future I do want to make a drop-down menu, probably with a drop-down box that appears on the right-hand side of the item, which you would left-click to pop out.

That will probably be fine to put in a few frequently used operations on that menu, but I don't think that will be happen for v2 though, probably that one will have to wait for a bit longer.


Thanks very much for the ideas and the image tests!

- Michael

Hi Michael,

I didn't do this testing for a specific one of the two modes, since it should be the same for both IMO. I only used the adjacent mode to see the two designs side by side and to not have such a long screenshot. So yes, collapsing the title is actually only useful for inside mode (or if the panel would vanish and only leave the title when it's collapsed...).

I don't agree with you on the titles being too similar but thats just fine when talking abut design ideas ;-)
"they look too much like they are siblings on some kind of equivalent level" - that is what they are for me - "Scene Browser" just kinda groups them, but each section is independent and does something else. I would have the same feeling if you would group all the current "tools palettes" into one collapsible parent group.

I'm looking forward to what you come up with in the end!

Cheers,

Thomas

Hi Thomas,

> I didn't do this testing for a specific one of the two modes,
> since it should be the same for both IMO.

The actual browser control itself (which is made up of the sections: Groups, Objects, Types, Styles) should certainly be the same, and it is...

But the container that owns the control is a different issue - that is a separate thing from the control and does not necessarily need to be identical.

In the side pane where there are other palettes that work as containers, then the browser control should be nested inside of a palette container. For the "adjacent" mode where currently the whole panel is dedicated only to hold the browser and not any other palettes, there is no need to add in a "lone" palette container there, it would just not serve any useful purpose (not yet, anyway).

I mean really the whole reason to have more than one mode for the browser ("inside" versus "adjacent") is actually to have different container methods for it.


> "they look too much like they are siblings on some kind of
> equivalent level" - that is what they are for me

They literally are not siblings - when in "inside" mode, the palette header is at a higher level of the UI hierarchy and the scene browser control is nested within the palette body as a contained child element. Then clicking the palette header causes the entire browser control to be hidden or displayed - that's pretty clearly a parent/child relationship rather than a sibling relationship...


Anyway, I hope that explains some of the reasoning behind the design, and why some of the alternates that have been shown do not quite fit.


Also, if you end up not liking some of the particular colors for some reason, you will actually be able to edit the PNG files to suit your own personal taste if you want.


At any rate, for the next beta I've eliminated that "tail" part of the header UI that is in the current beta which seemed to be what was bothering you the most.


- Michael

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