(I copied Michaels text from the v2 beta release thread to this thread to start an own thread.)

Michael, I tried it, but it dosn't work here.

Rhino layers - Default, Layer 01, Layer 03, Layer 04

OBJ names - Default_3 and three objects joined at layer Default

Attached my Rhino test scene and the convert cmd/js. Do you have an idea?

Thank you very much for all your effort.
Micha



Michael wrote:
>>>>>>>>>>>>>>>
Hi Micha, re: mesh Rhino NURBS and bring back into Rhino with the same layers.

> Maybe an option could be implemented that allow to
> save styles as mesh names (without joining meshes
> with the same name) and at Rhino a script move the
> meshes back to the original layers?

I think it should be possible to handle this part by a script right now in MoI.

For example, if you set up the following script on a keyboard shortcut:

script: /* Set object name as style name + num */ var objs = moi.geometryDatabase.getObjects(); var styles = moi.geometryDatabase.getObjectStyles(); for ( var i = 0; i < objs.length; ++i ) { var obj = objs.item(i); obj.name = styles.item(obj.styleIndex).name + '_' + i; }

Then when you hit that shortcut key each object will get assigned a name of its associated style name, plus a unique increasing number, like BlueLayer_2, BlueLayer_3, etc...

The number is appended to make the names unique to avoid combination of mesh objects with identical names.

After you have run that script, then when you export to OBJ and read into Rhino, that information of what layer the mesh was originally on will stored in the object name, and some Rhino script code should probably be able to go through the meshes, strip off the ending _xxx which will then give it the layer name to place that object on.

Probably if you can clearly state the problem in the Rhino newsgroup someone will be able to help you with that part. Something like: "I have a bunch of mesh objects with layers stored in their names, like BlueLayer_1, BlueLayer_2, OrangeLayer_5, etc... and I want to edit these objects to place them on the layer that is named in the object name, like assign BlueLayer_1 to the layer named "BlueLayer", etc...


You can incorporate that same MoI script above to be a built in part of your batch conversion script if you want, just after the opening of the model file. Here is more readable version of it for putting in a text file rather than in a single-line keyboard shortcut:

code:
// Set object names to be their Style name + unique number.
var objs = moi.geometryDatabase.getObjects();
var styles = moi.geometryDatabase.getObjectStyles();
for ( var i = 0; i < objs.length; ++i )
{
var obj = objs.item(i);
obj.name = styles.item(obj.styleIndex).name + '_' + i;
}




- Michael

And one more question - the new beta grouped all objects with the same name. Could it be possible to get an option at the Import/Export options for it like "group objects with same name" because it can cause problems?

For example - I get a Rhino file there is an object with a name that is copied several times - for example a bolt with the name "bolt 30x10". After meshing per MoI and import the mesh to Rhino all bolts are joined to one mesh. Now only ungroup and explode helps to get single objects - no, not single object, all mesh faces are splited. So, the new feature can cause a lot trouble.

If you dont like to add an option for keeping separate objects separate, please add an ini file option for disabling it.

And now I have seen that there is an other name problem. If the object name is "A B C", than the OBJ mesh is named "A" only. So, three object with the name "A 1", "A 2" and "A 3" are joined together to one mesh with the name "A".

Hi Micha,

> And now I have seen that there is an other name problem.
> If the object name is "A B C", than the OBJ mesh is named "A"
> only. So, three object with the name "A 1", "A 2" and "A 3" are
> joined together to one mesh with the name "A".

I see - actually what is happening here is that MoI is setting the full object name in the OBJ file, but anything after a space is not being read in by Rhino. That's probably going to be a common problem as "group" identifiers in an OBJ file are not supposed to have spaces in them. I think I should automatically replace spaces in object names with underscore _ characters for OBJ export by default.

It should be possible to modify that script to do that now though, I'll take a look.

Then once it is imported into Rhino the script on the Rhino side will need to take this replacement into account - when it scans through the names of layers to try and find a match it should not compare the object name with the full layer name but rather compare it with the layer name that has been modified to also have spaces replaced with underscores.

- Michael

Michael, couldn't you not allow to write meshes to 3dm files please, please .... . Anything could be so easy, since MoI got "layers". The 3dm format allow to contain meshes and NURBS, it could be a great help. Maybe you can build in a hidden door for that usage, for example that mesh export to 3dm works per script only. Than I could export my geometry from Rhino, open it per script and save it as 3dm. No UI change would be needed. It's some extra work for you, but I suppose so it will cause some extra MoI user too. ;)
Rhino v5 will not have a better mesher and I need Rhino for rendering with Vray. So, MoI is my escape for complex models. An easier workflow would be great for all render users like me.

