I know this is probably much better suited for the developer forums, but I want to see if anyone ever feels the same way, or if there is some way to do this already that I just dont know about, perhaps.
I think I may have said something about this in the past, however, I cannot remember. I would love to be able to (after the rendering process is over) clip each light pass individually. If one light isnt bright enough, I can go back and adjust that one light without brightening the whole scene, and if there are several lamps, Even with different brightnesses, because the post rendering brightness is achieved through a multiplier and not a value, if 2 lights are grouped, 1 is set to 1 and the other is set to 2, and I raise the “gain” or multiplier to 2 on the group after rendering, it will make the 2 into a 4, and the 1 into a 2.
Realize, I am not heart set on this, but it would resolve having to go back and re render if 1 light, or a group isnt bright enough. This is a feature of maxwell, and luxrender that I absolutely love. Both are physically based renderer engines, while cycles isnt, so I dont know how it would work, but if it could be done, It would be awesome…
Just looking to hear peoples thoughts before I proceed to the dev forums.
Please do not post needless comments, and if you do not understand the point than I suggest getting HIGHLY antiquated with luxrender, and you will see why it helps.
Blender has lux style tonemapping now, but only for the whole render.
Although AFAIK you can adjust individual light group intensities post render in lux, but, from the wiki:
Light groups are intended to help setting up the right mix of lights, but for any final renderings it is advisable to adjust the light intensity values correctly before starting the rendering.
.
Light groups as implemented in lux would be very useful in Blender and can now only be achieved with considerable difficulty by adding drivers and constraints. But it can be done, of course.
This may have been a needless comment. Please ignore it if you find it to be such. I consider myself reasonably antiquated, so thought it would be OK to post, but you know how the mind goes first.:evilgrin:
Just saw your edit, so this comment is being edited as well.
I dont doubt it would be difficult, especially because to the best of my knowledge cycles works on a mix system while lux is a physically based layering system. For luxrender they just adjust they layer (im sure there is more to it) vs cycles, where everything is part of the same render, nothing is ““on top”” of each other, and even if you use nodes to make it so, post pro on 1 layer doesnt post pro the layer below it.
I bet this could still be arm bent with some nodes, but Im not sure, and if its something that a dev is curious enough to take an interest in, I think a light group feature would be much more helpful.
This has nothing to do with being “physically based” or anything. “cycles works on a mix system while lux is a physically based layering system” <— this comment doesn’t even make sense. The way these features work is actually pretty simple: it just writes contributions of different lights to different passes. You then add all these passes and get the final result. If you want a light group brighter or dimmer, you just scale that pass up or down. In fact, Lux has a little known button in the export image menu called ‘export light groups to EXR’. You can take the EXRs it spits out and layer them in Blender’s compositor (or AE, or Nuke, or whatever) with simple add nodes. The factor/opacity becomes the light group strength. You can even do cool tricks like applying glare effects to individual light groups prior to comping them back together.
The reason it’s not recommended for final rendering though (besides the extra RAM) is that significantly altering the brightness of group can invalidate assumptions made by things like MIS and adaptive sampling, and you can end up with a lot more noise than if that light had the proper power at render time.
Also, the only way to make it work properly with traditional lighting passes (diffuse, specular, etc) is to have a separate one of these passes per light group, which gets pretty silly (who wants to comp 36 lighting passes…anyone?)
First, I don’t think this is a physically vs non-physically based render thing. Second, Cycles is physically based-ish. It just makes the concession of using rgb instead of using an actual spectrum like Luxrender. I don’t know how Maxwell works actually.
The lightgroup thing in luxrender is really useful, I think anyone will agree with you. You can already use passes on direct and indirect for glossy, diffuse and transparent, which gives you some flexibility. So cycles does not lump everything together as you suggest in your response to DruBan. Furthermore, you can tweak those channels in any way you want using curve editors or whatnot.
To use light groups, you could set something up using renderlayer, by having your light sources on different layers. That wouldn’t be to hard to set up.
And here is the luxrender developer… Like I said, I dont understand all of it and im certain a developer could correct me.
In a way the comment makes sense. But obviously i dont know enough about either engine to clarify what I meant.
Any ways, I learn something new everyday. I wish I had the tollerance to learn how these engines actually worked to an in depth level. I want to want it XD Ill stick to rendering for now, I think.
As far as explaining how this actually works, thank you so much. It instills a small amount of belief that this could actually be applied to cycles. I certainly am more of a luxrender fan, but unfortunately I dont have a render farm to render large scenes quickly, so I am reliant on SLG, which never fails to make a point to me that it is still a WIP.
Anyways, again, thanks for the clarification, and correcting my previous statement.
“the” luxrender developer? I have like 4 commits to the core engine. I just poke Luxblend with a stick sometimes. And I’m mostly working in Cycles these days anyhow…
I agree. I attempted to play around with render layers a bit, with no success I might add. I was basing my comment about it being lumped together based on the standard tone mapping node and exposure settings.
Still, I think a defined setting, or node for it would be a cool feature. Whether it happens or not.
Well frankly it’s impossible to decide between the two anymore, LOL, cycles has nodes but wait Luxblender has nodes now …but lux has volumes oh wait cycles has volumes now … but lux has world volumes but wait …
I would love to have such a feature in cycles. But having 36 passes Surface/Light Passes does indeed make little sense either… But with the right tools built into blender this could work.
I could see renderpasses as a solution -IF, BIG IF cycles would threat Background sampling somewhat smarter - much faster. Right now if you render a tiny object with all Background around it with 4000 Passes it takes forever - it can’t be it wastes this much time on the background. The background is fine after 1 Pass - it does not need to waste another 3999 on it.
I wonder how big difference in render time can be between using light groups and using a trick with multiple renders with one group of lights in each of them.
The point of using light groups is the fine control over the result after the render. Compositing of 36 layers can be pretty easy if you use an advanced node compositor (not the one inside Blender). Just make a preset and change the input. The control over the result without the need to re-render is definitely worth it. But this is currently possible in Cycles and the only reason for using “real” lightgroups would be a big rendering speedup (I doubt that the difference would be very significant).
its not impossible to decide. at least not for me. Cycles looks good, but placing lights in impossible places, unrealistic brightness that doesnt truely effect camera reaction, only reflections and poor shadows that often need a lot of post pro kills it for me. If I want math thats gonna blow me away, I always revert back to lux, but its render times are kindof touchy. I hate complaining about render times, because it seems like people would sacrifice quality for speed in a heart beat, while if anyone had the computing power nesecary, they could make an informed decission based on the scene they are rendering… but thats not the case.
besides, cycles still has yet to include ray absorption, a proper dispersion effect, and despite now having volumes, volumetric glass still has to be faked. Its colors are too bright, and its ability to have a sat above 1 still is not helping its case of realism… Cycles is good, and it certainly has reached a greater level of user accessibility than lux IMO, and is clearly easier to use, just based on what I have seen people actually make with it vs lux, but it only proves that people have trouble using lux, not that lux is inferior, or even at par with cycles, at this point. Both engines are progressing rapidly.
The main thing that’s really missing here is that Cycles currently does not have a way for the user to create ‘light index’ passes that would be comprised of the illumination result for just that group of lights. Even then, this is something you would do in the Blender compositor for Cycles, since there’s no need to have a specialized UI for it like in Luxrender.
Regarding the Lux forum developer labels, from my knowledge, if you did anything to contribute to the Lux core or to one of the exporters, you are considered a developer, so it gives the impression that the Lux forums are swarming with developers even though the majority of them haven’t touched a line of C++ shading code
Im certain you are right… hes “the developer” ok… I know that people who make contributions are ““developers”” but I see very few of them regularly contributing to the blender artists comunity as well. Since i see J here rather often, hes the developer.
As far as the GUI, I agree, it doesnt need to be blown out, just give us an option in the world setting for it or something that will enable a node, if you add the node your self it automatically turns it on, you turn it on and it automatically adds the node. the output node would have a “light groups” input maybe, and the light groups node gets plugged into it. whenever you make a light group, it adds the name of the group and a gain slider to the node. obviously use nodes would need to be enabled, but I dont think thats hard to figure out for anyone who would even be using this. IDK, if it happens, I dont really care how it happens, as long as it makes things easier and not harder to use. I dont doubt that its not the best option for a final rener, like said by j about lux, it uses more ram (not usually a problem for me) but while in the light testing stage, yeah, it would help…
I am trying to get the lighting right on my viper and have rendered it probably a good 40 or 50 times because for whatever reason the changes to the lights dont show up on VP render so I have to do a full render each time, to at least 400samples to see the full effects of the lighting. Its more time consuming than it should be.
Can you elaborate? Both Lux and Cycles compute linear equation and produce exact colors (despite XYZ-RGB out of gamut things). Maybe you mean built-in Lux Reinhard post pro tone mapper? But Blender approach was to use Compositor for such things, as well as bloom and sparkles.
ray absorption was introduced in trunk two years ago as “ray length” data exposed to shaders. Not one click solution, you need to hack every material with exp(-distance*sigma) custom math nodes, but it fast and had full feature for years.
Recent volume addition in trunk have even better solution, just plug Volume Absorption node to Volume socket.
Yeah, Lux’s “clear” volume and the vol. absorption shader Cycles is getting in 2.70 are pretty much identical. Just some minor workflow differences, that’s it.
The user-facing side of light groups in Cycles is easy. Give materials and lamps a “light group” field, either text or a menu, where you select the group. You know, same as in Lux. How you get from that to the actual passes is a developer’s problem, not an artists.
And finally, yes, the Lux “dev” flair is really more of a contributor flair. Not only is it given out to UI and exporter devs, but a couple of people have it from documentation and PR work and don’t even have commit access. Most people who have it actually have done at least some core work though. (even me! I copypasta’d some crap once and made an extra light sampling mode). I also find it really bizarre that we now have 4-5 posts about what forum flair I have on the Lux board. I didn’t realize that was a such a popular and contentious subject. :D:spin:
I can elaborate. The math is calculated the same sure, the way other objects react to the light is very similar, ill be it, but yet, in lux render, bright objects come out white wite with an almost haloing effect, cycles comes out almost dim, and lunlike lux, if one light gets brighter, the whole scene gets brighter, where lux uses the camera settings so the exposure stays the same. If 1 light gets too bright than the other ones still appear to cast the same gradient, however they are dimmer. Cycles just gets brighter and brighter and brigher without adjusting contrast or gamma untill its a white scene. I dont know if there is any merit in what I am saying from a developers stand point, but I can tell you all about it from the users end.
The Reinhard tonemapper in Luxrender changes the exposure of the scene depending on the maximum brightness of the lights, this works well in some cases (like reducing the tweak time for light power in indoor scenes), but in others, you might lose finer control on how exactly you want the lighting of the scene to look and you have drawbacks like the outside world being blown out if you’re also wanting the image to have lighting from inside a building (I give it to you that’s not how cameras work, but not everyone wants to create an exact replication of photography. I don’t think people want to be placed in a situation where they can’t get the balance they want in terms of brightness because real cameras can’t do it, even though the human eye can).
I have like 4 commits to the core engine. 