How to orient an IES emitter with the maxwell plugin?
The IES file is assigned to an emitter, which is assigned to a small sphere, to emulate the lightbulb.
However, the spere has no directionality in itself and by default, the light is pointing downward.
Rotating the sphere has no effect on the direction of the light cone produced by the IES.
Using a spotlight with an IES assigned to it would allow me to direct the light cone, but it does only allow me to set RGB color for the lights, while I need to use Kelvin because it needs to be fully accurate with regards to the lighting data i received from the lighting designer. So that’s not an option.
Use the Rhino spotlight and, in its properties, go to the Maxwell tab and set the light type to IES under Light Modifier at the bottom of the tab. Add the IES file path. The spotlight will orientate the IES pattern.
I tried that as well, but as far as I understand (but I’m just evaluating Maxwell, not a power-user!), the only way to set color with an IES spotlight is by RGB. Kelvin (light temperature) isn’t possible. Which seems like a big issue for the physically realistic renderer that Maxwell claims to be.
Since the only real advantage of Maxwell over other render suites like Vray is the exactness of the light, I really do need to set Kelvins as communicated by the light designer / manufacturer. By eyeballing an RGB color (or even by using an Kelvin-RGB translation algorithm, which is still not fully accurate) the whole Maxwell render process becomes pointless.
Or do you know of some hidden way(advanced settings?) to set Kelvins for IES spotlights?
As far as I can see, you can only do it by bringing the scene into Maxwell Studio instead of Maxwell Render (assuming you have it: it’s the red Maxwell icon in Rhino). Then you can set the spotlight temperature in Kelvin before rendering.
This looks like an oversight in the Rhino plugin - make be worth asking @fernando.tella if the temperature fields can be added to the light modifier fields for the spotlight.
I’m considering Maxwell just because it is integrated into Rhino, so I don’t need to export scenes (or worse: update my original Rhino file each time there are changes made in Maxwell studio).
But then I also kinda expect it to give me full control over light parameters, as it is Maxwell’s USP.
Otherwise, Corona render would be an equal contender for the job, if I wouldn’t mind exporting, or Vray would be good enough if lighting parameters needn’t be too exact.
Bella unfortunately doesn’t fulfill the requirement of the multilight app.
I’m working together with a lighting design studio and am investigating in cooperating with them through a simplified design process, whereby they supply me the light info (IES, position, direction, color) after which I (as an interior designer) would produce renders from within the (apart from lights) fully finished interior. The resulting images are then finetuned by them in the multilight app to ensure it reflects their design intent.
This way there is no need for them to rebuild surface geometry or redo material shaders and texturing, which is an awful waste of time and money.
But all this works under the condition that the lights are fully accurate when I render them in Maxwell, because the lighting designers will only have control over light intensities in the multilight app, nothing else. Hence my concern for eyeballing stuff…
Corona has a multilight feature as well, but they don’t integrate with Rhino, so that would mean exporting again. So that’s off the table…
Yes, making a block out of the emitting object and using an emitting material is the way to do that currently.
The light types that need “directionality” in order to point the light in different directions, like the IES, spots or projectors, have to be included into a block so that you can orientate them if you don’t want to use the Rhino native lights.
I agree with you as I also find the Maxwell custom options a bit lacking when using the Rhino native light objects. I’d suggest the developer add some options to override the intensity and color and include proper units. That “Multiplier” has always annoyed me a bit.
Maybe you can clarify a bit on the intensity multiplier…
Let’s say I assign an IES file to an emitting sphere. Does the IES file already contain the lumen / candela / wattage data fully? Meaning, when I leave the intensity multiplier on “1” I get the exact (default) intensity already specified by the IES?
And if I then render an image and open it in Multilight and slide the intensity slider up to 2 for this light, I get double the values that are contained in the IES (lumen / candela / wattage)?
This is quite crucial when using the Multilight as a tool to derive meaningful lighting parameters for the lighting designers to drive the decision-making process and not just for rendering nice looking images (which Vray can do as well, and quicker).
Maxwell is unfortunately not giving much detail about these subjects…
Yes, that’s exactly what happens inside Maxwell when using IES files. The multiplier set to 1 means it is using the same lumens specified in the IES file. When you move the Multilight slider up and down, the value multiplies the intensity specified in the IES file by that number.
By the way, in the next version of the plugin, we are pumping up the options offered for the Rhino lights, including intensity units and color in K among other things. We are also adding support for Bongo animation among other things.
Hey I wanted to ask if you could help me I have an existing model in Rhino and an identical model in the evo software that already has lighting. I need to take an ies file and put it on the rhino model so that it gives light exactly like the evo model, but the evo model already has lighting fixtures planned and ready that illuminate, and the rhino model has no fixtures. How can I create exactly the same look as in evo if when I insert an ies file I have the option to insert a cone that will shine? For example, I need to prepare a lighting strip that will illuminate the entire length of the building