For now - replacing spaces isn't a good option. The workflow will be more difficult. I wished, the mesh grouping/joining could be avoided. I afraid it cause problems and I never missed this feature.

Hi Micha, I don't think I will be able to do a 3DM mesh export for v2... Maybe in the future. There are just too many other main areas of v2 that need attention first, I just cannot dedicate time to a major new kind of file export right now.


> For now - replacing spaces isn't a good option. The workflow
> will be more difficult.

Why? With the scripts in place on both side it will be the same final result as if there were not spaces replaced. Having spaces replaced is just an "implementation detail" but you would not have them replaced on your result.


> I wished, the mesh grouping/joining could be avoided.
> I afraid it cause problems and I never missed this feature.

Yes, it does make sense to make an option for that.

But this should have no impact on this particular "layer preserving" script mechanism because it sets all the object names during its processing anyway.

- Michael

Hi Micha,

> Rhino v5 will not have a better mesher and I
> need Rhino for rendering with Vray.

Is there possibly a stand-alone version of Vray that might work better for your rendering than a Rhino plug-in one?

Normally a rendering system should now be able to read in MoI's new OBJ export and have materials set up and ready to be rendered.

In other renderers, the Styles become translated as a materials list, which is all prepared to edit any of the materials to adjust the render properties of all the objects that are assigned to that.

I guess your main problem is that Rhino's OBJ import does not really read in material information properly to keep the list of named materials that is stored inside of the OBJ file, is that correct?

If that's the main problem, then that is really a bad function of Rhino's OBJ importer - it should read in materials from the OBJ file as a table of materials that you can edit. If the closest thing to that in Rhino is layers, then it should build layers from OBJ materials.

It seems like much of your problem in this case is that Rhino's OBJ importer just does not seem to function as a regular rendering program's OBJ importer does.

- Michael

Hi Micha, anyway getting back to your convert script problem, please try updating to the attached version.

This version will replace spaces in style names with underscore characters.

If you test it, it should now allow for the data to now be transferred into Rhino with layer names set on each object as a modified object's name.

All the data should now be in place in Rhino to have a script on the Rhino side that will move each object to the proper layer.

The way the Rhino script needs to work is the following:

The script first needs to prepare a translation table between underscore names and a layer. It would do this by populating an associative array by looping through all Rhino layers, take the rhino layer name as a string variable. Replace all spaces in this string with underscores. This string now becomes the key for an associative array entry, and the value for that entry is the layer's index number.

Now that the associative array is constructed, you want to loop through all objects that have been imported (or maybe just all objects in the database is ok), take the object's name and look it up in the associative array. That will produce the layer index, and the object should then be assigned to have that layer index.


It's not really a complex procedure, but I am not familiar enough with the Rhino script API (it was added after I had originally worked on Rhino) to know all the specific syntax for traversing objects and assigning layers, etc... So you'll need to get someone who is familiar with RhinoScript to help to produce the script.


Anyway, with that piece of script processing in place on the Rhino side, it should allow you to have stuff meshed in MoI and then retrieved back into Rhino as you want.

- Michael

Hello Michael,

a vray standalone isn't available. Also I'm not a friend of render studios, because additional work must be done. My clients work with 3dm files, send model changes often, extra informations like layers, layer states and cameras are used. Some times my client like to get the camera is used for creation additional things like AI lines from a view.

I tested your script and so far I see it works without problems. The mesh grouping is avoided. :) Also I have seen that the Rhino Obj mtl import works fine too. I ask me, could it be possible to keep the information of material name and layer name through the conversation process Rhino2MoI2Rhino? I'm not sure MoI can read the material name of Rhino objects. After import the MoI OBJ I have two places where informations are stored - obj material name and object name.

I will try to find somebody how can write a Rhino script. Maybe somebody read the thread here and could do it please. Attached a Rhino file that show objects where the object names needed to be converted to layer names without the additional underscore.
To avooid nameing problems the underscore could be replaced by a seldom used character like "|" or "§". I have the feeling the underscore could be regular used for layer names. But this should be the smallest problem.

I understand that the 3dm mesh export would cause more work. My hope was that v2 could be the "meshing" release among other things. ;)

Cheers,
Micha

Hi Micha,

> I tested your script and so far I see it works without problems.

That's great! So all you need is the script on the Rhino side to be able to get what you need here.


