Daily Builds 1.5

[blank...]

The easiest way to do all of that, without reinventing the wheel, is to have overrides for post and lighmixer in camera modifier.

[rozpustelnik]

The Lightmixer feature is just incredible :) Pure magic.
Now, if we could easy animate those light scenarios and output frames for a footage...

[johan belmans]

Lightmixer: would it be possible to make use of Kelvin values instead of RGB values?

[Ryuu]

Lightmixer: would it be possible to make use of Kelvin values instead of RGB values?

That's already in my TODO list. The color picker dialog will have one more slider for Kelvin values.

[johan belmans]

Lightmixer: would it be possible to make use of Kelvin values instead of RGB values?

That's already in my TODO list. The color picker dialog will have one more slider for Kelvin values.

Great!

[Flavius]

Please exclude the bloom and glare from alpha channel(element) and/or masking (cmasking wirecolor for eg). Or at least maybe an option to have it on/off. It's quite an issue when the glare or bloom extends over the background. Thanks!

[Nekrobul]

11\10 Coronas for the new light mixer.

It is just super effective in everyday\routine archviz workflow.

+1 for kelvin values

[Ondra]

Please exclude the bloom and glare from alpha channel(element) and/or masking (cmasking wirecolor for eg). Or at least maybe an option to have it on/off. It's quite an issue when the glare or bloom extends over the background. Thanks!

there is a bug, will be fixed

[Ondra]

"lightselect" super easy to set up and really seems powerfull. Haven't even noticed any performance penalty, I guess there is none?

about 1% per one group, so pretty small for most realistic scenarios

[Ondra]

Well, tested Lightmixer in a real life scenario, what to say it is an amazing tool which will revolutionize our workflows, still, as always, there's a room for improvements and here are my thoughts on those which I think are the most necessary:

 1. Grouped light+object support is simply a must - idk who in their right mind will separate the light objects from the rest of the lamp models in real life usage scenarios but I surely won't do that under any circumstances, not to tell what lamps are more than often made by using light object + some ies as a light source itself + self illuminated material on a bulb which of course should both be inside the same group for ease of moving, rotating, adjusting, instancing\cloning and even reusing them later.
 For now adding groups with lights inside is not supported not for material nor for object ones, which makes using lightmixer in real life scenes such as this https://www.flickr.com/photos/119850875@N05/29368457581/in/datetaken-public/ , https://www.flickr.com/photos/119850875@N05/28824417114/in/datetaken-public/ , https://www.flickr.com/photos/119850875@N05/29340216172/in/datetaken-public/ a real chore.

 Solution: well, if due to some sort of yet another 3ds max's limitation, simple evaluation of all light emitting objects inside an added group is not possible to do using that max's exclude\include list (the one used used right now), then maybe some sort of a separate script which could automatically open selected groups add only light objects and light material containing ones from those group to the appropriate render element's list and then close those groups back, could help - not the best solution but surely beats doing that manually. Maybe such a script with a separate panel and gui (something akin to ecximer's lighlister) would be even handier to use and would help handling all of those lights and lighmixer channels\lightgroups in a more appropriate and way more understandable manner than the current need of doing all of that inside the render elements - how to do and design that script's\panel's ui is a whole different matter\discussion of course, but I think it could benefit all of us quite a lot ))

 2. Light mixer states (or something like that) - some sort of savable and custom nameable state list (not unlike the history one) which could simply store and load the values and color adjustments of lighmixer's channel sliders and colors is most surely needed - why ? well, imagine one needs to do some renders of different lighting conditions, like night illumination only\decorative lights only\flood light only\daylight only or some other combinations of them all across multiple cameras with the same results\intensities\colors across those camera\views\renders - the rest is obvious I think ))

 3. Lighmixer does need some separate exposure and post controls - not necessarily a separate ones, as they could be saved inside the above suggested light mixer states as well and loaded\applied automatically when user switches between the beauty pass and lighmixer one or between the lightmixer's states - that would surely make life way easier when rendering something with completely different lighting conditions and thus different exposure and post processing requirements like I mentioned above. Of course the exposure differences can be compensated by simply adjusting the channel value sliders but the other post processing values like highlight compress, white balance or even glare and bloom will not be affected so probably that could be a good solution.

 4. Lightmixer itself surely does need some separate on\off toggle either inside render setup ui or somewhere inside the vfb or inside both - why ? Simple - using it (or any render channels for that matter) increases ram usage quite a lot thus there might be some scenarios which will require to be able to quickly turn it off, well like DR rendering when some of the nodes have less ram than the main pc. Yeah, yeah - I shouldn't be such a greedy sob and buy more ram for those nodes, but sadly it's not always possible - for exampe I've got some i7 920 up to i7 980x's in my puny farm which are old but still quite capable cpu's and the maximum amount of ram which can be crammed inside those is 24gigs (which I already did)) but some scenes require more ram and much, much more sometimes - the scene, which renders I've posted above, requires about 10 gigs to render without the Lighmixer channels and around 19-20gb's when 8 of those are enabled so you could easily imagine how fast one can get those out of ram crashes on nodes. Yeah one could go through the render elements disabling them one by one but that can be quite tedious to do especially when one is in some sort of deadline induced frenzy state )) so having the ability to quickly turn on\off all those light select elements without turning off the rest of render elements is surely needed, especially when there will be more of those channels in some bigger scenes.

 Hope I did at least some right thinking and at least some of those improvements could be approved and made, well, of course, I don't think that some "polishing" of those ideas is not necessary as they are pretty crude first glance type ones, so fellow Corona users, write what you think about those, maybe some of you could suggest some better ideas for making this wonderful tool even more suitable for different types of workflows and usage scenarios.   

