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

Hi Michael,

I tested in with R5 64 here and it's like you wrote, the layer names are splitted. I will ask the Rhino team for a way to keep the names.

Thanks,
Micha

Hi Martin, hmmm maybe it's called something different on the Mac version - on the regular Windows Rhino version "Import" means the same thing as it does in MoI, meaning to bring in the contents of the file you pick and add them into the current model without removing any of the current stuff and not starting a new workspace.

Surely there must be some way to do that with the Mac Rhino version, is it possible that it's called "Merge" or "Combine" or something slightly different?

- Michael

Hi Micha,

> I tested in with R5 64 here and it's like you wrote, the layer names are splitted. I
> will ask the Rhino team for a way to keep the names.

So other than this "names with spaces" issue, does it look like that will do what you need?

Someone on the Rhino newsgroup could probably write a little script that would convert layer names to switch spaces in them to underscores.

- Michael

Nahhh, no merge or combine, there is an insert but that wants to work with blocks. If it is of any consolation the very buggy R5 WIP also opens a new workspace on "importing" another 3DM file, it's probably an issue with permissions, but it was installed with their own installer but that don't mean much with nix based systems, I will download the latest build later and see if it's fixed in that, if not i will run the fix permissions tool and see if R5 plays any better there-after.

Martin Spencer-Ford

** Updated **

Ok just installed the latest build of R5 WIP, no difference, did repair some permissions but nothing directly to do with the software just installed, and still no difference, even from the initial starting workspace, select open, and you get a new instance of R5 ... Ah well, never mind, still got my MoI!!

"So other than this "names with spaces" issue, does it look like that will do what you need?

Someone on the Rhino newsgroup could probably write a little script that would convert layer names to switch spaces in them to underscores."

Yes, this could be a solution. Is there a chance to get the "use style names" option for v2 too?

Hi Micha, ok I've added that in for the next v3 beta.

It will be a new setting in moi.ini under [OBJ Import], called:

[OBJ Export]
WriteStylesAsGroups=n

You will be able to change this to say WriteStylesAsGroups=y and then you will be able to output the kind of files that I posted earlier.

By default spaces in the style name will get converted to underscores. There is another setting you can change to enable writing spaces AllowSpacesInObjectNames=y but you will need support for that on the Rhino side before that will work properly. Until then you would probably want to have some script in Rhino that will replace all spaces in layer names with underscores so that does not cause a problem with the names changing.


> Is there a chance to get the "use style names" option for v2 too?

Sorry no, v2 is not really under active development now, v3 is where I'm adding new things so that's where this new feature will be in.

- Michael