> Also I have seen that the Rhino Obj mtl import works fine too.

Maybe I'm missing something, but it seems to be problematic to me.

For example, if I export an OBJ file with 4 boxes in it, with 2 boxes having Style = Orange, and 2 boxes having style = Red, when I import it into Rhino, where do I go to see the table of all used materials? There should be a list somewhere that shows 2 materials of Orange and Red and would let me edit them to change all objects that have been assigned that material, without needing to do any selection steps before that... Is that something that I missed somewhere?


> I have the feeling the underscore could be
> regular used for layer names.

It's ok if it is used for layer names - the only time it would be a problem would be if you had 2 layers in Rhino with the same name but one using spaces and one using underscores. There would be a collision in that particular case, but it would have to have all the same other characters in it between those 2 names. So it is pretty unlikely.

Just any regular layer name with underscores in it should not be a problem though.

If you'd like to replace the character though, it is easy to do that, just edit the line that says:

obj.name = name.replace( /\s/g, '_' );

and replace that '_' with '^' or whatever character you wish.


> My hope was that v2 could be the "meshing" release
> among other things. ;)

It definitely is a major meshing release already! I've spent about 2 months of full time work only on speed improvements for the mesher for this release. I think that's the most amount of time that I spent on this release for any single feature area.

Just use v1 for a bit and you'll be reminded of this, many features like multi-core enabling, other speed optimizations, and better handling of the UI flow like not freezing during calculations were all things that are new for v2.

I'm actually very surprised that you would not consider that v2 is a major meshing release, I mean there have also been many quality improvements as well, a whole bunch of them in direct response specifically to requests from you! For example refer back to this thread for a bunch of them: http://moi3d.com/forum/index.php?webtag=MOI&msg=2451.1

So I mean come on... How could you not consider it to be a major meshing release after all that?

- Michael

Sorry, I found not the right words. The v2 bring a lot great enhancements for meshing, no question, it helps me to finish projects (plus in high quality). With Rhino only some projects was inpossible or extrem difficult. MoI v2 is great!!!
I thought, it could be nice to get so much meshing features as possible to v2, so that user like I, who use MoI for meshing only, could stick at v2 and v3 would bring improvements on other areas and only little meshing improvements. I thought, it could be nice, if for meshing user like me v3 wouldn't be a must (400$ would be quite a lot of money for meshing only ;) ).
I tried to say, that the meshing situation is quite bad at Rhino and that no change is known for v5. So, MoI is the escape and the connection between both can't be good enough. I know MoI isn't build for Rhino user only, but it could be nice if MoI v2 would perfect match the need of Rhino users too. Perfect would be, if MoI would mesh NURBS objects and after reimport at Rhino all original informations for layer, name, material and mapping could be keeped. I thought per 3dm export layer and material could be keeped without to much programming effort, since 3dm is the basic format of MoI too. But if it is not possible, than the script way is a good method too, a second step is done, the layers could keeped (for me the first step was the script connection between MoI and Rhino).

Rhino and OBJ material import - attached a screenshot that show meshes after import from MoI. The rendered viewport show the right material (style) colors and the object properties show the material (layer) names.

Hi Micha,

Yes unfortunately it is just not possible for me to spend 100% of my time only working on meshing functions alone.

It will just be a very normal process that not every single feature that you need will be built into v2. Some things will happen with future work and not all right this moment.

So you should generally plan in advance that to get new functions and improvements, it would be necessary to update to future versions of the software. That's just a very normal thing, there isn't really any way around that.


> (400$ would be quite a lot of money for meshing only ;) ).

Actually, no not at all if you use it for professional work! You've mentioned that MoI's current meshing has saved you hours and hours on numerous occasions, and even enabled you to finish projects that you would not have otherwise been able to complete properly!!

$400 for making your professional project able to be completed when otherwise you will not be able to finish is a very great bargain by any normal reasonable standard. You are certainly entitled to your own opinion... But I'm sorry I really do not understand it.

If you're not willing to pay for it, then it sounds like improved meshing is just not really that important to you after all...

- Michael

Hi Micha,

> Rhino and OBJ material import - attached a screenshot that
> show meshes after import from MoI. The rendered viewport
> show the right material (style) colors and the object properties
> show the material (layer) names.

Yeah, the basic information seems to come through, but every object seems to have its own local copy of the material and not any unified material table.

Where can you see the list of the materials that are used in the imported objects? Can you only see the materials one at a time when going to the object properties of one object? That is not good.

Also when I change the color of one of those imported object's materials, only that object changes, other objects that had that same material assigned to it in the OBJ file do not seem to change.

