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

Michael,

Thank you for quick reply!

I do not use beta - v1.1 trial, but i have read all your posts concerning and explaining the new obj management interface.

In SketchUp the layers palette is much of a redundant tool and used very occasionally. For obj management needs we employ outliner exclusively... Not only because it is more convenient but because layers have some nasty issues if you try to use them as obj management.. I think the layers palette only exists there for imports from CAD..

As a note I actually used to design application interfaces in the past so I usually pay attention to how they are implemented. MoI, so far as, I said, has a superior interface.. Although there's always room for improvement ))

Also I'm impressed with the convenient API implementation.. javascript comes in very handy (no need to learn ruby, actionscript lisp or any other stuff BUT have searched and couldn't find any sort of help on it? (just commands but they do not provide any systematic description..)

Another major point is that the interface also exposed to a user (not everything but enough to play with!!! less work hopefully for you in the future.. very good decision.. thank you!

re interface:

It might be useful to be able to hide some of the tabs as in sketchup (styles or types or objects - especially styles for me)) as they will eat up space if I use inline mode (i have 1200 px ver resolution and am going to use this mode most of the time) but it is not urgent - in v04 shall be OK.

What also may confuse new users (and confuse me a lot) is that there's a little inconsistency in highlighting tabs and buttons (eg Grid snap, Object snap) - these ones have orange highlight - which clearly indicates they are ON but the tabs on the right have a different highlight to show they are ON (actually every time I click I stumble over those which is ON? white or light blue? )) I'd stick with orange - same as office and Max (although I know I can tweak it myself, hopefully).

Other interface improvement I'd suggest is making clear which numbers stand for X, Y, Z coord. as they are in the same box.. (I know it was designed to serve as a command line as well - so maybe just sort of a prefix for a number?

re obj management:

There's definitely some reasons for the current layout I admit, so my comments here are from a mesh modeler viewpoint (I haven't been modeling too much nurbs) but what I would first have implemented is just two tabs - objects (as in sketchup - show grouped items and components), and types (types are modeling aids like those in max if understood correctly?) not sure if it is the best solution - Max people kept complaining that it makes them click too much (rhino as I understand was trying to reduce clicks with pop-ups) but nevertheless I highly welcome all this improvements..

And thank you for taking time to read all this, hopefully all this can help make MoI more productive..

regards,
I

Hi Igor,

> Also I'm impressed with the convenient API implementation..
> javascript comes in very handy (no need to learn ruby,
> actionscript lisp or any other stuff BUT have searched and
> couldn't find any sort of help on it?

No, there is not currently any organized help file for the scripting interface.

Unfortunately producing documentation is not really a very easy task, it tends to take quite a bit of time to do it.

If I were to focus on producing documentation for the scripting interface stuff, that would mean taking time away from other areas of more "typical end user" type work areas such as implementing the browser, making meshing multi-core enabled, etc... There are just too many basic bread-and-butter features that are taking priority still.

Since I am the only person working on MoI, I kind of have to be careful with my priorities. Areas that require a lot of time-consuming work to finish and don't typically impact a large number of people just need to have a lower priority over things that are more widely used.

Anyway, that's why it hasn't been a high priority yet to work on the scripting documention.

But I do want to work on some scripting documentation at some point in the future though!


A few people have learned it just by studying the existing examples, if you want to dig into that, there is a link to the moi.idl file here: http://moi3d.com/wiki/Scripting and there are several examples of scripts and custom commands that some others have created here: http://kyticka.webzdarma.cz/3d/moi/



> It might be useful to be able to hide some of the tabs as in
> sketchup (styles or types or objects - especially styles for me))
> as they will eat up space if I use inline mode

Actually it already works to collapse those entries down, for example clicking on "Styles" will either expand or collapse that entire section. When collapsed each of those sections becomes compact, only taking up a single line.

Or do you mean some way to hide that entry entirely rather than collapsing it? That's quite a bit more tricky because of course then there also needs to be some way to show it again..


> I'd stick with orange - same as office and Max (although I
> know I can tweak it myself, hopefully).

Those "orange" ones and the palette tabs are actually different controls - the "Grid Snap", "Straight Snap", and "Object Snap" control a setting for snaps being on or off but do not directly make other UI appear or disappear. The tab controls have a much different action - they do not control an "invisible" setting and instead directly control the visibility of a section of the UI.

Since these controls do some different things, it is actually good for them to have a somewhat different appearance between them.

This is really pretty standard actually... For example you mentioned Office. If you check out Word 2007, you should see that the tab control for the Ribbon which controls visibility of chunks of UI is not the same color as a state button such as the Bold button. There the Bold button is orange when "on" but the active tab is not orange.


