[jvanmetre]

JD-

These are similar issues to what I'm finding with Rhino/Studio -- although I'm not sure it's related to Rhino.

I'm getting very erratic results with renders -- I will post a few.

http://www.maxwellrender.com/forum/view ... hp?t=28645

http://www.maxwellrender.com/forum/view ... hp?t=28702

jvm

[jvanmetre]

This top rendering went to SL 18.14

The shelves are a standard dielectric mxm from wizard -- very noisy.
The bottles are preset mxm from "frosties" collection.

Supports where vertical risers meet the underside of clear shelves -- triangles are appearing.

The back riser is the same standard dielectric mxm from wizard (same material as shelves). It has a white material behind it -- very noisy.



Here's another -- this went to SL 18.14 too.

Notice triangle on the back vertical panel. Same materials, preset "frosties" mxms, dielectric from wizard -- very noisy render.

[JDHill]

These are similar issues to what I'm finding with Rhino/Studio -- although I'm not sure it's related to Rhino.

If you render from Rhino, do you ever get the 'triangles with no materials' issue, or is this only after you open in Studio, then render?

The shelves are a standard dielectric mxm from wizard -- very noisy.
The bottles are preset mxm from "frosties" collection.

The basic difference between 'White Frost' and a (plugin) wizard dielectric is: is Reflectance 0° (0,0,0 vs. 64,64,64), Roughness (30.0 vs. 0.0) and Nd (1.2 vs. 1.51). I'm not exactly sure how this comment pertains to the plugin.

Supports where vertical risers meet the underside of clear shelves -- triangles are appearing.

...

The back riser is the same standard dielectric mxm from wizard (same material as shelves). It has a white material behind it -- very noisy.

...

Notice triangle on the back vertical panel.

Are these surfaces co-planar?

[jvanmetre]

JD-

I can render direct from Rhino -- I do not get a "triangles with no materials" message.

"Triangles with no materials" is a problem with Studio -- what I've noticed is that when I've changed an mxm (while using the Rhino plugin) the error becomes noticable in Studio and with MXCL. I think it's more subtle (at least in my experience) than saying it's only Studio.

It seems that changes to mxms are either not being read correctly in Studio or they are not being recorded correctly at the Plug-in level. Pure speculation on my part though.

As far as I can tell, the surfaces are not coplanar. Some of the clear materials are stacked though -- I tend to add a gap where two surfaces meet in that case.

This update to 1.7 I'm finding to be a bit of a struggle -- I'm trying to understand why materials I've used consistently in the past are giving different results this time.

Thanks for your help.

Jim

[JDHill]

Well, we can start in one place and move to others. To begin with, if I:

- assign a Material to an object in Rhino
- export to MXST
- inspect the exported material in Studio

Here, it matches. If I then:

- alter the Material in Rhino
- export to MXST again

The changes are brought over fine. This is because, when you export an MXS, it overwrites the existing one. There is no link or relationship between the two 'versions' of this MXS - they are completely different files. So I don't know how to comment on the 'it's more subtle (at least in my experience) than saying it's only Studio' aspect - either the MXS has materials assigned to objects, or it doesn't.

There were times in the past where there could be conflicting material names in exports made by the plugin, and these would result in 'no material' errors, but there should not be any issue with this now, and as you said, rendering directly from Rhino (i.e. not using MXST to re-read/re-write the file first) works fine. As was the case when errors were found in previous plugin versions, I would need to see a file - I can find where specific errors come from, but I could rarely guess at what it would take to create one.

[jvanmetre]

JD-

Thanks for your reply.

I will try your suggestions.

The reference to a subtle issue is based on things like the material editor becoming unresponsive at certain times and having to click on a different material in the window to regain responsivness. For example, a material may be open in the window and I want to click on a layer but instead it has frozen on a layer. Only when I click on a material "scene material" can I get it back.

jvm

[JDHill]

That (unresponsive mat editor) is a plugin issue already reported (by you ) which involves some low-level Windows peculiarity - I still have not been able to determine what is causing it.

[jvanmetre]

Huh! The issue seems more humorous now ..(but hey, I'm consistent!)

It seems less subtle and more noticeable now -- where the material editor becomes locked out.

What to do?

jvm

[JDHill]

Well, I don't know what to tell you at this time, that's why it's an unsolved bug. I can only observe it here maybe once every couple of days and in the rare instance where I've been able to get the debugger attached, it doesn't appear to be anything I can specifically prevent. There is just something about how I've built things that is causing a transient disconnection...as noted in the bug report, if you seem to see any pattern, I would like to hear it.

Practically speaking, getting out of this scenario usually involves selecting a different material in one of the browsers, or something in the viewport - this seems to get the dialog back into the loop.

[jvanmetre]

I do understand...

A concern of mine is that an unresolved issue(s) are related to the results I'm seeing with some renders.

jvm

[JDHill]

I don't see any way to connect those issues. The unresponsive editor is purely a GUI issue...Windows works by sending 'messages' to different windows, each one gets to look at the message and decide if it should do something - in this case, the Material Editor is getting taken out of the 'loop' - the messages are not being passed to it, making it unresponsive. It does not know that you are clicking on items it contains.

Just more in general...try to avoid making yourself more confused than necessary - that is, when you face a problem, be as methodical as possible. If you are seeing an issue where materials seem to be different when exported, confirm this by inspecting the MXS in Studio. If there is no difference between the two, you can rule out the connection between the plugin and Studio. If you have ruled that out, and you have an issue with materials becoming 'un-assigned', examine the exact scenario you're dealing with.

Things to consider for a problem like this...

- in an MXS, materials are associated to meshes by their names. What do the names used in your MXS look like? Do they all use simple names, or are there any characters that could pose problems? Are there names which only differ by upper/lower casing?

- you use Studio's Pack and Go. When you open the MXS it produces, do the materials inside look the same as the ones in the source file? Their names? The names of your meshes? Now, when you move it to another machine, are these things still looking the same? So, you render, and get an error message. Which object is giving the issue? What if you re-assign its material - does it now render?

Finally, there is more than one way to do things. If you are seeing some issue with Studio's Pack and Go (I haven't yet) try using the plugin's 'Relocate Paths' method. As this is new, I'll tell you what it does:

- select 'Relocate Paths' from the Maxwell menu > Scene Data Management
- you will be prompted for a new MXS output path
- once chosen, all textures will be copied to a 'textures' folder next to the new MXS location
- references to these textures in the current scene will be changed to point to the newly-copied textures
- you can now export the MXS

After doing this, if you export an MXS, the paths it contains will point to the textures which have just been copied. When you move this MXS and the 'textures' folder next to it to another machine, Maxwell will find the textures regardless of their paths, since it checks this location. Therefore, if you use this method, you do not need Studio's Pack and Go function.