[softroom]

Does anyone know / have / want to start a collection of luminaires (light fittings) for Maxwell? I've avoided the issue for a couple of years now, but need to start using some good spotlights in scenes. IES files give a beautiful look but won't work with what we're trying to do, so will need to resort to modelled lamps. At the very least, a wide beam recessed downlight, a narrow beam spot lamp and a wide beam flood lamp would be a great start.

[brodie_geers]

Can you post some example photos or something like what you're looking for and/or describe why IES won't do what you're looking for?

-Brodie

[softroom]

I particularly need a narrow beam spot that can pick out an object the size of a chair from 5 metres away - will post pics next week.

IES won't work because I need to be able to join multiple emitters into a single multi light channel as you can do with plane / geometry emitters. Now, you can actually join multiple IES emitters in this way, but I am using rhino which doesn't allow you to point IES lights anywhere other than straight down... Alternatively you use rhino native lights and attach IES data to them and direct them where you want ... but then you can't join up those native lights into a single multi light channel.

So a geometry solution would be ideal, but so far I haven't been able to model a narrow beam spot....

[brodie_geers]

Well, the trick is that there is no trick. What you'd need to do is model the actual light, and reflective parabola at the very least - maybe even a special lens. Basically you'd have to model it in the same way that a real spot light is constructed. However that's very problematic as you're starting with a multi polygon emitter which isn't ideal, then you're bouncing the light off of a highly reflective material which instantly turns all of that light into caustics. And if you add a lens, then you're adding refracted light into the mix. The result is going to be a lot of noise that takes a very long time to clear up. So just make sure you've exhausted all options before you do that.

For example, you might just want to live with the extra ML sliders. Or perhaps you export the scene from Rhino to Maxwell studio where you can rotate your IES lights.

-Brodie

[softroom]

Thanks Brodie - I agree with your analysis.

I should probably explain that the context for using Maxwell here is that I want the designers in my architecture studio to be able to use the system as a design tool, not just a visualisation tool. So the more they can work with 'real' lights and not have to learn the tricks of CG artists, as I had to for years, the better. OK at present there are speed etc issues, but looking forward, I do believe that Maxwell (or something similar) is absolutely the future for this type of activity.

The technical limit I am currently facing is in part down to the fact that renderfarm I want to use has a limit on the size of MXI it can handle of 5GB (it can't merge the data from all of the render nodes if they're each above that size). For a 4,000 pixel image, this seems to equate to a limit of about 14 MultiLight channels.

Although the multi-light mixer in Maxwell Render 2+ seems to treat all emitters using the same emitter texture as one even if they are not joined together (at least when output is via the Rhino Plug-In), that's unfortunately not how the renderfarm interprets them - each un-joined emitter source has its own Multi-Light channel regardless of whether they share the same emitter texture. (I need to investigate why there's this discrepancy.)

(We need to use MultiLight to be able to generate lots of options on each scene and work interactively as a design process, but we will diligently 'pre-bake' and merge as many lights at a set value wherever possible, even though that smacks of working for the machine, not the other way round! It's still not quite 'as easy as using a camera' unless that camera is a Victorian glass plate one...)

Doing the lighting in Maxwell Studio is an intriguing option, but I find the Studio interface unhelpful compared to working in Rhino, plus its another link (and potential bottleneck) in the production chain and yet more for the team in my studio to have to learn...

So I think my Rhino-only work-around will be;

* use low-poly emitters with standard Maxwell emitter type for flat illumination - merged into single Multi-Light channels where possible
* use IES lights for straight-down vertical illumination and merge them into a single Multi-Light channel
* use individual IES lights mapped onto Rhino's native lights for accent spotlights that need focussing - in reality this probably doesn't need to be very many in any given scene, so shouldn't be a problem to keep below the approx 14 total number of channels.

This all leads me to add my voice to the wish list that Maxwell incorporate a feature for interactively creating IES lights within the application on the fly, using the sort of spotlight controls you find in regular CG applications- where you can adjust the throw and beam angle through a graphical user interface. Also a simple multiplier command, even though it's contrary to spirit of Maxwell etc etc, as having to crank up the values in Multi-Light each time is a chore, especially when you have one IES emitter applied to a number of merged points and the power goes down accordingly.

[brodie_geers]

Understanding your usage certainly helps. I could see how physically modeling the lights could be of some use in your situation, although if you're concerned with additional training it could simply cause more issues (ie. learning light fixture construction including appropriate material properties, etc.) besides the basic render time issues. You could spend a lot of time learning how a given fixture is designed only to get a reflection property wrong somewhere and end up with a very inaccurate result. IES data is measured from actual light fixtures in a lab so if you're looking for accuracy that's you're best bet, besides the speed factor. But it sounds like you've already come to a similar conclusion.

I'm not sure of all the factors that go into the size of an MXI, but ML is certainly one of them. A 5gb MXI at 4000px sounds large to me but I'm not sure I've ever run a render w/ 14 ML channels. Only suggestion I have there is to make sure you're using instances. I've got a friend who uses Rhino and by the sounds of it, it doesn't have a well integrated instancing system so perhaps you're not currently utilizing that which would significantly reduce MXI size.

Your analysis is correct regarding ML channels. Maxwell 2.x groups emitters based on texture name rather than geometry. This effectively eliminates the old habit of joining 2 emitters and then having to double their strength in the texture. What you're experiencing through the farm sounds like aberrant behavior and should be solved on their end.

I would suggest that the extent to which the Maxwell Studio is helpful relies totally on your modeling packages limitations. I use mostly Sketchup and sometimes 3ds Max. Max can do everything Maxwell Studio can do and it does it better. However, sketchup leaves me with a couple limitations which mean that although I'd love to just render directly from SU it's often better and faster to do some work in studio (eg. importing high poly objects like cars and trees). It's not ideal and if you can avoid it, without a loss of quality/speed, then I would, but just be careful not to take it off the table too soon as an option. The interface gets some taking used to but if all you need to know is how to open the mxs, find your ies objects, and rotate them, it's not too bad. The bigger issue, is having to redo that each time you make a change back in the Rhino file (there's a workaround or 2 that could speed it up a bit but not a lot).

Your ies wishlist is an interesting idea. Sometimes Maxwell can suffer from too much real world accuracy and not enough flexibility. IES lights is a good example. You essentially have to pick out a particular light fixture and bulb strength up front rather than being able to simple interactively adjust strength and beam angle on the fly to make it look good (much better from a design standpoint where you haven't picked a fixture yet). And it doesn't violate Maxwell's unbiased nature because it would still be treating the light in a physically accurate way.

-Brodie

[Petero]

Great discussion- great suggestion about conrolling IES emitter beam shape through the Maxwell interface.

If I have understood correctly... the accumulation of sliders in multilight when exporting from rhino could be solved by going into the MXS file generated and deleting the separate (but exactly similar) Emitter materials generated except one, and then just re-asign your lights to that one Material. Afterwards your slider whould be only one for that Material no matter how many lights you have. I just did this from Bonzai3d, and it worked perfectly.

Peter

[softroom]

Hi Peter;

We've been doing quite a bit more work with this since the last post and now conclude that;

• Mapping IES emitters onto Rhino spotlights works very well.
• Native spotlights with IES emitters mapped onto them can't point straight up or you get an error.
• You don't get an accumulation of MultiLight channels if all the Rhino spotlights have the same IES emitter texture assigned -and you're using the latest versions of the software!
• We're disciplining ourselves to 10 MultiLight emitter channels, and think of them as equivalent to different 'lighting circuits' in a real interior.

But yes, a bit of interactive IES beam shape design would still be great.