Hi Micha, I guess for the automatic version to work you would need some different behavior for the Rhino _run command.

You'd want a version that ran the program and also waited for that program to exit before it let Rhino continue on normally.

You might want to ask in the Rhino newsgroup if anyone out there has developed a plugin to do that task already.

If not, that may be a good enhancement request for the regular Rhino _run command to be able to take an optional scriptable "WaitForExit=true" or something like that.

- Michael

Thank you for the hints. I will ask at the Rhino forum.

Michael, is it possible to pack all scripts in one *.cmd file, so that I could create different files for

* open MOI3D with a 3dm model
* meshing with UI
* meshing full automatic

I have the feeling the convert.js and the batchconvert.js could be packed in one file and maybe this script could be packed in the *.cmd file.
I try to get it clearly arranged. :)

Hi Micha - some pieces can be combined into one - the 2 .js files can be combined into a single .js file.

To do that, just find the spot where one file is doing an #include of the other file, and remove that line and paste in the contents of that included file.

#include is just a way of saying "paste the contents of this other file here".


However, I don't think there is a good way to combine the .cmd file with the .js ones - those are being used and run by different things.

The .cmd file is being run by the Windows shell, and the .js files are run by MoI.exe .

Since they are run by different programs, I don't think that you can combine them, that is kind of like saying how can you combine this Word .doc file with this .3dm rhino file - they are both files with data in them but they are used by different things so they can't necessarily be combined.

But it may be possible to actually eliminate the .cmd file entirely if you can figure out a way to make Rhino's _run command take 2 sets of parameters surrounded by quotes - one for the path to moi.exe and one for the command-line arguments to give to moi.exe .

- Michael

Sorry, so much questions. I try to send a file to MOI, so that it is shown and the meshing dialog is open. It's like this script, but in the background should be visible the MOI interface for a visible control of the meshing. Is this possible? I found no option to enable the general UI.


function Convert(FileName)
{
var gd = moi.geometryDatabase;

// Open the file, set 2nd param to true to suppress any save changes prompt.
gd.open( FileName, true );

// Create the output file name by breaking off the file extension and adding 'obj'.
OBJFileName = FileName.substr( 0, FileName.lastIndexOf('.') + 1 ) + 'obj';

// Save out to the output file, passing the option to suppress the UI. You
// add other options separated by semi-colons with no spaces. These
// options are available for controlling the meshing:
// NoUI=true
// Angle=12.0
// Output=ngons | quads | triangles
// MaxLength=0.0
// MaxLengthApplyTo=curved | planes | all
// MinLength=0.01
// AspectRatio=0.0
// Weld=true
// Display=shadedwithedges | shadednoedges | wireframe
// ExpandedDialog=false
gd.saveAs( OBJFileName, 'Angle=12.0;MinLength=0.01;MaxLength=1000;AspectRatio=20;Weld=true;Output=quads');

// Let's clear out and suppress any save changes prompt again.
gd.fileNew( true );
}
Convert('d:\\Temp\\moi.3dm');
moi.exit( true ); // Pass true to suppress save changes prompt.

Hi Micha, sorry no there is not currently any way to make the main window displayed when you run MoI with a command-line script.

This method of launching a script given with a command-line parameter was mostly intended as a way to have MoI silently process things in the background.

But I don't think it should be difficult for me to add another parameter that you can specify on the command line options that will make MoI show its regular user interface for this, I'll give that a try for the next v2 beta.

- Michael

Thank you for all your effort. :)

Hi Micha,

> It's like this script, but in the background should be
> visible the MOI interface for a visible control of the meshing.

I've updated the next v2 beta so that it will now be possible to make this work (to have the full UI displayed so you can see the viewports and mesh result while running the batchconvert.js script).

The way it works is you specify /showwindow as an additional command-line parameter for MoI.exe .

For example I have attached an updated LaunchMoIBatchConvert.cmd file that has this set in it.

Again this will work not in the existing Jan-19 current beta, but should work in the next released one. Hopefully it will not be too much longer before the next one is ready maybe something like a week but it is hard to say exactly.

Once the next beta is out, please let me know if you run into any problems with this new option.

- Michael

I'm curious - thank you.

Hi Michael,

I tried the new command now. My workflow was, that I select a NURBS object at Rhino and press my "Moi" button

