Hi Michael,

I'm using MoI most for getting clean and lightweight meshes for rendering per Rhino+Vray. I ask me, are there advantages of v3 for me except bug fixes?

Since a long time I miss a way to keep the layer structure during meshing objects. Will it be possible? Can I write meshes to 3dm files? Could be great to see it at v3, also if it would be a hidden feature enabled per ini file only. It's a dream for my workflow to open a 3dm NURBS file at MoI and finally to get all objects meshed at the right layers at Rhino.

Will be there some new meshing options like a refinement per "max error"? Often I run in the problem, that large light bend objects need a to fine "angle" or "divide larger than" to get a mesh without visible mesh angle jumps. For example a scene with a train and a light rail curve. The rail need a low angle, but it cause to much polygons for the train details. For example a simple "max error" of 1 scene unit (cm) would do it.

Will be there a 64bit version for handling complex files?

If none is implemented yet, could it be added please?

Best-
Micha

One note: keeping the layer structure could be easy possible per FBX. I tested it per Rhino - FBX support layers. Now I'm curious. ;)

Hi Micha, right now I don't think there are any major new feature areas in v3 as compared to v2 only specifically in the area of meshing.


> Will it be possible? Can I write meshes to 3dm files?

Right now I do not have any specific plans for this - as we've discussed several times before it could be pretty confusing to try and save a type of 3DM file that MoI could not then read back in. Right now I do not really have any good idea for where I could put such a feature without having that potential catastrophic side effect of someone actually losing their primary data.


> Will be there some new meshing options like a refinement per "max error"?

This one has been on my list to add for quite some time, it just hasn't made it up to the top of the list yet.


> Will be there a 64bit version for handling complex files?

No, unfortunately there will be a really substantial amount of work involved in producing a 64-bit version, it will involve changing compilers and updates to all the various libraries that MoI uses. It would basically be a major porting effort and I've only recently completed another big porting effort with producing the Mac version and so that's not the kind of project that I'm really up for digging into right away again, with huge effort involved for just one sort of new feature.

Right now I'm currently much more focused on new modeling tools.

- Michael

Hi Micha,

> One note: keeping the layer structure could be easy possible per FBX. I tested it
> per Rhino - FBX support layers. Now I'm curious. ;)

At some point I would like to make a pass through several of the file export options to add more features to them.

Since the focus for most export is for going into a rendering system, it would really be more focused on setting up material definitions, but I guess a "layer" in FBX is just a channel of some particular information that polygons can index into, like for example UV coordinates go on a particular type of layer. I don't know how Rhino's FBX importer works exactly, whether it gets its layers from one particular kind of FBX layer, there are a bunch of different layer categories, like "Material", "Vertex Color", "Visibility", "Polygon Group", "UV", etc... Do you know which particular kind of FBX layer it uses to build the Rhino layer table from?

- Michael

I export some mesh objects from Rhino as FBX and reimport it. The objects are on the original layers. Also last I got a FBX model from a client, there was a layer structure implement - very useful.

Layer are quite important for rendering - my clients are using it for sorting materials but also for easy allow to switch between design versions, for example an airplane seat with table in and out.

Attached a FBX in ASCII format there you can see the used layer properties. Only the layer colors are not set yet.

I hope it can be implement. Funny, this way was open since years, but I ask you for OBJ/3dm and layer only always. I didn't know that FBX is so powerful. It seems to be that it can save NURBS too, Rhino ask for it during export.

Hi Michael,
I think it will be a good feature to add vertex and polygon count in meshing option dialog box. For exmple changing angle we will see how many polygons we get.

Hi mir4ea,

> I think it will be a good feature to add vertex and polygon count in meshing
> option dialog box. For exmple changing angle we will see how many polygons we get.

Those are displayed in the command options area in the upper right corner of the main window:



- Michael

oh thanx) never saw it))

Michael, did you have seen my last post with the FBX example? What do you think, could you implement the layer support please? From my users view it should be there, since MoI supports layers, it's overseen. ;)

