If you would add ini options for displaymesh-to-3dm save, than no user who don't need it would get a large file. The problem is, that it isn't need allways. So, if I could enabled per shortcut than it could be better.

If the display mesh is saved to the 3dm, than it can be extracted at Rhino ... ;)

> Isn't that a different thing than whether to store render/display meshes on NURBS objects in the 3DM file or not?

Yes, I hoped, if you can save display meshes to the 3dm file per special option, than you could allow a mesh export too. It would help so a lot. I could mesh complete scenes within one pass. OK, you havn't the 3dm file format available at the export format list, but couldn't you not allow it to enable this output for advanced users per ini option. So, user who enable it, know that this 3dm meshes can't be reimported. Please try to add this feature, it could save a lot of work.

Michael,

> If MoI generated 3DM files that had render meshes in them and just ignored them on load,
it would cause a large increase in file size without any benefit for regular MoI users since that data would just be ignored.

I don't think that is such a big concern these days, hard drives can store massive amounts of data.

Hi Kevin,

> I don't think that is such a big concern these days, hard
> drives can store massive amounts of data.

It tends to get awkward when the model files are something like 10 times greater in size for things like e-mailing your model files or posting them here on the newsgroup for people to download.

Transmitting model files like that is something that happens pretty frequently...

Rhino has to have a special extra "Save small" command separate from the regular Save command in order to solve this problem. That's a good example of the kind of thing that causes a sort of "bloat" or clutter to the UI which I've tried to avoid with MoI.

- Michael

Hi Micha,

> If you would add ini options for displaymesh-to-3dm save,
> than no user who don't need it would get a large file.

Yes, that's true! But it's not simply a matter of making an .ini file flag, features like putting the display mesh into the 3DM file require me to code them, I don't just set a flag and the feature pops up in MoI automatically... :)

It can be hard to justify spending time on a particular feature that is totally hidden from regular use by only being accessed by an .ini option.

.ini options are normally better used for things that are a modification in behavior of existing features.


I do have exporting a 3DM mesh file on my list of things to look at in the future, but it's unfortunately an awkward thing to integrate into the regular UI. Having 2 different kinds of 3DM files listed in the regular file types dropdown could easily lead to confusion, with one 3DM variation being MoI's main save type, and the other mesh variation being a completely different type of data that could actually not even be read back into MoI. There is potential there for someone to actually lose their data by mistakenly saving to the wrong 3DM variation.

So probably at some point it will be something that could be accessed by script, and if I had a script library UI that people browse though scripts more easily that would then make it a more accessible thing than only enabled by the .ini file.


I'm not sure when I will be able to work on these various pieces that would go into that though.

- Michael

Wow! I had a moi file lying around that I had previously saved as .Iges, then imported to rhino, saved and now I can see it on my iPad! My clients are going to be shocked!

I really don't understand the obsession with saving meshes in the 3dm file. Whats wrong with using one of the various export options MOI provides. Don't tell me that it's because the iPhone or the iPad can't read them. That's Apple's problem, not Michael's. The mesh data that Rhino saves is not meant to be extracted anyway. It is internal for Rhino's screen renderer and is not very good (no n-gons, no point welding, etc) for use in anything else.

Has anyone else tried the stereo feature?