_-export "d:\temp\#moi.3dm" _enter _enter
_-run "C:\Program Files (x86)\MOI 2.0\MOIConvert.cmd"

than the CMD was started

"C:\Program Files (x86)\MoI 2.0\MoI.exe" "C:\Program Files (x86)\MoI 2.0\MOIConvert.js"

and the MOI meshing UI pop up.

But if I add the /showwindow to the CMD file, than I get the MoI UI only, without NURBS object and meshing UI. Do you have an idea what's wrong here?

The MOIConvert.js contain this code:

function Convert(FileName)
{
var gd = moi.geometryDatabase;

// Open the file, set 2nd param to true to suppress any save changes prompt.
gd.open( FileName, true );

// Create the output file name by breaking off the file extension and adding 'obj'.

OBJFileName = FileName.substr( 0, FileName.lastIndexOf('.') + 1 ) + 'obj';

// Save out to the output file, passing the option to suppress the UI. You
// add other options separated by semi-colons with no spaces. These
// options are available for controlling the meshing:
// NoUI=true
// Angle=12.0
// Output=ngons | quads | triangles
// MaxLength=0.0
// MaxLengthApplyTo=curved | planes | all
// MinLength=0.01
// AspectRatio=0.0
// Weld=true
// Display=shadedwithedges | shadednoedges | wireframe
// ExpandedDialog=false

gd.saveAs( OBJFileName, 'Angle=12.0;MinLength=0.01;MaxLength=1000;AspectRatio=20;Weld=true;Output=quads');

// Let's clear out and suppress any save changes prompt again.
gd.fileNew( true );
}
Convert('d:\\Temp\\#moi.3dm');
moi.exit( true ); // Pass true to suppress save changes prompt.

And other question to this topic - could it be possible, that an automatic reset of the views is done after a file is opened? The problem is, if I try to mesh an object from Rhino, than the object could be outside the default view.

An other poblem, but not so important - the display mesh show some artefacts at this opended Rhino sphere. Is it normal? The exported mesh looks good, so it no problem for the daily workflow here.

Regards,
Micha

Hi Micha,

> Do you have an idea what's wrong here?

I suspect something may not be right with your MOIConvert.cmd - make sure when you add the /showwindow parameter that it has a space character separating it from any other parameters. Otherwise if things are not separated by spaces they become glued together into one parameter.

So for instance a .cmd file with content like this should work (this is tested with my machine):

"c:\program files\MoI 2.0 beta Apr-12-2009\moi.exe" "c:\scripts\MOIConvert.js" /showwindow

If that is not what was going wrong, please show me exactly what content you have for your .cmd file.


> And other question to this topic - could it be possible, that an
> automatic reset of the views is done after a file is opened?

Yup, this is easy to add - modify your MOIConvert.js file to have a new line of code added with a call to moi.view.resetAll(), after the call to open(), like this:

// Open the file, set 2nd param to true to suppress any save changes prompt.
gd.open( FileName, true );

moi.view.resetAll();



> An other poblem, but not so important - the display mesh
> show some artefacts at this opended Rhino sphere. Is it normal?

No, that is not supposed to happen. It looks like a bug, similar to one that I had thought was fixed up.

Does this happen to any sphere or only one in a particular location?

Can you please post the sphere so I can double check that? If that bug is still in there, it could possibly have an effect on exports in other situations so it would be good for me to take a look at it.


By the way, I think that now with this new release all the bugs you reported in that other thread should be fixed up - there were a few different ones like "Avoid smaller than" sometimes not working well and increasing polygon count when there were long skinny parts, aspect ratio not working well with that one surface with a pole, also incorrect normals on that same one with a pole also fixed, I think there was a triangle leak thing that was fixed (your Mesh#5 example), and also some quads that were split into triangles which will now stay as quads. Also one that had a flat plane with a couple of small spikes coming up from it. I don't think that there are any bugs left that you reported there. But I have not yet had a chance to add in new meshing parameters yet though.

- Michael

:) That's great, thank you for the hints. Anything works like expected now, the workflow makes fun.

Sorry, something was wrong with my new beta install path and so the sphere mesh issue was, because the old beta was opened. I fix my install error and anything is fine now. :)

