Maxwell Render | Official public forum

I'm having a weird problem with materials:
Rhino isn't using the Maxwell material I assigned to the layer (in that case a light furniture chrome) but translated it into a blue rhino material and renders it like that.
It was working fine before and now I have to reassign the Maxwell material again to make it work.


Would you have any idea why this is happening? I've seen it happen from time to time but I have no idea when and why.
And I've mostly seen it with this light furniture chrome material. In this case with two files which were fine before and now both have this problem.
But I've also seen it with different materials and materials assigned by object.
If it is assigned by object it usually is sufficient to just tick the checkbox "Plug-In".

Finally!! someone else is seeing this mean bug;

i reported it time ago, but seemed to be the only one affected. And JD could not think of any logical way for this to happen.



there are two problems with materials here:

A: objects loose material assignement.

as you report, the material name is still there but only in the rhino mat-slot and it will contain the last displayed texture, if there was one selected in the rhino mat before "it happened".

for me however just checking "plug in" usually does not do the (whole) job; have you checked the maxwell tab afterwards? does it show any assigned material there, here it does not.

And i also get the problem with importing older blocks that used to work fine; had this just two days ago.
i imported a set of cars(rhino file) and all lost their materials reverting back to rhino ones. I could not restore it.


B: the adjustment sliders of the texture control get reset to the same values.

this bug is even meaner, as this destroys materials.
have you had any materials suddenly looking not the way they should? could be this..



*

now this does not happen very frequently, but it just happened yesterday when i sent the final 5k render to the network in the middle of the night. Things like this leave a bitter aftertaste.. i am somewhat scared to use rhino on tight deadlines right now.

JD, we are certainly ready and willing to help in any way we can to crush these villains, but it is really urgent.

thanks,

Daniel

I did not see this phenomen yet but I have seen cases where Fire rendered a channel map as the actual image. I remember this happening
with the Normal map which clearly wasn't accidently assigned as the diffuse colour. It might be entirely unrelated but it's another case where
the plugin alters the assigned material on its own.

Polyxo wrote: It might be entirely unrelated but it's another case where
the plugin alters the assigned material on its own.

that is exactly what we are talking about.

but i am wondering, when you saw that normal map rendered, it repaired itself or you had to reassign the material?

polynurb wrote: but i am wondering, when you saw that normal map rendered, it repaired itself or you had to reassign the material?

No, it didn't repair itself - I had to re-assign the material. I found a screenshot I made but forgot sending in.

polynurb wrote:Finally!! someone else is seeing this mean bug;

I once had a tree collection with 30 different trees and 4 seasons in one file (120 with 3-4 different materials I have to reassign) where I used to copy out the ones I needed. But somehow the file is not working anymore since some of these trees lost their materials and I can't find a working backup anymore.
Every tree is a block instance. I always thought that might be the reason why this happened as there have been some weird things with earlier rhino5wip's and blocks ...

I cannot remember seeing the second problem you reported. But from time to time it happens to me that I copy some geometry from an older file and it overwrites the adjustment sliders in my new file with the one from my older file. But Jeremy stated this is due to the material having the same internal ID and so the plugin thinks its the same material.

kami wrote:I'm having a weird problem with materials: Rhino isn't using the Maxwell material I assigned to the layer (in that case a light furniture chrome) but translated it into a blue rhino material and renders it like that. It was working fine before and now I have to reassign the Maxwell material again to make it work.

I'll guarantee almost 100% that there is not a bug here -- the material is using complex IOR, and has no texture selected for display in the viewport. The plugin does not know the color of an ior file; I could change it to use something other than blue, but not much else. I chose that (it has been this way for a long time) so that when you are using a complex IOR file, it is clear why it may be rendering as something very different from the viewport.

polynurb wrote:A: objects loose material assignement.
B: the adjustment sliders of the texture control get reset to the same values.

As discussed previously, I have no control over (A), and have found no way yet of reliably reproducing it. With (B), which texture control are you referring to? In Object Properties > Maxwell > Real Scale Texture Control, or the material editor's texture editor window? The difference would be that in the first case, we are missing data from an object, and in the second, from a material. For a material, I'd expect that we either lose the whole thing, or nothing at all, so I guess it must be the first.

Polyxo wrote:I did not see this phenomen yet but I have seen cases where Fire rendered a channel map as the actual image. I remember this happening
with the Normal map which clearly wasn't accidently assigned as the diffuse colour. It might be entirely unrelated but it's another case where
the plugin alters the assigned material on its own.