Hi Micha, I just now took a look at your FBX example, and from what I can see the "layers" in there are not implemented by any of those FBX layer methods that I mentioned before (with the things that FBX format itself calls "layers" which are like channels for Normals, Materials, or UV data), but rather by an object hierarchy with Null objects being used as a parent object that has that layer name.

That's probably not going to be a good match for what MoI calls "styles", which would more naturally map to materials rather than an parent/child object hierarchy.

Also from what I can see I'm not sure that Null objects in FBX have any way to have colors assigned to them - that's probably why color information is lost when Rhino converts this kind of hierarchy into its layers. So again that's probably not really a good way to do it, it's not a good mechanism to use for it if it can't convey color properties.

Is that correct that you lose all layer colors when importing your FBX example file into Rhino ?

So from what I can see right now I can't really see implementing this kind of Null parent object method for exporting layer data out from MoI - the primary focus for most mesh export from MoI is for use in rendering and that would be a pretty weird way to do it (with no colors coming through) rather than using material assignments.


.... Or maybe it is possible that a KFbxNull can have a color property assigned to it, I'm not entirely sure about that. But even if that's possible it would probably be pretty unlikely that rendering programs would actually look at that rather than at the material assignment.

- Michael

Right, the layer colors are not imported.

So there is no standard way to implement a layer structure to FBX?

But since nobody asked you for "That's probably not going to be a good match for what MoI calls "styles", which would more naturally map to materials" it seems to be not so missed. But if a parent/child object hierarchy is the way to Rhino, than why no use it? ;)

I think, if you could implement a way to get layer transported to Rhino, than you and the user can profit only. Meshing user will be happy, you will have some "meshing only user". MoI layer color are quite limited to use for rendering materials, new materials are need to be setup at the final render package most. From my experience my clients are using layer names for transport material informations like "shiny white plastic", "soft white plastic" and "white rubber" - how will this colors be setup to the MoI layer colors. Layer colors wouldn't be helped to organize materials. If not material names are transported, than my clients organize objects, for example "walls, interior version 1, interior v2, plants, trees, ...". During rendering I turn on/off the layer for rendering different version of a scene. The layer color helps to see, which design version is turned on, but it's not so important.

If you would find a new way to get the layer structure to FBX that doesn't work for Rhino, than it is not useful. Please try to find a bridge to Rhino, if you like your Rhino user and want to help them.

Hi Micha,

> So there is no standard way to implement a layer structure to FBX?

Yes as far as I can tell there is no AutoCAD style layer mechanism for FBX format.


> But since nobody asked you for "That's probably not going to be a good match for
> what MoI calls "styles", which would more naturally map to materials" it seems to
> be not so missed.

Other people have asked before for materials to come through in FBX format.


> But if a parent/child object hierarchy is the way to Rhino, than why no use it? ;)

Because it would not work for transferring materials, and setting up materials is the main goal for most of MoI's exports to rendering oriented formats.


> MoI layer color are quite limited to use for rendering materials, new materials
> are need to be setup at the final render package most.

Yes, the main thing that helps is having the materials list and assignments come through.

Rhino's layer mechanism is not able to handle material assignments very well since each object can only be on one single layer, you can't for example have a box in Rhino that is one single joined object but have some different faces of the box on different layers.

Just in general the mesh handling in Rhino is poor, there are many limitations like no per-face vertex normals, no n-gons, etc... - usually to get the best mesh handling you would want to export your mesh data into a more rendering specific program like Cinema4D, Modo, Maya, etc... - Rhino users who do this are already well supported by MoI, I'm not sure why you keep insisting on using Rhino for doing mesh _imports_ when it's not very well suited for that. If you want to use MoI for better mesh exports, then go from Rhino into MoI and then into your rendering program rather than trying to go back into Rhino with the mesh data.

- Michael

When you export from MoI into OBJ format, the styles become material definitions and material assignments in the OBJ file. So if the Rhino OBJ reader would translate those into layers that would probably do what you want.