A question for further improvements of the Rhino2MoI meshing. Do you see a chance to keep the Rhino layers so that the imported meshes are back to the original layers? If I remember me right I read that you plan to name the mesh material names by style names? I don't know so much about Rhino scripting, but could it be possible per Rhino script, that the reimported meshes are saved to layers with the material name?
Best would be, if the Rhino material and layers could be keeped during MoI meshing. I know, that's not your job, but maybe you have an idea. ;)

Hi Micha, that's great that it is working for you now.

> Do you see a chance to keep the Rhino layers so that the
> imported meshes are back to the original layers?

Well, I guess it depends on what kinds of things Rhino's OBJ importer will read from the OBJ file.

I don't know if it will read in material definitions or not... These are "usemtl" statements in the OBJ file, which I do plan to generate from the style assignments in MoI (not working quite yet though).

If Rhino's OBJ importer is able to construct layers from material assignments, then I guess you will be all set up.

But if it doesn't, maybe there will be some other possibilities, like if it does read in an object name maybe before generating meshes the export script can be modified so that each object is given a name for the style/layer that it is on, then if that information is read into Rhino it would be possible to have a script in Rhino that would look at object names and put those objects on those layers.

- Michael

Hi Michael,

my current workflow for MoI meshing of Rhino object is, that I select all object of a layer and mesh it per MOI. Than I delete the Rhino objects (or move it to a TEMP layer), import the MoI meshes and set the old layer for it. This I do for several layers. My problem is, that I like to use the previous used mesh settings for the next meshing. Could it be possible to set an option like "use last meshing parameters" at the ini file? At the moment I must set the parameters again and again. Maybe it's something for the wishlist.

Regards,
Micha

Hi Micha, I've added a new setting for this in the next v2 beta.

[Mesh Export]
PersistSettingsBetweenSessions=n

If you switch it to be =y then the parameters will be saved when you exit a program session, and restored when you start up a new program session.

I think that should solve the problem you are talking about here.

- Michael

Thank you very much.

:)

Hello Michael,

thank you for the new beta release. :)

I have a question for the usage of the ini file. Some weeks befor I copied the ini file to the MOI 2.0 directory so that I can easier found it. Now I installed the new beta over the old one, but the ini file isn't updated with the new options. I manualy added the option Persist..., but it dosn't work.

It seems to be that a new ini file is writen somewhere at the ..documents..\.. dir - I can't find it. If I want to keep my old settings, than I must manual merge both?

General it could be nice if all settings could be set within in MOI. It's no complex UI needed, but it could help to get an easy and quick access.

-Micha

Hi Micha - often times if an option is pretty specialized and has only been requested by a single person, I'll only add that in to the moi.ini file and not put it in the main UI, at least initially. As time goes on and if more people ask about it, then I'll generally move it into the main options UI at that point.

That's so that the main options UI does not become extremely complicated with such a large amount of things in it, especially with many of them that are only of interest to just one person or a very small focused group.

Otherwise, if I did make a policy like you are asking, to have every setting available in the main UI, that would then mean that I would just not have many options available like this at all, in order to keep the main UI simplified for more typical use.

So that's why I would not make such a policy - it is actually not having such a policy that makes it possible for me to make special settings like this at all. Otherwise, I would remove many of these options and that is probably not what you want, right?


It's probably best to install the new beta into its own folder like it defaults to, rather than in the same folder as an existing previous beta. I don't test that kind of "doubled up" install, and it could possibly cause difficulties with things such as uninstall later on.

Also it is a good idea to install them side by side so that you have the old version still available if there is some kind of bad bug in the brand new one.

After you install the new one, if you want to have the moi.ini in the same spot as moi.exe then just copy it over to your new installation.

Then the way that new settings work is that they will typically get added to the moi.ini file the first time that you run MoI and shut it down, although possibly some areas may not get added until the first time that you use that particular area, that's probably what happened here, those particular settings will only get touched if you actually generate a mesh during a session and then exit. If you don't generate a mesh then the mesh settings code does not get run and does not generate the new entries in moi.ini .


> It seems to be that a new ini file is writen somewhere at
> the ..documents..\.. dir - I can't find it.

If it does not find an existing one in the application folder, it will create a new .ini file with default settings, located in:
C:\Documents and Settings\ [your login name] \Application Data\Moi\moi.ini .

That's on Windows XP, on Windows Vista it will be in:
C:\Users\[your login name]\AppData\Roaming\Moi\moi.ini