That's a lot different than the way a regular rendering program's OBJ importer works - normally materials are not copied to be only belong to an object in a private isolated manner, there is normally a material list where you can see all the materials that are used in one place, and also edit the material in that one place and affect all the objects that are assigned to it by doing that.

As far as I can tell, Rhino's OBJ importer is not really set up in the proper way like this.

- Michael

>Where can you see the list of the materials that are used in the imported objects? Can you only see the materials one at a time when going to the object properties of one object? That is not good.

Yes, there is no material list at Rhino.

> So you should generally plan in advance that to get new functions and improvements, it would be necessary to update to future versions of the software. That's just a very normal thing, there isn't really any way around that.

I understand that. The problem I see is, that the price of MoI grow with every new release and for "only-meshing" the price-performance-relation is the question. At the moment we have:

v1 ... good mesher, better than Rhino, 200$
v2 ... great mesher, multicore support, super fast, script connection to Rhino, 300$
v3 ... ??? 400$

For me it would be ok to pay 100$ more for an v3 upgrade that would bring for example a full integration of the MoI mesher to Rhino. The current mesher works 99% perfect, only little wishes are open. So, my idea was, if the connection to Rhino could be complete (3d support) now, than Rhino user could stick at the MoI mesher for 300$. But it seems to be a bad idea, sorry. Maybe this could be the key feature of v3 for Rhino-meshing-only-user.
I suppose so v3 will bring many new features that are not needed by "meshing-only" user. But maybe you are right and most Rhino user who need better meshes will pay 400$ too.
I know it was not your plan to offer a Rhino mesher and so I don't expect it. It was only an idea, since it seems to be so near and I thought it could be possible now. But if you say, it's a lot of work, than I understand that you can't pack it in v2. I'm sorry that my request caused trouble. Your work is great and I will try to help you with tests and requests that MoI grows.

Hi Micha, thanks - yes I can understand more of where you are coming from now.

And yes, you are correct that v3 will not likely have such a major advancement in meshing as between v1 and v2, that's because pretty much the major things that I wanted to accomplish for meshing are actually now implemented in v2.

Certainly there will be some refinements and maybe some new parameters and stuff like that, but nothing really huge like the 25x speed increase from v1 to v2.


But I think that MoI v2 will actually get what you need done. Your last main request about preserving layers is actually very close to being solved now, the remaining script that is needed on the Rhino side is not really that complicated.


One idea that I have had for MoI versions and pricing is that by the time I get to v4 I'll probably offer the v2 release as a "lite" version which will probably be a good fit for someone like you who only wants to use MoI for one specific purpose. But it will be a while yet before I get to that stage.


But yes, as you've seen the overall focus of my business is not only about making a mesher for Rhino - my main focus is about making a CAD program for artists to use for creating cool designs. Having a great mesher is an important part of that, but it is only one part of my overall project.

- Michael

Hi Micha, the other thing that I should mention is that it is pretty common for people who are using Rhino and MoI together to use MoI for more than just meshing, they use it for drawing things as well.

So it's not exactly the case that functions other than meshing that I work on are just "wasted" for all Rhino users, there are Rhino users who make use of these other functions in MoI as well.

- Michael

Yes, I am a case in point ... I do architectural work as well as landscape architecture. I use Rhino for all my 2d drafting these days. Rhino is a pretty good 3d modeler, too, but I have come to prefer MoI for most modeling as it seems faster and more intuitive for most work. There are a few things it won't do with surfaces that Rhino does well ... so, I shift back and forth between the two as needed. Because of the drafting aspect I do use Rhino more hours of the day most of the time ... modeling (including rendering) takes up to 20% of each project but the other 80% is spent with dimensioned, detailed, drawings and notes ... MoI is not the tool for that.

It would be wonderful if one tool would do it all perfectly ... but one should not try to use a hammer for fine saw cuts.

cheers,
eric

Hi Micha, just a note on object names.

For the next beta I've added an option to control whether to combine meshes for objects of the same name or not, it will be under
Options > Import/Export > Combine same named objects.

However, Rhino's OBJ importer seems to automatically combine objects with the same name even if they are listed as separate objects. Probably you can repeat this in Rhino, do something like make 3 boxes with all the same name, export to OBJ and read it back in again.

So probably you've had this combining behavior for a while without really knowing about it anyway.

But that export batch script will not have this issue since part of that script puts a unique name on every object.

- Michael

Ah, good to know. Thank you for the MoI option.