This sounds like a case where the material has become unassigned. Meaning, you have a material that uses a normal map, you assign it, you select the normal map into the viewport in order to adjust mapping, the material becomes unassigned (by an unknown process, referred to in Daniel's point A), and the plugin consequently generates a material for the object during export, using the normal map as color map, since that is what the object's Rhino material indicates. Does this sound likely to be the sequence involved?

kami wrote:

polynurb wrote: I cannot remember seeing the second problem you reported. But from time to time it happens to me that I copy some geometry from an older file and it overwrites the adjustment sliders in my new file with the one from my older file. But Jeremy stated this is due to the material having the same internal ID and so the plugin thinks its the same material.

i also noted that when you have two scenes (eg versions of a file) containing the same material, and you rename one before copying a certain object from one scene into the other, the new name will not show up in the pasted into scene, but the original material will be over written. seems like the renaming is not immediate in all depth, at least not right after doing so.

I'll guarantee almost 100% that there is not a bug here -- the material is using complex IOR, and has no texture selected for display in the viewport.

not necessarily, blue is what you'd still see after the material assignment broke. i had exactly this happening on a project where i used some cobalt .ior. the rendered viewport was blue like you say but it also rendered that exact blue diffuse in maxwell.

As discussed previously, I have no control over (A), and have found no way yet of reliably reproducing it. With (B), which texture control are you referring to? In Object Properties > Maxwell > Real Scale Texture Control, or the material editor's texture editor window? The difference would be that in the first case, we are missing data from an object, and in the second, from a material. For a material, I'd expect that we either lose the whole thing, or nothing at all, so I guess it must be the first.

it is the S/B/C/min/max sliders. I think it might be limited to happen only to all textures within a layer, as i recently had a material that was broken by this, but still showed two different values in two different layers.

the material becomes unassigned (by an unknown process, referred to in Daniel's point A)

i have one little idea in my head about this: could it in any way be related to using "SetObjectDisplayMode"

i use this a lot to display selected objects in render mode in a shaded or a wirerframe view in order to progress from blank to fully textured.

polynurb wrote:

I'll guarantee almost 100% that there is not a bug here -- the material is using complex IOR, and has no texture selected for display in the viewport.

not necessarily, blue is what you'd still see after the material assignment broke. i had exactly this happening on a project where i used some cobalt .ior. the rendered viewport was blue like you say but it also rendered that exact blue diffuse in maxwell.

Yes, if the material assignment broke, then the plugin would build a material during export using whatever the Rhino material indicates -- which would be blue, if that is what had been generated prior to the assignment being lost. The two things are unrelated, though.

polynurb wrote:

As discussed previously, I have no control over (A), and have found no way yet of reliably reproducing it. With (B), which texture control are you referring to? In Object Properties > Maxwell > Real Scale Texture Control, or the material editor's texture editor window? The difference would be that in the first case, we are missing data from an object, and in the second, from a material. For a material, I'd expect that we either lose the whole thing, or nothing at all, so I guess it must be the first.

it is the S/B/C/min/max sliders. I think it might be limited to happen only to all textures within a layer, as i recently had a material that was broken by this, but still showed two different values in two different layers.

Thanks, as I say, it doesn't make much sense for a material to become only partly broken, but at least this in particular (s/b/c/min/max) is something I've not looked at before, so perhaps there is some undetected problem hiding there.

polynurb wrote:

the material becomes unassigned (by an unknown process, referred to in Daniel's point A)

i have one little idea in my head about this: could it in any way be related to using "SetObjectDisplayMode" i use this a lot to display selected objects in render mode in a shaded or a wirerframe view in order to progress from blank to fully textured.

I cannot say I've used that very much, so I'll check it out.

I'm not using this command at all, so I'm guessing this cannot be the case?
But my suspicion was going in the direction of using blocks (sometimes external blocks too)

It hits me on bare sinlge surfaces too.

Are your blocks using meshes?

Several issues might come together there.
As we figured in another thread there had been odd things going on with meshes and texture coordinates(rhino issue)

In the last case it has been affecting polysurfaces (but it was assignment by layer anyway). In the tree file it is meshes and object assignment.

kami wrote:I'm not using this command at all, so I'm guessing this cannot be the case?
But my suspicion was going in the direction of using blocks (sometimes external blocks too)

Seems it may not be either of those things -- in checking, I am finding some interesting behavior (I am on Version 5 SR5 (5.5.30717.16015, 7/17/2013)) that I don't think I've noticed before. In your original screenshot, we see the Rhino material on the left, in Rhino's Layer Material dialog, and a Maxwell material editor on the right, in the plugin's material editor. The "Plug-in" checkbox at the bottom left of Rhino's editor is not checked, which means there is no Maxwell material associated. Now let's try an experiment (make sure Maxwell is the current renderer):

• 1. Click File > New.
  2. In the dialog, click "No Template" (to minimize variables).
  3. Create a new Maxwell material, set its BSDF to a red color.
  4. Drag the new material onto layer Default.

The layer's color chip becomes red, and its "Material" indicates "Material," the name of your Maxwell material.

• 5. Click on "Material" in layer Default to inspect its material properties.

You see that the "Plug-in" checkbox near the lower-left corner of the window is checked.

• 6. Un-check the "Plug-in" checkbox and click OK.
  7. Repeat step 5.

The "Plug-in" checkbox is now unchecked, as expected. This Rhino material is not associated with the Maxwell material.

• 8. Check the "Plug-in" checkbox once again and click OK.
  9. Repeat step 5.

Unexpectedly, the "Plug-in" checkbox still remains unchecked. This Rhino material has not been re-ssociated with the Maxwell material. Repeat steps 8 & 9 as many times as you like -- something appears to be broken.

• 10. Repeat step 4.
  11. Repeat step 5.

The "Plug-in" checkbox is once again checked, as is necessary, and as was expected to be the case in step 8. So it looks like there is a problem here -- do you confirm the same behavior there?

Hi JD,
thanks for having a look. I can confirm all your observations.
Not sure if this pattern is only valid for per layer assignments or if this tells you also
about other ways of accidental un-assignement.
I very rarely assign mxms by layer (surely not in the case I posted) but still ran into this.

Holger