nice writeup, thanks. To address the points:
1: of course it is 3dsmax thing :D. The solution here I would like to do is to drop the 3dsmax handling of all (not just light select) plus/minus buttons for objects selection, and do own (one that adds currently selected objects if something is selected, and handles groups correctly). Hopefully I will be able to do it before 1.5 is out.
2: we will try to think of ways to do it. Doing something that feels natural to use will be a bit tricky IMHO - we dont want to end up with overcomplicated UI
3: I would rather not do that - I am thinking about completely replacing beauty with lightmixer result when it is active (transparently to the user), so the workflow is maximally natural
4: lightmixer has zero memory overhead ;) Not even single channel ;). Of course there is the standard overhead of the light select passes, but these can be used also separately without the mixer, and you can already quickly turn them on/off by selecting all of them in the render settings dlg and unchecking active. Additional checkbox is IMHO not necessary and would lead only to more user errors and overcomplicated UI

[PROH]

@Ondra. Just a couple of comments/notes to the list above:

3) ATM all lights are rendered in the Beaty pass. Would it be possible to have a "do not render in Beaty" in the LigthSelect passes. This would be great when for example rendering a daylight scenario in the Beaty pass, and then using the light mixer to build a nighttime viz. Another way to achieve this could be by having a "render hidden lights" in the LightSelect passes.

4) ATM turning a LightSelct pass off in render passes, screws the color assignments in the light mixer up. If for example lightselection number 2 is yellow and number 3 is red, then when turning number 2 off number 3 turn yellow. In short, the colors does not follow the lights, but follows the row number.

Further more:
Could it be possible to use more than one sun in the light mixer? If it could, this would be a massive timesaver when rendering out Sun/Shadow studies.

Thanks for a great tool, that could become a serious game changer:)

[maru]

Could it be possible to use more than one sun in the light mixer? If it could, this would be a massive timesaver when rendering out Sun/Shadow studies.

That's an interesting idea, but I suppose it would be very tricky, especially that the sun also affects sky.

[Tanakov]

I love Light Mixer, its a great tool. Things that I would like to see.

Render Element "Light Mixer" with "add Grups" instead of making 10 light selects.

Why? It would allow to automaticly save the LightMixer 2-3 presets, red light, day, night etc. Plus it would allow LightMix to be saved automaticly as right now when Im rendering 4 frames, I need to click save "LMix" each time in all 4 frames.

Include Enviro could have not only the color add, but also "Saturation" in this one case.

[maru]

I agree with Michal. Light mixer is not a RE now. There is no easy workflow to save an animation out of it yet, right?

[Flavius]

Ok, so something weird is going on... I'm trying to render a scene, 6000 by 3500 px, with displacement. I have a vector map (PhoenixOcean Tex), displacement pixel size to 3.8 px . It worked nicely yesterday (for 6 angles even), and now I need to re-render one of the angles and it is running out of memory, regardless of what pixel size I use. I've even tried 32 pixels and I am running out of RAM (64GB). I've just installed 5 sept daily, and it does the same thing, and I'm not sure how to investigate this (?)
Thanks!

EDIT!! : Ok, so I've figured out what happened. I've raised the plane(the one with the displacement) slightly, and by some weird coincidence it was on the same Z value as the camera, so the camera was somehow "intersecting the plane" and that leads to excessive ram usage by the displacement. I moved the camera 10cm higher and all is fine now