[crcgrp]

Has anyone had a problem where two materials switch in the render? I have two brick materials on a building, Fire looks ok. Even exporting from Studio, pack&go, and Maxwell switches them in the Render. But doesn't do it every time. We have the full suite.

[JDHill]

If that is happening, there is a reason, but I wouldn't be able to tell you what it is without being able to reproduce the behavior here directly. So if you can send the model (jeremy at nextlimit dotcom if it is small enough, otherwise dropbox or similar), I'll take a look and try to identify the cause.

[crcgrp]

Ok, I'll have to dropbox it. The model is huge!

[JDHill]

Thanks, I got the model; no kidding on the size, it takes something like two minutes here just to open it. This may take awhile -- to narrow things down, could you please post a quick screenshot showing a couple of places in the model where you see the materials being mixed up? Or do you just mean that the brown bricks on the buildings get swapped with the black ones?

[JDHill]

I have a few more questions. Mainly, could you please describe for me, exactly, the sequence of steps which leads to the error? You say it works fine in Fire; then you talk about a workflow involving Studio. So please expound on that, and include any other factors you think may be relevant, such as the use of network, shared folders, etc. I need to know at which point the issue starts to appear. Because I haven't yet seen it, and I haven't yet found anything suspicious.

[crcgrp]

This has happened, same model, but a few different people rendering it. It has happened rendering locally or via the network. I have had it happen rendering straight from Skp to Maxwell, or going through Studio, using that Fire to make sure it looked ok, and then rendering from there. It can happen, then I just hit render again from Skp and it works fine. Not sure how much help that is. Basically, I could find nothing in a specific workflow that I could point at and say, "this is what's different then when it renders fine".

[JDHill]

Thanks. This seems like an interesting sequence:

1. export to Studio.
2. render in Fire in Studio to confirm everything is okay.
3. render to Maxwell from Studio and find the materials rendering wrong.

It seems like Maxwell could be getting confused about a texture filename, or finding a similarly-named, but wrong, texture, using one of the search paths. How many search paths have you added in the plugin, in Scene Manager > Options > Search Paths, in Studio Preferences > Materials > Textures, and in Maxwell Preferences > Paths? Studio also has an "Extension independent textures" option that could come into play. And one more question would be: do you recall ever having seen this happen with another model?

[JDHill]

I can think of one theoretical possibility, and it involves the fact that the two materials in question share a texture of the same name. During export, the plugin asks SketchUp to write textures to disk. One is written using the texture name indicated in its SketchUp material, which is brick3RDS.jpg. As this name is already taken when the second is written, it is given the same name, but with a "1" appended: brick3RDS1.jpg. Since the order of texture-writing is not known by the plugin, and since nothing specifically guarantees that existing texture files are overwritten each time, it is theoretically possible that the order could be reversed from one export to another; were that to happen, the export would be correct, but at render time, the contents of the two textures would appear to have been reversed. Similarly, even if this did not happen, but if you copied the exported MXS, along with its textures, into a different directory, where there had previously been an earlier version including these textures, if Windows showed you the "overwrite?" message, and you did not respond in the affirmative, you could end up with a directory where the contents of these two files were reversed.

So, the thing to check, the next time you see this happen, is what the two textures actually contain, in the location where they are being found by Maxwell, at render time. It should be useful here to look in Maxwell's Console window to see where it is resolving the location of these textures. You can then open the offending MXS in Studio, and see what is happening there -- which texture contains the brown bricks, which contains the black bricks, and the paths at which they are being found.

Regardless of all that, it seems clear enough to me that if you used SketchUp's "Edit texture image in external editor" function to edit the texture, saved it using a unique filename, then re-linked the SketchUp material to use the new uniquely-named copy, it would not be possible for this problem to occur.

[crcgrp]

As luck would have it, I tested a render this morning and the brick is reversed!

First, the skp file is out there on our network, not local.
I hit render straight from sketchup, did not use fire. I did create a new local folder just for this render so I could see what happens with the texture export.

I searched through the Maxwell console and found that it was pulling the majority of the textures (maybe all) out of the texture folder where the sketchup file lives, not where the new mxs file is. I thought it would look where the new mxs file is first.

But what I found is what you indicated. In the texture folder on the network where the skp file lives, the two textures are reversed. brick3RDS.jpg is the dark grey but should be the red, and the brick3RDS1.jpg is the red but should be the dark grey.

In the texture folder that was created with the export in the brand new folder I created locally, the textures are correct. So it seems that Maxwell is looking in the texture folder where skp is first and finding the textures there and not looking anywhere else.

I always thought that it would render the "newest" textures, the ones exported with the mxs from sketchup.


On another note, when I first started seeing this problem, I also thought it might be something related to the similarity in names between the two bricks. I selected the dark grey brick and renamed it in the sketchup material dialog box a completely different name, "brick black" I believe. I don't see this anywhere in the texture folder, this name.

So, that means that the name of the color within sketchup, the one that shows up at the top of the material window, does not necessarily relate to the name of the texture that is exported?

[JDHill]

Yes, that is true; while it may not appear so from looking at your material list, there are any number of unique versions of any given material (mainly due to things like faces with distorted textures). The name, though, that I was referring to, is not the material name, but the file name of the texture (under the "Use texture image" checkbox in the SketchUp material editor) used in the SketchUp material. This is where your similar texture file names are coming from.

So it seems that Maxwell is looking in the texture folder where skp is first and finding the textures there and not looking anywhere else.

Yes, if it finds a texture, then there is no reason to keep on looking for it elsewhere. That is not the problem. The thing to understand is that if you have Pack & Go enabled, then the MXS will not contain any absolute paths; they will all look like textures/texture.jpg. If texture.jpg really does exist at textures/texture.jpg, relative to the MXS, and Maxwell still chooses to find that texture at some other path stored in the MXS search paths (there is an array of paths written by the plugin, to be used as hints for where to find missing things), then this would indicate some faulty logic in Maxwell's process of looking up textures.

And checking with a simple test, it looks like that is the case, which is why with Pack & Go enabled, you are seeing Maxwell find textures in the wrong folder. So I'll have to notify the engine guys about this, and in the meantime, you can either not use Pack & Go, or you can use it, but make sure that there aren't multiple texture directories containing similarly-named, but different, textures, next to the SKP, and next to the MXS. Or, you can just avoid having multiple materials in SketchUp use similarly-named textures.

[crcgrp]

Ok, I see the problem now. It is referencing the same texture under the "Use texture Image" in the Materials palette, I didn't realize this. That makes much more sense to me now why one or the other could be named or referenced wrong in the texture folder.

This is really good to know though, in this office most people rendering are just adjusting the colors within sketchup. Now I see where that can be problematic.

Thanks for the help! I will advise people not to do this in the future.