[Richard]

JD

With the old flow I put my common light fittings within each room and group them thereby automatically creating a new MLight emitter group (slider) - simple and perfect as I didn't need to count on varied mxm emitters! I just counted on the default export to do this!

Just wondering mate how this same WF might be achieved with the new plug - god I hope not by materials or at least an option to not?

Mate I wonder if an override for separations might be needed to the plugin dialogue as right clicking parts of the model to enact is maybe less required - though to be honest I've never really worked out the differences as the default worked!

BTW mate the plugin to direct to render,into studio and out from there is faultless this end so far excepting a few flutters with the material picking in SU and not sure exactly what's been bugging me as I've been doing with client so have to take some time alone to make notes.

Oh and JD the DOF function I could just about cream over - how simple and cool is that!!! Man we have the ultimate camera control now!! WELL DONE! Never even realised how much I needed that!!! I might do some tests playing with the component created from SU's create camera function to place planes that can be virtual guides for depth and even then thinking about it even as a guide for z buffer settings! Hmmmm?

BTW again what are the bracketed numbers after materials in studio and why to only some materials?

[JDHill]

In Maxwell 2.0, you get one multilight slider for each emitter material -- sorry if that's a problem, but the plugin doesn't have anything to do with it.

I think someone else asked about a global 'separate by' switch, but I'm not yet really convinced that there's a real need for it. I mean, it's probably not difficult to add, but I don't want to clutter this plugin up with obscure options unless they provide a generally-useful, non-trivial benefit.

You will generally see bracketed material names when a material uses a SketchUp texture. It may not be apparent from the surface, but every time you use SketchUp's 'project texture' feature, SketchUp creates a brand new bitmap which contains the results of the projection. Therefore, the plugin has to keep track of every SketchUp texture on an individual basis, and write separate materials out for any that use projected textures. There may be some other similar cases too, but I would have to examine the code to say what they would be.

[Richard]

In Maxwell 2.0, you get one multilight slider for each emitter material -- sorry if that's a problem, but the plugin doesn't have anything to do with it.

OH NO! Bugger - bloody! S*^% life just got A LOT harder! What a nightmare, did they break that? Surely it wasn't chosen as a development!

Will IES lights fix this by functioning as a group under multilight?

Now I'm looking at like 15 emitter materials in my average scene rather than 2 previously! That doubles my material count in most scenes - amazing!

Mate is there any possible work around for this via layers or anything? - this is almost enough to head back to 1.7.1! I'd love to hear how others overcome this if they can tune in?

[JDHill]

Well, it was done because people complained alot about having to physically join emitter meshes together in 1.x to get them under a single ML slider -- and you may not be aware, but doing that involves alot more work in some other modelers than it might here. So, rather unexpectedly, the change ended up receiving mixed reviews. My suggestion has been that it would be made an option -- basically, a toggle in each emitter material that would set the method used for meshes which use that emitter.

And no, there isn't any way that I know of to get around it.

[Richard]

Thanks mate!

I'll jump on my self righteous box and rally for support - "bring back the option, bring back the option, bring back the option!".

Cheers mate!

[Richard]

JD I'm thinking of a workaround for this issue!

Does the plugin now support materials painted to nested geometry within components (I haven't tested)?

Meaning if my light fitting is all painted as required excepting the emitter geometry, then when they are inplace just selecting the appropriate emitter material (su material with assignments) and painting to the component will paint the nested emitter geometry - the question is will this stick? To edit the fittings grouping can then be done with a simple repaint?

[JDHill]

Material assignments are SketchUp's territory, so if a particular inheritance strategy works in SketchUp, then it should work in the plugin too. Excepting the idea of back-face materials, of course, so keep your eye on that (and face normal direction too, especially with emitters) if something isn't working like you think it should.

[pochi]

I would also like to have separate emitter sliders in Multilight for the same reasons.
Similar to Richard, I would place same light fittings to different locations in a arch-vis scene and use Multilight to play with the lighting intensity of the different light groups for the final image. These light groups vary from group of ceiling downlights to single pendant light.
So, it would be great to map these groups of 'lights' to separate emitter sliders.
I imagine this option would be generally useful for arch-vis??

BTW, I tried Richard's potential work around.
Applying material to faces without material assignment within nested groups worked. But I still needed to create multiple Sketchup colors and multiple MXM emitter materials (emitter1.mxm, emitter2.mxm, etc) to achieve the separate control desired.

[Richard]

Thanks Pochi for reporting back on the potential workaround! That will at least somewhat overcome the issue!

The application of materials does however allow for easy naming of ML channels!