[Josephus Holt]

this is not a "biggie" but seems a bit "buggie" to me...not sure if we've already covered this, but back to the brick window sills. So I made several to use as blocks/instances in my model (using RS and following explicitly the order you wrote), and this morning when I went to re-open the block reference files I'm found that although the 90 degree z rotation shows correctly in the Maxwell Object Properties properly, that I did not see that mapping on the screen, it's showing z rotation =0 (I tried refreshing the viewport as well as clearing the maxwell cached data with no change). This will render out incorrectly, it will render as shown on the screen, and so far the only way I've found to quickly reset this is to go into the material editor of EVERY material ( ) and just tweak any of the xy tiling or offset values (and then reset to original value).

The odd thing is that I can not now reproduce that behavior, so will keep an eye out for it and post more if it happens again.

[JDHill]

It sounds to me like there are other texture mappings associated with the objects. If you have a small file you could zip and send me (.3dm) it might help.

[Josephus Holt]

It sounds to me like there are other texture mappings associated with the objects. If you have a small file you could zip and send me (.3dm) it might help.

done

[JDHill]

Okay, I think I may have it - I am guessing both of these files were created from another common file.

The material contained in each definition (i.e. file that will be inserted as a block) is the 'same' material (it has the same internal ID), and when the two definitions are inserted as blocks, one or the other version of this material is being imported - if you look, there will only be one shown in the material list in the referencing model. So, that means that one of the blocks is going to render differently than it does in its source document, because the texture parameters vary between the two materials. The solution is to open either one of the definitions, clone the material inside it, delete the material that was just cloned, and assign the newly-cloned material to the geometry. Next time you open up the model that uses these definitions, you should see that you now have two materials, and the two objects should render correctly.

I will have to tune this up so that the plugin automatically does this cloning when you reference another file (I thought I was doing that already, but apparently not).

[Josephus Holt]

Okay, I think I may have it - I am guessing both of these files were created from another common file.

The material contained in each definition (i.e. file that will be inserted as a block) is the 'same' material (it has the same internal ID), and when the two definitions are inserted as blocks, one or the other version of this material is being imported - if you look, there will only be one shown in the material list in the referencing model. So, that means that one of the blocks is going to render differently than it does in its source document, because the texture parameters vary between the two materials. The solution is to open either one of the definitions, clone the material inside it, delete the material that was just cloned, and assign the newly-cloned material to the geometry. Next time you open up the model that uses these definitions, you should see that you now have two materials, and the two objects should render correctly.

I will have to tune this up so that the plugin automatically does this cloning when you reference another file (I thought I was doing that already, but apparently not).

yes, they were created from one common file...glad I sent you two
So I should probably keep a unique name for each like material, material (2), material (3)....?

[JDHill]

The name doesn't matter, the material itself will need to be unique, meaning, created by cloning, New Material, or by MXM import.