[JDHill]

Maxwell for SketchUp
Version 2.5.15 Release Notes

In addition to its Maxwell Fire-based material preview, this version brings Maxwell Fire to the plugin for rendering the scene, along with some other new features and fixes as well.

Changes

• Added new Maxwell Fire rendering to the plugin.
• Added new auto-focus functionality to the camera.
• Added new Network Render menu/toolbar commands.
• Added auto-detection for starting network node & manager.
• Added Z-Clip and Z-Buffer modes to the Pick DOF Tool.
• Added new Output Mode option, which allows for auto-naming.
• Added new 'MXM Information' panel for MXM-linked materials.

Fixes

• Fixed various issues when operating under non-US English locales.
• Maxwell Fire was not stopped upon closing of the Scene Manager.
• Materials list was loaded intermittently when opening models on OSX.
• Texture control is now 'click-to-enable', in order to work around OSX issues.
• Texture lookup had been made case-sensitive in the previous version.
• Zero-value UVs were written for non-textured faces in partly-textured meshes.

Downloads

• Available from the customer portal.

Notes

• These release notes include changes/fixes from version 2.5.1 to 2.5.15.

[fv]

OSX

I am doing a little renderjob for a client.
Noticed that the recent plugin no longer brings the color adjustments to Studio or Maxwell of imagemaps made in the SU color panel.

In fire it looks ok.

Example.
Material with a blue imagemap in SU. Change the color in the Colorpanel to light blue. In Maxwell or Studio the original color of the map shows up at render.

I can avoid the problem by using proper colored image maps. Sometimes its nice to be able to use the same map altered for color in SU.
Sometimes a restart seems to clear the problem.

I will do further tests later. Hopefully its just me.
Francois

[JDHill]

Let me know if you find steps to reproduce it. I would more expect to see this happen in Fire only, since you would need to reload the scene to get the altered texture re-loaded into Fire.

[fv]

It might have to do with Sketchup adding materials by itself. Purging will not always help. Maybe other SU users have some ideas.
It may be something simple not really related to the plugin itself. Under OSX it quickly becomes a problem so I am sure I am not the first to encounter this weird material behavior in SU.
Francois

[fv]

As the deadline was a matter of hours and having to do the rendering in a rush, I just could not figure out why my modelled groundplane would not change color, it was a few cm under the groundplane set by the plugin....

I will still check why often I get misplaced textures. I think it must be because of textures set to groups were they are also set to the parts of groups.

It should actually not happen that the visual you get on the screen is different from the rendered result in Maxwell.


Francois

[stefan_kaplan]

"Rename if necessary" does not work if render is started while Fire is running.
mxs-file is generated with correct name, eg. Render_0001.mxs, but mxi and image-files saves without renaming, eg. Render.mxi and Render.jpg.
Existing files with these names are then overwritten.
(This is only tested on Windows 7. Export destination folder located on the desktop).

/Stefan

[JDHill]

Thanks Stefan, I've corrected this in the code.

[brodie_geers]

I noticed that my HDRI was really dark in FIRE. When I exported to Studio I noticed that instead of intensity 1 it is translating it to .01

-Brodie

[brodie_geers]

Also when I had the FIRE window open (not running) and exported it didn't translate my camera position properly. The location seemed to be right but there was no Offset created based on my 2 pnt perspective SU camera. Closing the FIRE window, and reexporting solved the issue.

-Brodie

[JDHill]

I noticed that my HDRI was really dark in FIRE. When I exported to Studio I noticed that instead of intensity 1 it is translating it to .01

Can you reproduce this with a new model? If there's a problem, it's probably happening when attempting to compensate the value range which was previously stored in the document.

Also when I had the FIRE window open (not running) and exported it didn't translate my camera position properly. The location seemed to be right but there was no Offset created based on my 2 pnt perspective SU camera. Closing the FIRE window, and reexporting solved the issue.

Yes, this is the expected behavior, since during Fire rendering, the camera info is obtained via Ruby, where there is no way of knowing about your 2D perspective camera. This is why you need to do a full export and *not* render it in Fire for 2D perspective to make it through to Studio.

[brodie_geers]

Couldn't reproduce the first error on a fresh file. /shrug

Regarding the second point about the camera offset, I didn't explain myself well. I understand the limitation regarding FIRE calculating the Offset. However, when I have FIRE open in SU and then export the model to Studio, it no longer translates the Offset (in Studio).

-Brodie

[JDHill]

Couldn't reproduce the first error on a fresh file. /shrug

That is what I figured. Next question would be: is it repeatable with the file you were using when you noticed the issue? If so, could you send it to me?

Regarding the second point about the camera offset, I didn't explain myself well. I understand the limitation regarding FIRE calculating the Offset. However, when I have FIRE open in SU and then export the model to Studio, it no longer translates the Offset (in Studio).

Yes, this is because when you have the Fire window open, it is the MXS data contained in the instance of Fire which is written to disk, rather than a complete from-scratch MXS export. You need to close the window to release the in-memory data.

[stefan_kaplan]

You need to close the window to release the in-memory data.

It might be nice to have a switch that turns on/off "full export" (ignoring FIRE data), when pressing Render.
It usualy takes no time to export large scenes and if FIRE has not been updated after creation of new objects/materials, they don't appear in the render, of course.
I'm turning FIRE on and off all the time, mostly because of the Auto Rename If Necessary-issue, but also when FIRE reports something like "triangle without material" and won't render. Closing FIRE seems to avoid these kinds of issues...
/Stefan

[brodie_geers]

I tried it again and it didn't repeat. If it happens again, I'll let you know.

-Brodie

[JDHill]

It might be nice to have a switch that turns on/off "full export" (ignoring FIRE data), when pressing Render.
It usualy takes no time to export large scenes and if FIRE has not been updated after creation of new objects/materials, they don't appear in the render, of course.

I can look at popping up a dialog box when you export with the Fire window open.

I'm turning FIRE on and off all the time, mostly because of the Auto Rename If Necessary-issue, but also when FIRE reports something like "triangle without material" and won't render. Closing FIRE seems to avoid these kinds of issues...

Auto-rename aside, you do realize that you can re-export the scene using the little 'refresh' button in the Fire window toolbar, correct? That will dump the in-memory Fire data, do a full export, and restart Fire.