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.
