[dsr]

The following pertains to two new issues we discovered this afternoon when trying to use a new Maxwell material with our updated Rhino/Maxwell plugin:

1. We downloaded MXM material from the Maxwell render web site.
2. We processed the material:
• Placed the MXM in our Maxwell material library
• Named the MXM and the textures with a unique name (to avoid duplications)
• Opened the MXM in the Materials Editor
• Reattached the newly named textures to the material
3. We brought the MXM to the rhino model by assigning it to an object.
4. The MXM did not display as it was supposed to (FIG 1):

http://farm9.staticflickr.com/8120/8661 ... 9a66_b.jpg

5. The Rhino/Maxwell plugin is not finding the right textures (the ones we had just assigned to the material). The textures which are being used have a similar name as the original downloaded MXM and are in different folders than where our processed MXM was (recently just) saved.

6. Another (potentially bigger) problem. In the Rhino/Maxwell plugin, we linked the MXM textures to the correct ones (to work around the above problems).
We modified the UV mapping of the material to suit our model scale.
When we rendered, the mapping did show the UV mapping size that been set (and seen in the render display in Rhino). Indeed, the material was changed to something about 100 times the scale!
We tried rendering in a new file, but we still had the same problem.
Then, we rendered the file in a computer in which the latest Rhino/Maxwell plugin is not installed it and everything rendered fine…This appears to be a bug? (FIG 2):

http://farm9.staticflickr.com/8123/8661 ... 8f95_b.jpg

Thanks for you help.

Regards,
dsr

[JDHill]

Regarding the image in point #1, I did not understand what is supposed to be wrong with how it is being displayed. It looks like the Bump texture in the third BSDF is active, and that is what I seem to see in the viewport. On point #5, I will take a look and try to reproduce that. And regarding point #6, it's not possible for me to diagnose without seeing the model, but don't worry about trying to send it, I mean to upload another build this afternoon, with some changes made in the general UV-handling, which should roll behavior back to something more similar to the 2.7.22 plugin.

[dsr]

Thanks. We will see how the update affects the problems.
As for that first image, it is finding a bump map from a different material that has the same name.
The strangest part of that is that the bump map it finds is higher up in the directory structure? And completely from an unrelated material?

Regards,
dsr

[JDHill]

Thanks for the clarification. There seems to be an ambiguity, though, between these two statements:

Named the MXM and the textures with a unique name (to avoid duplications)

As for that first image, it is finding a bump map from a different material that has the same name.

Here is why I need to bring that up: given MXM files A and B, where A references folder-1/image.png, and B references folder-2/image.png, if either of these texture paths is not valid, as actually given in the MXM files, the plugin will perform a search using the name image.png, and will use the first actually-valid image.png file it can find.

So while it is a bit difficult to read in the screenshot, my conclusion is that there are actually two bump maps involved, both with the name B.jpg (or maybe 8.jpg), where at least one of them is not able to be found at the path indicated in the MXM file. Does this seem to be a correct diagnosis?

[dsr]

We will try to reproduce the same results tomorrow (we are open here on Sunday) and send you more information.

When do you expect to release the update?

Thanks,
dsr

[JDHill]

Basically, as soon as possible. I'm still in the process of seeing what can be done regarding the discussion on the other thread.