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

Thanks for the detailed answer - I understand. I'm curious how long you can stay an one-man-company. ;)

Hi Micha, yup this is exactly the kind of thing that would be possible to hand off to other programmers to finish for me if I had some other programmers working for me.

Because I don't have that, I have to be pretty careful about working on things that have a combination of relatively time consuming but not high value general overall return.

There can be some hidden (sometimes very well hidden...) benefits to having limited resources though, since it can force greater precision and help to avoid feature bloat.

- Michael

Hello guys,

I'm trying to convert all igs files in a folder into fbx format...

So i've downloaded the last pack i've found, from Michael...

I've changed the BatchConvert.js to start ConvertFolder( 'c:\\test', 'igs' );
and i've changed 'obj' to 'fbx' into Convert.js...

When i start the cmd, i get a script error :
ReferenceError : Can't find variable : Enumerator... line 46...


here are my scripts :

---------------------
BatchConvert.js :
// This is the script file that you would generate, put one line in
// for each file you want to convert.

#include "Convert.js"

//Convert( 'v:\\Oskab\\convert\\Angle haut 700 x 600.igs' );
//Convert( 'v:\\Oskab\\convert\\Angle haut 924 x 600.igs' );
//Convert( 'v:\\Oskab\\convert\\AR9 P Arr 696 x 376 x 3.igs' );

ConvertFolder( 'v:\\Oskab\\convert', 'igs' );

moi.exit( true ); // Pass true to suppress save changes prompt.


---------------------
Convert.js :

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 'fbx'.
var FBXFileName = FileName.substr( 0, FileName.lastIndexOf('.') + 1 ) + 'fbx';

// 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:
// (note: | denotes mutually exclusive options, for example for Output choose one
// of the given options, like Output=quads)
//
// NoUI=true
// Angle=12.0
// Output=ngons | quads | triangles
// MaxLength=0.0
// MaxLengthApplyTo=curved | planes | all
// MinLength=0.0
// AspectRatio=0.0
// Weld=true
// Display=shadedwithedges | shadednoedges | wireframe
// ExpandedDialog=false

gd.saveAs( FBXFileName, 'NoUI=true' );

// Let's clear out and suppress any save changes prompt again.
gd.fileNew( true );
}

function ConvertFolder( FolderName, FileExtensionToLoad )
{
// Convert all files within a given folder, that have the given file extension.
// For example, convert all .3dm files inside of the folder c:\test :
// ConvertFolder( 'c:\\test', '3dm' );

// Create the FileSystemObject to get access to files and folders.
var FSO = new ActiveXObject( 'Scripting.FileSystemObject' );
var Files = FSO.GetFolder( FolderName ).Files;

// Go through every file in the folder.
for ( var FilesEnum = new Enumerator(Files); !FilesEnum.atEnd(); FilesEnum.moveNext() )
{
var File = FilesEnum.item();
var FileName = File.Path;
var FileExtension = FSO.GetExtensionName( FileName );

// If the extension matches the kind we are converting, call Convert() on it.
if ( FileExtensionToLoad.toLowerCase() == FileExtension.toLowerCase() )
Convert( FileName )
}
}
---------------------

Michael?... some help ?... thanks in advance...

Hi naxos - it looks like that script is using some stuff specific to the Microsoft Jscript implementation which MoI used to use for scripting in MoI v1 and v2.

V3 has switched to use a different script engine and so that one particular area of the script will need to be altered. I'll take a look at that.

But also if you just use MoI v2 instead that same script should work now I think, so that's another solution.

- Michael

Hi naxos, this will require an update to MoI in order to get this script to work in MoI v3 - the script happened to be using a Microsoft-scripting specific mechanism for going through the files within a directory. I'll need to make a built-in method in MoI to handle that part (and the script will need modification to use the new method) since the new script engine in v3 is not able to interface directly with that previous library that the script was trying to use.

So for the next v3 beta there will be a solution for v3 but for the moment to get this script to work you will need to use MoI v2 instead.

- Michael

Hi naxos, I've added a new script method for the next v3 beta so that this will be able to work in v3.
With the next beta you'll be able to use this for the ConvertFolder() function inside the Convert.js file:

    function ConvertFolder( FolderName, FileExtensionToLoad )
    {
        // Convert all files within a given folder, that have the given file extension.
        // For example, convert all .3dm files inside of the folder c:\test :
        // ConvertFolder( 'c:\\test', '3dm' );
    
        var Files = moi.filesystem.getFiles( FolderName, '*.' + FileExtensionToLoad );
   
        for ( var i = 0; i < Files.length; ++i )
            Convert( Files.item(i) );
    }

But until the next v3 beta is out you'll need to use that version you've already got but with MoI version 2 instead of MoI version 3.

Thanks for reporting the problem so I could get v3 tuned up.

- Michael