> If I want to keep my old settings, than I must manual merge both?

No, just copy your old moi.ini to the new application folder and then you'll have all your old settings copied as well.

Any new entries will get automatically added to it after their feature areas are used the first time. But you can also add them in manually as well.


> I manualy added the option Persist..., but it dosn't work.

The persist option should look like this to enable it:
[Mesh Export]
PersistSettingsBetweenSessions=y

Can you please check to make sure you have correct spelling and that it is in the right [Mesh Export] section? I just gave it a try and it seems to be working over here...

Please let me know if you still can't get it to work.

- Michael

Hi Micha, also one thing to check - when I previously wrote that the new setting would be:

[Mesh Export]
PersistSettingsBetweenSessions=n

What that actually means is that there will be a new entry "PersistSettingsBetweenSessions", which will be under the [Mesh Export] section.

If you manually add that in, you need to find the existing [Mesh Export] section, and then paste the new PersistSettingsBetweenSessions= line under that, don't add in a second [Mesh Export] section.

Also note that you'll need to make the setting say =y instead of the default =n if you want the new persist behavior.

- Michael

Hi Michael, it works now. It was the mesh option at my MoIConvert.js script file that override the "persist" allways. Thank you. :)

For the options UI - in the past at Rhino 3 there was a render plugin called Rhinoman. It allow to render per render engines based on the Renderman standard. The Renderman standard allow to use dozen of options and so the coder Brian Perry added a simple list/table UI for seldom needed features. At this simple tables/lists the user could add options like needed - first column option name and second column value. I see now that you implement something like for the shortcut keys.
Why not add a button somewhere at the general options that open a window with a table that show the moi.ini? So, the user don't need to search it at the hard disk, get quick&easy access and you don't need to work on the UI for every little new options. The MoI interface is so nice sophisticated - this little addition could make it perfect for the advanced users too. For me it sounds like a must. ;) The UI wouldn't be complicated, only a little button needs be added. At the general options you could add a line "MoI ini file" with an "Edit" button. An advantage would be, that if the user has more than one ini file at his system (by an user fault), that the UI would only open the ini file that is known and used by MoI.

If you would add the table, than you could make that all options titles like [Mesh Export] could be show bold or with a empty line before.

Hi Micha, re: "Advanced options editor" - yes Firefox has a kind of similar thing, if you type in about:config in the address bar.

It would certainly be useful!

The main problem would be that I would need to divert time to work on it and I would need to cancel other features in order to make that one.


> The UI wouldn't be complicated, only a little button needs be added.

Yeah adding the little button itself would be easy.

Unfortunately making the whole table part which actually would function dynamically is a lot more work than that.

Beyond just making the table UI itself, it would also require an integration layer to make the table hooked up to each of those settings in the actual MoI code.

It's easy in the sense that it is not "rocket science", but it is not unusual for things that are not necessarily difficult to still take a lot of time to implement.

I can understand from your perspective it seems very simple, "Just add a button and a table, how long could that take?" .... If only things really worked that way I would be happy!

It's unfortunately pretty common for many kinds of things to take a lot more development time than you might initially imagine.

This would just be too time consuming of a thing to develop right now.


> At the general options you could add a line "MoI ini file"
> with an "Edit" button. An advantage would be, that if the user
> has more than one ini file at his system (by an user fault), that
> the UI would only open the ini file that is known and used by MoI.

Yes, this one is a lot more feasible, and I've thought about having a button to launch the current moi.ini file in a text editor.

There is a complication with this too though, because MoI writes settings to the moi.ini file when it shuts down. So it is not so good to have the moi.ini file opened in a text editor while MoI is still actively running since if you edit the text and then save it while MoI is still running, your changes will then get overwritten when MoI shuts down and also writes to the file.

So such an "edit moi.ini button" would need to shut down MoI and wait until all settings have been written and only launch moi.ini in the text editor after that.

That's slightly unusual to have a button in options which will shut down the program like that, which is why I haven't done it yet. I guess I could put up a warning dialog first like "To edit moi.ini, MoI will now shut down. Do you want to proceed?" or something like that, that may work.

EDIT: I think I misunderstood your last part here - you were talking about using that button to show that special "Table UI". The thing I'm talking about here would be to have a button that would launch moi.ini in a text editor like notepad.

- Michael