[m-Que]

Hey everyone,
I was wondering - I remember in 1.x Multilight was object driven, meaning I could have like 10 objects with the same emitter applied to them and I would get 10 layers when multilight was enabled.
Now, in 2.5 (not sure about the recent versions) multilight is emitter driven, meaning every multilight layer is set to particular emitter no matter how many objects it is applied to.

Am I missing something

EDIT:When trying to render an instance with an emitter applied to it, I get an error message: "Instances of emitters are not supported".
Is this a known limitation?

Thanks

[brodie_geers]

You're not missing anything. If you have 2 lights and you want two sliders in ML, now you have to apply 2 different materials to them.

Not sure about the instanced emitters, but that error sounds familiar.

-brodie

[m-Que]

OK, imagine having an exterior shot of facade with like 20 lights on it and you want to have every light as a separate slider. So, back in 1.7 you would just select all the lights and apply one desired emitter to all of them, enable multilight, and you're done.
Now, in 2.5, you have to clone that emitter 20 times and apply it manually to every single "light", just to make multilight work...
But the worst thing is, the client can just say: "Nah, those lights suck. Change them to something else" and you go all over again, and again, and again...

I really don't get it - what was the point of that change

[brodie_geers]

Pretty much. I myself have mixed feelings about the new system. Richard, who's been pretty vocal about his dislike of the system as well, has a thread over at the wishlist section as we speak requesting to simply go back to the old method.

I think the reason for the switch was that before if you grouped 20 emitters and they were 100 watts each, you had to change the material to 2000 watts which is pretty counter intuitive. Unfortunately, I think the current method, although perhaps more intuitive, creates some workflow issues, as in the example you mention.

I don't know what the solution is. I'd like to see a 3rd alternative develop but I couldn't say what that would be.

I wonder how Thea does it?

-Brodie

[Mihai]

Before this change, "the other side" kept asking for ML to be material based because most often they would have to merge the emitter geometry itself to not have a ML slider for each piece of geometry. So it seemed practical and faster to keep ML at material level. Otherwise if you changed your mind about a configuration you would have to un-merge the geometry, do different merging etc. Isn't it more common you want 1 ML slider for one group of lights? You also don't have to keep track of the nr of individual light geometries you merged to multiply the emitter strength. Perhaps it will be possible to have an option for ML in Render Options - material based or geometry based.

[brodie_geers]

Maybe, this is just crazy talk, but what about having the option you're referring to, but rather than having it globally, having it within the material itself (ie. a checkbox labeled 'separate sliders' or something). So basically, things would, by default, work as they currently are. But if you have 20 emitters you want on 20 sliders, you apply your i100w-separate.mxm to them which has the checkbox ticked and MR knows to give each geometry it's slider.

-Brodie

[pipcleo]

how about an option where only SPECIFIED LIGHTS could be attached to the multilight function ?

[m-Que]

Thanks for your reply, Mihai.
I know you guys are trying to meet everyone's expectations, I really appreciate that.
Still, before that change there was a simple yet effective workaround like "export selected" for example, so you could always go back after merging without a loss, while at this point I'm not aware of any other solution but manually cloning & applying materials one by one, and it takes time - and that is critical especially at deadlines.
So it would be really great if you could get that extra option in "Render options".
And everyone will be happy

[Richard]

I think this is one of those "Us and Them" cases! It may suit certain model apps or workflow but not the other and those who rally for change voice opinion where those not seeing an issue remain silent or assume change would be an option - not an either or!

@ Mihai - Mate I know in Sketchup for one it was a simple case of grouping components containing an emitter to create a common channel. One would then only require a minimum number of emitter materials most likely representing a temp or RGB value of the light - thereafter intensity adjusted by group.

I've never previously tested groups containing multiple emitters to comment on functionality there, I would assume most would group emitters of common type anyway, ie: kitchen downlights v's dining area downlights both of which may be differing fittings or sources though each group of common effect.

Certainly the option through both Studio and the plugins to elect either option is Brilliant!!! I would add that in both situations the option to also preview / render with ALL emitters excluding "environment" would be another great option. Digging for emtters amongst objects in Studio to hide them during tests and particularly now with bulk added materials can prove time consuming.

[JDHill]

Mate I know in Sketchup for one it was a simple case of grouping components containing an emitter to create a common channel.

Sure, in SketchUp, but in Rhino for example, you would have had to extract a render mesh (remember Rhino is NURBS-based) for each of your emitter geometries and then you would need to merge the resulting meshes together into one mesh. If you changed the location of a single emitter, you would then need to delete the consolidated mesh from your model and repeat this extract/merge/assign emitter process. The alternative was to have 200 sliders in your multilight panel.

There are also other considerations; for example, I think that you have previously asked to save the state of multilight out to a file, and then to read it back into Studio or a plugin. But what would it actually mean to do that, in either the old model or the new one? In the new model, the process can be straightforward; in multilight, you are adjusting the intensity of emitter materials, so we just need a way to push that change back out. In the old model, however, the multilight sliders were tied not to a material, but to each piece of geometry. So in that case, where does the real value live? The answer is that it lives in two places: as an output specified in the emitter material, and as a per-object intensity modifier. So where your objects A and B have multilight values of 110% and 180%, there is no way to push this information back into a single 40W emitter material.

The core of the issue is that we are using two incidental properties (i.e. emitter output value and/or object-modifier intensity values) to represenent a third, unspoken concept: the idea of groups of lights. I would propose a simple solution: the addition of a single 'emitter group' string to objects. As you are modeling, where you can currently set the hide-to-x flags, you could also type in an emitter group name. When you rendered, each of these names would be seen in the multilight panel; when you moved the slider for a group, each object which had subscribed to that group name would have its output modified by the slider value. Probably, I would propose dividing the multilight panel into three main sections: environment, materials, and emitter groups. If you did not set the emitter group name on any object, the third section would be empty.

[Richard]

JD - I in part understand what you are saying! I can see from your rhino example that the option of material based groups is certainly a requirement.

Certainly your suggestion toward assignment of an emitter to a named group would suffice and possibly even preferred, I can think of several senarios that workflow would be advantaged by this option. In fact I'm buggered to think of any that it wouldn't be!

In regards to my previous request for emixer data to be loaded back to the app or studio for the time being is actually pie in the sky really as testing with emitters on due to the increased emitter materials isn't really an option as testing is considerably slower!