[bjorn.syse]

Hi

I have a few thoughts about material assignment when it comes to Rhino BLOCKS. I know it has been discussed before, but I just wanted to raise the thing again, and I'm not sure what's the most current information.

Am I right in the notion that rhino blocks cannot be assigned a maxwell material, but instead need to have their contained objects to be assigned instead?

If so, the way I see my options now are:

1. I use SuperExplodeBlock to explode all the nested blocks into their respective polysurfaces and such, and then assign materials to those. I can do this either on the top block assembly which will put everything in a big chunk of a group, or I can do a manual explode to drill down a couple of levels first, to give me at least a couple of groups to work with.

2. I manually use BlockEdit to go "inside" the block live, and add my material in there. However, I don't think I can do this recursively, am I right? That means that method won't work so well for me, since these assemblies imported from STEP-files always contain several nested levels of blocks.

Option one is the one I'm using mostly, and it works OK. However, I see that by doing like this - exploding all blocks - I'm missing out of all the advantages of using blocks. In many cases, I might have tank track-like structure with many exact copies of a given geometry, and with blocks;

a. The file size in Rhino stays the same, am I not right?
b. The same goes for rendering with maxwell right? If I could retain the blocks they could translate to maxwell instances and save me some memory and/or rendering time, no?

My wish here, is a command that on a given selected block instance, drills down it's hierchary assigning a specific material to the surface and polysurfaces contained in the bottom of the nested block. Doing all this while retaining the block structure.

How could such a command/script/macro be made? I know some RhinoScript, but perhaps there is an even easier way of doing it?

Please input and correct me if I'm wrong in my notions about how this work.

Best regards

- Björn

[JDHill]

Am I right in the notion that rhino blocks cannot be assigned a maxwell material, but instead need to have their contained objects to be assigned instead?

Individual block instances most definitely can be assigned unique maxwell materials; the objects contained in them will only use those materials, though, if they are set to by-parent assignment. So, (1) make a cube, (2) block it, and (3) put a material A on the instance is a no-go, but (1) make a cube, (2) set it to by-parent assignment, (3) block it, and (4) put material A on it -- the cube will use the material A. It is the same for any material, not just Maxwell ones.

That is the source of your problem -- whatever you are using to get the STEP data into 3DM (i assume that's just Rhino's STEP importer) is not setting sources to by-parent before blocking them.

a. The file size in Rhino stays the same, am I not right?
b. The same goes for rendering with maxwell right? If I could retain the blocks they could translate to maxwell instances and save me some memory and/or rendering time, no?

I think the answer to these questions may also answer the preceding ones:

1. I would assume (but cannot guarantee) the 3DM size would be smaller using blocks. However, if there is only one instance of each block, then it surelywould not.
2. Same thing: if you make a thousand cubes, and block each one individually, then there will be a thousand cubes in your MXS. But if you block one cube and array the block a thousand times, you have one cube and 999 instances.

I'll also note that testing BlockEdit in V5 a couple of days ago, it looked to me to be bugged. The block I edited permanently disappeared from the viewport. Checking again, (1) make three cubes, (2) block them, (3) make two copies of the block, (4) select one and run BlockEdit, (5) hit OK to exit BlockEdit, (6) the edited block disappears.

My wish here, is a command that on a given selected block instance, drills down it's hierchary assigning a specific material to the surface and polysurfaces contained in the bottom of the nested block. Doing all this while retaining the block structure.

How could such a command/script/macro be made? I know some RhinoScript, but perhaps there is an even easier way of doing it?

Try putting this in a toolbar button:

Code: Select all

! -RunScript ( _
Dim definitions, definition, objects
definitions = Rhino.BlockNames(True)
If IsArray(definitions) Then
  For Each definition In definitions
    objects = Rhino.BlockObjects(definition)
      If IsArray(objects) Then				
        Rhino.ObjectMaterialSource objects , 3
      End If
    Next
End If	
)

It should run through all block definitions and set whatever they contain to use by-parent assignment.

[bjorn.syse]

Individual block instances most definitely can be assigned unique maxwell materials; the objects contained in them will only use those materials, though, if they are set to by-parent assignment. So, (1) make a cube, (2) block it, and (3) put a material A on the instance is a no-go, but (1) make a cube, (2) set it to by-parent assignment, (3) block it, and (4) put material A on it -- the cube will use the material A. It is the same for any material, not just Maxwell ones.

That is the source of your problem -- whatever you are using to get the STEP data into 3DM (i assume that's just Rhino's STEP importer) is not setting sources to by-parent before blocking them.

Ah, thanks for clearing that out. I see how it works now,. but you're right - I don't have much control of how the STEP files are interpreted as blocks. I passed this issue on to the Rhino newsgroup though, we'll see if they react.

I'll also note that testing BlockEdit in V5 a couple of days ago, it looked to me to be bugged. The block I edited permanently disappeared from the viewport. Checking again, (1) make three cubes, (2) block them, (3) make two copies of the block, (4) select one and run BlockEdit, (5) hit OK to exit BlockEdit, (6) the edited block disappears.

yep, I've seen this too. Temporary I suppose, it worked right before.

Try putting this in a toolbar button:

Code: Select all

! -RunScript ( _
Dim definitions, definition, objects
definitions = Rhino.BlockNames(True)
If IsArray(definitions) Then
  For Each definition In definitions
    objects = Rhino.BlockObjects(definition)
      If IsArray(objects) Then				
        Rhino.ObjectMaterialSource objects , 3
      End If
    Next
End If	
)

It should run through all block definitions and set whatever they contain to use by-parent assignment.

Thanks mister! on a first test I seems to work very well. I imported a STEP file and ended up with a nested Block tree looking like this:



And if I have a peek at the enclosed polysurfaces at any level in the tree, they are set to "by layer" material assignment. I then close the blockedit without changing anything and explode it so I drill down to the first layer, and I'm left with 14 block instances.

If I try to assign a maxwell material nothing happens, neither in viewport or in Fire window.
I then run your script and try to assign some material to the instances again. This time I don't see any changes in the viewport (rendered display mode), but I do see the change in the Fire window - but only after pressing the "Refresh scene" button. Perhaps this was an issue you're allready aware of though?

However, I save the file, and restart rhino - and this time around every material assignment updates the viewport aswell.

Thanks so much for the script though, I think it's a great leap forward!

Regards

- Björn

[JDHill]

Yes, you'd need to refresh the geometry in Fire after doing this. However, as far as viewport updating goes, I wrote the script using blocks nested five-deep, and it works fine here, both in V4 and V5. What would happen if you used the plugin's restore viewport command, instead of closing/reopening Rhino?

[bjorn.syse]

So the script only drills down 5 levels? I can't see anything about any 5 or figure other than 3 in that script, but I though the 3 had something to do with what material setting to change?

I actually tried the restore viewport command before I did the restart but it didn't do the trick..

- B

[JDHill]

No, I'm not saying that, I only meant that what I tested with was theoretically a more complex case than what you had shown above. Really though, the script isn't concerned with nesting at all -- it alters objects in the block definition table directly. The 3 in the script is simply the symbol used to represent 'by-parent' mode in the Rhino.ObjectMaterialSource method.

[bjorn.syse]

Ah, ok