[Mihai]

How does emitter strenghs behave now? Does it distribute over all the meshes it is applyed to or every mesh gets the strengh specified in the mxm?

Every mesh gets the strength specified in the mxm.

I have to mention we got this request from people using CAD/architectural applications more than those using Subd modellers. They have an interior with 50 ceiling lights, they want to create different groups of lights quickly, merging/disconnecting, selecting, again/re-merging in that case takes more time, than simply applying another emitter material to some of the objects. A toggle perhaps could be made but I imagine how much confusion that would bring.....

[Polyxo]

I have to mention we got this request from people using CAD/architectural applications more than those using Subd modellers. They have an interior with 50 ceiling lights, they want to create different groups of lights quickly, merging/disconnecting, selecting, again/re-merging in that case takes more time, than simply applying another emitter material to some of the objects.

Hi Mihai,
although it might seem to you - but I'm not a chronical grumbler and tend to think before I write...
The scenario you describe here is really straightforward to handle inside Rhino and with the old behaviour.
I'd gladly set up a short tutorial on this.

A toggle perhaps could be made but I imagine how much confusion that would bring.....

This of course had to be a global Toggle inside the plugin options. I would see a nice place for it. Near to:

• Export Blocks as Instances
• Use Rhino Lights
• Cache Meshes
  etc...

[juan]

How does emitter strenghs behave now? Does it distribute over all the meshes it is applyed to or every mesh gets the strengh specified in the mxm?

Every mesh gets the strength specified in the mxm.

That's one of the keys of the "switch to per material" decision. In the new system you apply a material with 500W to 3 meshes and in the render you will get 3 lights that emitter 500 W each one, but in the multilight GUI you will see just one slider to control them all. The units shown in the lights mixer are physically correct: when you type 700W, it changes to 700W in each light, so you always know the power emitted by every light. If you want to control the 3 lights separately, just clone the materials and apply one to each light, you will know exactly the emission power in each one.

However in the old system, if you apply one 500 W emitter material to the meshes, in the render you will get 3 lights that emitt 500 W each one, and 3 sliders in the multilight GUI. Now imagine you need to control these 3 lights together, so you merge the meshes in your modeler, (maybe in Rhino is not such a destructive operation but in general it uses to be a bad idea [*1]) so you get a single slider in the emixer. Ok, you do that but now the intensity of the render has changed, because now you are distributing 500W over 3 meshes. So every time you merge/break meshes you are changing the overall intensity of the scene. Besides to this, you don't know what values you are changing in the emixer, they are not real unit numbers anymore but just multipliers. This scenario is specially funny if the 3 emitters have different areas; in that case the 500W power is not uniformly distributed but you can spend hours playing with maths calculating emission powers of each light depending on how complex the meshes are.[*2]

Working with real units in the multilight emixer is one of the biggest improvements on the new system. In the old system, usability and emission power were coupled and it was a big problem.

So to summarize: We have not done this change only because we are sure it is more user friendly but it is also more correct and makes the whole emission system cleaner and more efficient. A toggle option that breaks this correctness and goes back to the old system is not an option, not only because of the (dramatic) changes it would require but because it will make Maxwell worse.

Said that, we will check if there is something we can do at the Rhino plugin level (maybe others too) to improve the usability, maybe there is a way the plugin internally clones emitters and applies them to a group of objects. If there is a way to make it even better we will do our best to get it done.

Thanks,

Juan


[*1] Apart from the problems that many modelers have merging meshes that are spatially separated into one object, from the rendering perspective separating one light mesh in different parts is less efficient because of several internal reasons, mostly related to the fact that in that case the bounding box that covers all the lights is bigger than needed.
[*2] We can extrapolate all these conclusions to the new color multilight option to see how things will be even worse here.

[Fernando Tella]

From my point of view this new method is so much better...

[Pietro Spampatti]

All my respect Juan

P.

[JDHill]

Holger,

Just to make sure we are on the same page, I'll compare the two common scenarios in the context of Rhino. First, where the desired result is to have a bank of lights under a single ml slider, the steps required are:

• with NURBS objects, under 1.x:
  
  1. select objects
  2. run ExtractRenderMesh
  3. run Hide
  4. select extracted meshes
  5. run Join
  6. assign one emitter material
  
  with mesh objects, under 1.x:
  
  1. select meshes
  2. run Join
  3. assign one emitter material
  
  with NURBS or mesh objects, under 2.x:
  
  1. select objects
  2. assign one emitter material

Secondly, where the desired result is simply to have multiple lights and multiple sliders, the steps would be:

• under 1.x:
  
  1. select objects
  2. assign a single material
  
  under 2.x:
  
  1. create x-number of emitter materials
  2. assign one to each object

So, in the first case, the 2.x system is clearly superior. In the second, I concede that it is more tedious to have to create these extra emitter materials. So, I think the logical solution would be the addition of a single parameter in the emitter, along the lines of 'per-object multilight' or similar.

Would that seem to make sense?

[Polyxo]

Hello Juan,
thank you very much for your elaborate answer!
I see your point and understand the gain in light distribution-correctness.

