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