> Other interface improvement I'd suggest is making clear
> which numbers stand for X, Y, Z coord. as they are in the
> same box.. (I know it was designed to serve as a command
> line as well - so maybe just sort of a prefix for a number?

That would look fairly strange, it would kind of have an effect of cluttering things up since there would be numbers and labels all within the same input box.

I'm not really sure there would really be anything to gain - I mean the way it works is very simple - the first number is the X value, the second one is Y and the last one is Z... XYZ is such a traditional ordering for Cartesian coordinates that a label really isn't necessary here.

To have labels like you are talking about would pretty much require 3 separate controls to look normal (with a label followed by an input field), but that would eliminate quite a lot of functionality for instance being able to type in polar coordinates, relative coordinates, 2D coordinates without having to type in z, using 0 for a shortcut for 0,0,0 ... by having XYZ in one field it enables quite a lot of input functionality.

Another pretty big issue for this control is space - coordinates can sometimes have quite a few digits, and there isn't much room to hold them all there. Putting in additional labels would exacerbate this problem and result in fewer digits being able to be shown. It's also not particularly easy to just increase the size of the control to compensate because it nearly takes up all available space on a 1024x768 display already.


> types (types are modeling aids
> like those in max if understood correctly?)

Types are used for working on all entities of a certain object type, like "all curves", or "all solids". It's not unusual in NURBS modeling to end up with a bunch of construction curves hanging around after you've built a few things. So it can be handy to have a quick way to say "I want to hide all curves but leave all solids". This part probably doesn't apply so much to poly modeling.


> but what I would first have implemented is just two
> tabs - objects (as in sketchup - show grouped items
> and components),

That would leave out a couple of major areas that have been frequently requested.

One is to be able to assign materials to objects so that when you do a mesh export, you don't have to worry about material set-up later.

The other is to have an optional organization method that is compatible with layers for export to other CAD systems.

That's why there is a Styles section which is kind of a hybrid of these 2 areas.

If I left that section out, then the object organization tools would be missing some major sections of stuff that people have requested that it should be able to do...


I hope that explains some of the reasoning for the current designs, thanks for the feedback!

- Michael

I'd agree with Michaels direction - when you get used to the browser system it really is a powerful way of organising your file and once it's finished and we also have instances im sure it will be one of the best systems out there. I use the 'types' filter all the time, it's great for letting you very quickly isolate elements. Also the right click feature on a style instantly isolates that style without having to manually switch everything else off - very handy and quick.

EDIT: Although it would be nice to add a new style from scratch rather than having to draw something then select it and then create a new style ;-)

Michael,

Thank you very much for your answers.. I start to feel a bit worried that I'm taking too much time off your work
Gonna try beta very soon though..

The only little point is the ms ribbon is very arguable interface for reference (some people refer to it as fundamentally wrong) and many people on ms & autodesk forums feel very sad about it... others don't upgrade at all.. (unlike 3ds people- who are relatively happy)

Here we have sort of a ribbon type as well but.. absolutely different in implementation - times and times better than that of MS and I really liked your point that core tools' icons mustn't move around (in some previous post).

From psychological part of the color theory - orange (yellow) and light blue & are opposite in their impact as a highlight. That's why white seems to be a highlighted state - not the light blue..

Love to hear you have instances here too..! need to check help on those (as they are what makes SketchUp so powerful..!!)

Regards
I

Hi Igor,

> Love to hear you have instances here too..! need to check
> help on those (as they are what makes SketchUp so
> powerful..!!)

Actually MoI does not have instances currently, that is something that I want to add in the future at some point, sorry for the confusion!


> The only little point is the ms ribbon is very arguable
> interface for reference

In this case I was just referring to it because you previously wrote:

That's the part I was confused about - how can I be orange like office when office's tabs are not orange?


A discussion about the ribbon is certainly a whole different can of worms! :)

But there is certainly no doubt that the main concepts behind the ribbon are sound ideas, I mean the fundamental one is that unless your program is trivial you just can't have all the program's UI showing simultaneously, there has to be some way to switch chunks of it on or off.

MoI's UI is designed with much of the same fundamental ideas but with some different implementation. Early on I had tried doing just one big tabbed horizontal container, but it creates a rather excessive modality. That may not be bad if your workflow tends to spend a lot of time in one particular mode but if you need to bounce back and forth a bit between a couple of things it is good to have the possibility of having multiple tabs open simultaneously in smaller groups, which is what MoI's implementation does.

There is certainly a lot of "force everything into the ribbon" type stuff going on out there right now in the development world, sometimes with some bad side effects...

- Michael