When I made my request I had no idea of how deep this change reaches
into the core of Maxwell. With my layman's knowledge I assumed that such
a toggle was actually pretty straightforward to do.

While I understand your answer from the technical side I still think that old
workflow implementation is more elegant to handle inside my preferred modeling
application. The limitations found in a mesh-modeller do not apply here.
I never missed anything here (and Jeremy knows I miss a lot
Now one has to clutter the Scene Library with tons of identical materials for the
only purpose of having separate access to their parameters.
Workflow wise that appears to me similar to texturing without
projection-options on a per object level (create one oak-material for the left door
of the cupboard, one [identical] for the drawer front, another for the carved
ornament etc...). Good that cubic, spherical and whatever other projections
help us here, so that we can only use one material for the task.
---
I am glad that Jeremy hooked up default Rhino-Lights as Emitters
around the 1.7 release. They all get their own ML-slider anyway and are certainly a
good choice for the great majority of my Lighting-tasks.

For objects being light-sources I wonder if (on plugin level) some way of convention
could be found which decides whether or not stuff gets own sliders or not.
It would be handy if that worked with object names:

No name or identical name = one common slider for all objects with one Mxm.
Objects with different names but with the emitter applied get one slider each.

People who needed many different lighting variations could even easily script the
material change then.

Holger

[Polyxo]

So, in the first case, the 2.x system is clearly superior. In the second, I concede that it is more tedious to have to create these extra emitter materials. So, I think the logical solution would be the addition of a single parameter in the emitter, along the lines of 'per-object multilight' or similar.

Would that seem to make sense?

Hello Jeremy,
thanks a lot for chiming in!
I confirm the advantages over V1 in case 1 and:
Yes, I'd consider the "per object Multilight a good thing".

[caryjames]

Hi JD and others- I have to agree with Polyxo..... at the moment most/all of my scenes are illuminated with simple plane emitters with mxi gradients applied. I usually use the same emitter material for all planes, but I need the ability to adjust each to a different level. How this worked in 1.x was very easy to control- 1 material applied to 4 or 5 planes that were each labeled in the material editor of Rhino. This way I could tell which emitter I was adjusting in Multilight.

This new system does seem like more work for situations similar to Polyxo's and mine.... also I imagine most product/jewellery designers using emitting planes.
I could definitely see the benefits for certain situations.... I am trying to render a watch with many emitting materials (luminous dial), in this situation I can definitely see the benefits in the new system but for the majority of my work the old way worked terrifically! It would be nice to have the option of how to treat the emitting materials.

Just my 0.02 cents of course

[kami]

I must say I'm happy about the change, because in most of my scenes it would simplify the process. But I can also understand that in some scenes where you have an additional effort.
So an option to chose "per object" would be great!

[ivox3]

Juan said, ...Ok, you do that but now the intensity of the render has changed, because now you are distributing 500W over 3 meshes. So every time you merge/break meshes you are changing the overall intensity of the scene. Besides to this, you don't know what values you are changing in the emixer, they are not real unit numbers anymore but just multipliers.

As far as I'm concerned this was the strongest argument .. The new system is more in alignment with Maxwell's principle ideals. Slowly but surely the removal of guessing or 'eye-ing' it should be made.


Not damned if you do , ultimately, damned if you don't.

ps. Holger -- You should of been a lawyer.

[Polyxo]

This new system does seem like more work for situations similar to Polyxo's and mine.... also I imagine most product/jewellery designers using emitting planes.

Hi Cary,
we all got very used to use single mesh faces as emitters inside Rhino as this was the only option to get something like rectanguluar lights in Rhino
for a long time. But in 1.7 Jeremy has hooked up default Rhino-lights you can now easily use them as emitters and also adjust their global strength.
They all get their own sliders. I'm pretty sure you can replace your emitting mesh planes with them.

[Polyxo]

ps. Holger -- You should of been a lawyer.

Hehe...

[caryjames]

This new system does seem like more work for situations similar to Polyxo's and mine.... also I imagine most product/jewellery designers using emitting planes.

Hi Cary,
we all got very used to use single mesh faces as emitters inside Rhino as this was the only option to get something like rectanguluar lights in Rhino
for a long time. But in 1.7 Jeremy has hooked up default Rhino-lights you can now easily use them as emitters and also adjust their global strength.
They all get their own sliders. I'm pretty sure you can replace your emitting mesh planes with them.

Thanks Polyxo! I heard everyone talking about the default Rhino-lights but haven't had the time to check out what exactly they were. I now have the kick in the pants necessary to read about them! Thanks for taking the time to post
Cary

[giacob]

i agree with Polyxo... surely u have pro and cons as for everthing.... though it dipends very much of the 3d apllication u are using...
for instance:
in Lw 9.6 is more simple to put in modeller , lets say, 9 emitter panels in just one layer ( wich means that they wil be reaD AS A SINGLE MESH) than creating 9 meshes in 9 different layer and appliyng to them 9 mxm named diffeently ....that is undoubtly true

got it ?

so Juan dont complain abot some of us complaining ... unfortunately one must have to weigth pro and cons carefully before changing things ...
surely, as before explained, this change is not good as a default for Lw users
the better would be to have both option....