How does the Rhino OBJ importer currently decide to assign layers to imported OBJ data?

- Michael

Hi Michael,

there a some options for the OBJ export/import at R5 now - attached two screenshots. But reimported layer names are changed from "Layer 01" to "Layer_01". So far I remember me right, OBJ doesn't support spaces in names, right?

I wished I could direct and easy convert a NURBS model with layers to a mesh model with layers per MoI meshing. I hoped FBX could be the way.

Hi Micha,

> there a some options for the OBJ export/import at R5 now - attached two screenshots.

It looks like for import the only thing involving layers is to map group names to layers - I think what you would want instead for MoI's OBJ output would be to map material names to layers instead of that.


> So far I remember me right, OBJ doesn't support spaces in names, right?

Generally spaces are problematic since according to the OBJ spec some things use spaces to separate multiple names. So something that stuck to the spec exactly would see a group name with a space as 2 different groups being declared as active, something like that anyway.

You can control whether MoI allows spaces or not for different OBJ things by settings in the moi.ini file:

[OBJ Export]
AllowSpacesInMTLFileNames=n
AllowSpacesInMaterialNames=n
AllowSpacesInObjectNames=n


Maybe though the easiest thing I could do would be a setting in moi.ini for OBJ export to write the style name in MoI out as a group name rather than as a material, then possibly that option in Rhino's importer for using group names as layers would do what you need.


- Michael

Sounds good, we could try it. :)

Hi Micha, I've attached here a test for you to try to see if a setting for OBJ export for "Write styles as groups" will help.

For this test, in Rhino set the mode for "Import OBJ groups as: Layers" and also set "Map OBJ Y to Rhino Z". Hopefully that should then bring in the mesh onto the original object layers as you want. You should be able to open the original 3DM file, and then do an Import of the OBJ file with those settings and then the import should bring the meshes into the original layers.

The first one is a simple test, the second one obj_test2 tests using spaces in the group names, but as discussed earlier by the actual OBJ file specification any spaces in the group name is supposed to be mean that multiple separate groups are active (spaces are meant to separate multiple names) rather than it being one single group name so that may not work. If that does not work you would need to either ask McNeel to have an additional option to control that group name reading behavior, or have a Rhino script replace all spaces in layer names with some other character like an underscore before doing any of this processing.

- Michael

I had to test those with R5 WIP on the OSX platform ...

Test1: I get Blue red green layer names with black shapes (cuboids) .... Is that how it should be. The 3DM has the colours to suite the names
Test2: I get "layer", "with", "Spaces" along with default and 2,3,1,4 all on their own layers with no colour assignment

Hope it helps

Martin Spencer-Ford

Hi Martin, thanks for testing it!

> Test1: I get Blue red green layer names with black shapes (cuboids) .... Is that how it should be.
> The 3DM has the colours to suite the names

If you use the "Open" command directly on the OBJ file then yup that's what you are supposed to get. In order to maintain the layer colors you would want to do things slightly differently - use "Open" on the 3DM file, this will read the original layers in including their colors, and then use "Import" instead of "Open" to bring in the OBJ file, that should then bring in the meshes and map them to the original layers.


> Test2: I get "layer", "with", "Spaces" along with default and 2,3,1,4 all on
> their own layers with no colour assignment

That means that spaces won't work, which is not really unexpected as discussed above.

- Michael

Hi Michael, the reason R5 on OSX won't import properly ... or i think it's the reason why, is when I import it opens a new session, so using your steps above is futile here;

Just to make sure i am not totally dumb, here's what I did

step1 ... Open the 3dm with R5
step2 ... Attempt to import OBJ file (R5 says sure, i will import that but here have a new workspace to play with)

However just for argument sake ...

step3 ... Select all cubes that are coloured black in new workspace created by the imported OBJ contents, select copy, and then paste those cuboids into the original session and the cuboids come in with their colours assigned correctly and are approx. 20% the size of the original cuboids in the 3DM file

Martin Spencer-Ford