You are right. Mesh light actually faster than the corona light object. I thought that this is the same but with a more convenient parameter setting. With a mesh lights noise is indeed less. Thanks for help!
Sorry for my bad English
I disagree. For planar lights it is the same, and spherical lights are MUCH better as Corona light than actual geometry in the general case. The sole reason that it seems better in some particular settings is that geometry light is interpreted as a separate light for each triangle. So you end up with 320 lights instead of single one. If you have 100 other lights, you end up having higher probability of sampling one of the 320 lights from 420 lights total in light-as-geometry case, than the probability of sampling 1 light out 101 (it is actually only about 50% higher).
This just means, that because there is some defensive sampling involved, you can give higher importance to one light by turning it to geometry. It will render cleaner, but the rest of the scene will be worse. I don't like this solution, but I understand that the sampling in big scenes (>15 lights) is far from optimal. It would be much better to simply have some "visual importance" slider for each light that you can adjust for different shots, but I've been trying to avoid that. I'll try to improve it some other, automatic way first.
Visual importance slider would be no less of a bullshit than regular per-light samples settings in mainstream renderers. It would make a workflow that less efficient and it would not work in majority of the cases. For example in case of the extensive interior space with many light sources as the one that Animator89 did, you would have to absolutely readjust importance value of all the dozens of light sources in his scene for EVERY SINGLE CHANGE of camera angle :D It would also not work in an animation where camera goes through that space. And existence of this setting would imply that without using it, you would not have optimal scene convergence. :)
Even in case this would be the most optimal solution rendering efficiency-wise, it would be really bad solution setup-wise. And artist's time is a lot more expensive than rendering time. There simply has to be a different way... or more probably, a bug inside of currently used light solver. ;)
