[Delineator]

I think the new update looks very similar and behaves a bit smoother than the older Silverlight version. The 1 request I have is: can something be done to bring back output presets? We had rolled these out and it saved a ton of issues and errors we had when people weren't rendering to the network properly (I found these especially useful coupled with the naming macros). Its a bit of a pain to configure paths, SL, multilight, and channels each time you open a new file and have to render.

It doesn't have to be exactly the same as before (in fact, a nice import/export option for favorites may be nice so I can admin the master and roll it out to each station), but I'm a bit hesitant to update without this feature (a lot of our staff need a dead simple way).

[JDHill]

If some features are missing now, it shouldn't be taken as indication that they have necessarily been dropped for good, but rather that I want to start making the transition sooner than later (mainly due to the incompatibility with SU2013). That said, since they have to be rewritten, now is a good time to consider better, or just different, ways of doing that, and I welcome any input (e.g. as you suggest, perhaps via import/export, for presets).

As far as updating your machines, that is completely optional, if the existing plugin is still working for you. The new build does not change much except the user interface.

[fv]

JD, I think I have a bit of a problem with the new plugin.

What happens, I for instance put a texture with wooden boards on a surface. Then I rotate the texture manually from horizontal (original direction of the material) to vertical. But after some renders the orientation for all my textures rotate back to their original position.
Copy pasting the geometry into a new file does not solve the problem but when I copy paste the geometry out of the new file into a second newer file then the orientation of the texture shows up in fire and the render as it should and how looks in SU.

Its a rather persistent bug that makes the project I am doing currently almost impossible to do. I had this problem before occaisionally but now it seems to be regular. It does not happen just like that but usually when the file gets slightly more complex using references to mxs as well. Not sure if that has anything to do with it.

if you can solve this (asap) I would be very happy. As soon as this problem shows up with a file it seems impossible to get it right again no matter if you rerotate the texture.
Francois

[fv]

I know now what the problem is.

It seems to have to do with front/back faces. I changed the setting in the plugin to front only. That solved the problem.

Sometimes you can't really see what is front or back when a model is textured and then the plugin does not recognize the rotation of a texture when its using back and front faces to render the same texture on geometry that is exists on front and back faces as well. In my case the other face is texture default.

If you make sure the plugin uses only the front face to detect the texture the problem no longer occurs. Or you have to model carefully never to have a texture sitting on front as well as on the back face of other parts of the geometry.

I still hope this can be fixed since I often use front and back face to render simple models that use walls without any thickness.

Francois

[JDHill]

Thanks for supplying the model, this shouldn't be a problem in the next build.

[I Will I]

Thanks for ditching silverlight, I think you made a lot of mac users happy. However, I am seeing an issue when adjusting the saturation/contrast/brightness in the materials panel. Previously moving these sliders would actively alter the appearance of the material thumbnail to the left of these sliders but now the image remains unaltered when moving them. The only way you can see what the adjustment alterations look like is to re-render the material preview. This behavior is the same in the bump map area as well.
OSX 10.8.4/SU Pro 8.0.16845

[JDHill]

Yes, this is expected. In the future, I'll see if CSS provides enough control for the plugin to once again show you an accurate prediction of what Maxwell is going to do with those values.

[I Will I]

I am getting sketchup crashes whenever trying to export to studio, mxs file and maxwell render. Is this version not compatible with maxwell software outside of sketchup?
OSX 10.8.4/SU Pro 8.0.16845

[JDHill]

It is tested to be working fine here on 10.8.4 & 8.0.16845. When you say whenever, does this mean with every SKP you try to export? Does it occur with a brand new SKP containing only, say, a single cube? Could it appear to be related to a particular texture? It is not unheard of for there to be corrupted textures in a SKP, which crash SketchUp when the plugin asks it to write them to disk.

The thing is, though, rendering in Fire involves an MXS export, the same as any other, so if you can render in Fire, then a failure specifically when using the export commands would not seem to make much sense, except perhaps to indicate that the file system is having some problem with the location you've chosen to export the MXS. If it does not seem related to a particular SKP, I would delete maxwell.rb and the maxwell folder from /Library/Application Support/Google SketchUp 8/SketchUp/plugins, and Skp2Mxs.plugin from SketchUp.app/Contents/Plugins (right-click on SketchUp.app and choose Show Package Contents), empty the trash, reboot the machine, download a fresh copy of the plugin, and reinstall.

[I Will I]

My bad, it would appear it is this file, was working fine before update but stopped exporting after update. It seems like it is an offending texture, if I delete all texture from the file it will export again. The funny thing is that it will run in Fire but wont export to Studio or Render. Is there any trick to easily identifying which texture is causing the problem?

[JDHill]

Process of elimination is about the only way I know. Once found, it should be sufficient to edit the texture in an external application, re-saving it (perhaps to a different format), and forcing SketchUp to replace whatever it has stored in the SKP, with the newly-saved texture.

[I Will I]

I did that with every single material in my model and still crashes

[JDHill]

If you want to email the SKP (jeremy at nextlimit dotcom) or send it via dropbox, I can take a look and see if that also happens here.

[JDHill]

Thanks for sending the files. I confirm a Studio crash with this file when running on OSX 10.8.4, related to the use of grass and certain geometry (apparently no relation between this geometry and that to which grass is applied). Disabling grass on the group whose parent group is second from the last in Outliner (this is the only group in the model with grass enabled), the issue no longer occurs. I note that there is no such crash on Windows, nor on Snow Leopard, that I find graphics & OpenGL areas of code mentioned in the crash, that I only recently updated from 10.8.3, and that I am aware of no previous issue specifically with this, all of which point to the possibility that something has changed in 10.8.4. It is repeatable here (though I observed no issues with the plugin, nor with Maxwell Render -- only with Studio), so I will use the scene to make a report for the Studio developers.

I don't really find any workaround for you yet, though, since I am able to reproduce the issue whether creating the grass in the plugin, or later, after the MXS is already open in Studio -- saving it that way, closing, and re-opening, the same crash will occur. Rendering in Fire in the plugin should work fine, as should exporting to Maxwell Render, it appears to be a problem specifically with the OpenGL and/or UI part of Studio dealing with grass on 10.8.4.

[I Will I]

Thanks for looking into this