[JDHill]

Maxwell for SketchUp
Version 2.6.0 Release Notes

Version 2.6.0 introduces the new Maxwell for SketchUp Standalone plugin.

The Standalone plugin is distributed as a simple .zip file, does not require any Maxwell Render installation, and supports SketchUp and SketchUp Pro, version 6 or greater, running on Windows or OSX. The Standalone plugin has two licenses: a Free license, and a Commercial license. The Free license allows you to render images with Maxwell Render at a maximum resolution of 800 pixels, using Maxwell's Draft engine, at absolutely no cost. At very little cost, the Commercial license allows rendering at 1920 pixels maximum resolution, using Maxwell's Production engine, which is capable of more quickly resolving scenes that make use of complex lighting.

The newly-named Maxwell for SketchUp Render Suite plugin, which corresponds to the existing 2.5-series Maxwell for SketchUp plugin, is designed for use with a full Maxwell Render Suite installation. Since the Standalone plugin is built using a subset of the features found in the Render Suite plugin, the Render Suite plugin can do anything the Standalone plugin can, and much more, being designed to help you leverage the professional-level workflow provided by the Maxwell Render Suite.


Changes:

• Implemented a new Ruby-based exporter, which is used the Standalone plugin, or when C++ export is not possible.
• Implemented inheritance behavior for entity context-menu attributes (Hide-from-X, Separate By, UV Coordinates).
• Added new Ignore Distortion mode in the UV Coordinates menu; this prevents distorted texture files being written.
• Added new Set Projection Size function in the UV Coordinates menu, which allows per-entity sizing of generated UVs.
• Maxwell Fire's Quality parameter has been changed to Max. Resolution, providing precise control over output resolution.
• The plugin's Search Paths functionality has been completely reworked, and a Path Search Depth parameter added.
• When Auto MXM is enabled, materials which will be replaced by an MXMs at export now show their MXM in the UI.
• Added new Cache Policy Option, which controls whether MXS files are written from in-memory Maxwell Fire data.
• The Pick Focal Distance tool no longer deactivates after picking; this is more convenient when using Maxwell Fire.
• The plugin now saves MXM Gallery downloads in Maxwell MXED's Alternative Folder if one has been specified.
• Added an MXM Status Report window, which provides a convenient overview of the state of MXM links in materials.
• Several file assets are now shipped with the plugin; see the mxm, ior, sky, and simulens folders in maxwell/res.

Fixes:

• If a material was shown when initially opening the Scene Manager, its Character UI was initialized to Automatic.
• Wrong normals could be written, due to the use of an API function which aimed at reducing superfluous undos.
• Distorted textures appeared incorrectly in Maxwell Fire; their paths were being pointed to the undistorted versions.
• Multilight was exported using its Intensity mode, even when its Color + Intensity mode had been specified.

[brodie_geers]

Can you confirm a bug for me? When using 2pnt perspective in SU the plugin used to convert the parameters of the shift lens to match up with what you saw in the SU viewport upon export. There doesn't seem to be any such conversion anymore resulting in some quarky camera positioning in Maxwell.

-Brodie

Nevermind, it seems to be working fine now. Not sure what I was doing wrong.

[JDHill]

Just remember that only the C++ exporter can deal with SketchUp's 2-point perspective. So you write an MXS, and you are okay, but there is also Maxwell Fire to consider, which lives in the Ruby world; writing an MXS from data which has been used to render in Maxwell Fire, the 2-point perspective will be lost. Dealing with this is the purpose of the new MXS Cache Policy option (in the Options page): depending on what you choose here, the plugin will either write MXS files from data already loaded in Maxwell Fire, or will perform a whole new export of the scene.

[brodie_geers]

So if i'm using Fire and then want to go ahead and export to Studio I want to change that Cache Policy to Invalidate or Prompt?

-Brodie

[JDHill]

I would guess so, yes, if Studio figures heavily in your workflow. Of course, a full export will take longer than just writing a file to disk, so that's why the option exists.

[brodie_geers]

Any idea why this would be happening? I think the Fire engine is looking to some cached geometry or something? I think this box in the fire window is a test I did yesterday but obviously it doesn't match up with what's on my screen at all (other than the background/IBL.

The result was the same whether I used the MXS Cache Policy as Use Cache or Invalidate.



Edit: I closed the file and opened a blank file and ran fire to see if the box was still there. It wasn't. So I opened the building file again and ran fire and it's working now but that was still some odd behavior. Not sure if there's anything I can do to make sure and prevent it in the future.

[JDHill]

It might have been due to a file being temporarily locked, possibly by a rogue SketchUp instance (you might check for this in Task Manager if it occurs again). That, or I could have an unknown issue with not clearing current data from Maxwell Fire when files are opened. Just let me know if you see it again, and if possible, the sequence of events which led to it.

And just so you know, MXS Cache Policy only affects what happens when you export MXS files.

[brodie_geers]

Still having issues. Not sure if it's the same issue or different but it's related to updating FIRE. I changed the material on a drain and added a bit of geometry but I can't get FIRE to update with the changes. I've re-exported, turned FIRE off/on, even shut down SU and restarted it. FIRE still shows the old information. I went into C:\Users\bgeers\Documents\Maxwell\SketchUp\temp and opened up the latest .mxs that was created and it contains the correct information. I've checked the Task Manager and there's only one instance of SU running. At this point I'm not sure where FIRE is finding the old info at. Or how to update it.

-Brodie

[JDHill]

Could you please confirm whether it is specifically related to this model?

[brodie_geers]

Well I was able to update it by deleting all the stuff in that temp folder. Apparently it was creating a valid temp .mxs file when i started FIRE but for some reason it was referencing one of the older temp MXS files for generating the actual preview (rather than using the .mxs it had just created)? Does that make any sense?

-Brodie

[brodie_geers]

Yes it's the same model as pictured above.

-Brodie

[JDHill]

Yes it's the same model as pictured above.

Sorry, what I meant was, were you able to reproduce the issue using any model other than this one. If the issue was confined to this model, then I would want to ask if you could send it to me for testing.

Well I was able to update it by deleting all the stuff in that temp folder. Apparently it was creating a valid temp .mxs file when i started FIRE but for some reason it was referencing one of the older temp MXS files for generating the actual preview (rather than using the .mxs it had just created)? Does that make any sense?

No, I can't say it makes much sense, but at least it gives me something specific to test.

[JDHill]

Brodie sent me his file, and I was able to determine that this issue, which applies only to the Render Suite plugin, is caused by use of the Output > Auto-rename if necessary option. The workaround is to set Output > Mode to any mode other than Auto-rename if necessary.

[gtalarico]

I am having problems with MXM mode... Maxwell is rendering the application color/texture instead of the MXM...

I didn't notice at first because I had "copied texture to SU material", so it looked like it was working on draft views.... except for the glass

Anyone else?

JD: I can send you a file and you can see if you can reproduce if you would like...

[JDHill]

Could you go to [home]/Maxwell/SketchUp/logs, delete any logs you find there, perform an export in which an MXM link fails, and then check the logs folder again to see what you find there? Mainly, I'll be interested in the name of the log file, and then maybe, what it contains.