All images in cycles are stored uncompressed… why? because everytime a sample samples that map… it would have to decompress it & sample the pixel… all which would add on extra time to the actual render itself, overall becoming more inefficient.
Depends where they came from I guess. I don’t see anything wrong with it if they are paid for to sell. Considering I have 158 myself, most from a single source, all free, I’m assuming those are not in the collection. But yeah, I’ve seen (assumed and claimed) high quality HDR’s for sale for ridiculously high prices. I have some high quality ones myself (several hundred megs in size, some 50Mpix+ res, some very high dynamic range), but these are neatly stored away in a directory called “TooBigToBeUseful”, as Blender can’t handle those (haven’t tried in a while though).
I don’t have the addon, so I don’t know what the script actually do. But if future updates are planned and the thing kept alive, a couple of suggestions:
- Provide a couple of methods to scale the sunpoint. What I see in the screenshot looks, well, not too clever.
- Preview mode to see exactly where the scaling starts (see my example).
- Options to use very low res one (needs separate scaling most likely, since lower range) for diffuse only.
- Toggle switch for using a dedicated pre-tonemapped camera version.
- A procedurally created environment map with adjustable sun position, sky, clouds, ground texture, haze and all that jazz. I’m trying something like this myself using the sky texture, but I find them ridiculously hard to get useful brightnesses out of, and I don’t seem to be able to figure out how to position anything using the vector input (my maths suck I guess). This can be useful if you want to share a scene without providing an HDRI, and have the exact same result.
So here’s three tests, all same settings except of course for ProSky’s node set up.
I think part of the faster render time for ProSky is that the bottom half of is not rendered, but anyway, it’s not
‘the most realistic lighting’ for Blender, HDR’s are the most realistic lighting. I think that tag line is slightly misleading.
First is just an HDR, second and third are ProSky.
Also, check out Greg Zaal’s blog about his free HDR’s and his .80c per HDR pack here: http://adaptivesamples.com/2015/06/23/whats-with-the-hdris/
I’m glad you wrote this so I didn’t have to.
The other thing I would add is that when lighting with HDRIs there is absolutely no reason to be using 200+ MB images. What matters for lighting is dynamic range not pixel resolution. There is a reason on set HDRs are almost exclusively captured with chrome balls rather than Gigapans. Using HDRs isn’t hard, it just requires a little education.
Not quite, although Pro-lighting does follow the same general approach as Smart IBL it uses a number of simplifications. Being a Blender exclusive the UI is simpler and it is an all in one pack so it is easier to get started with. However, it is also less flexible and you can’t use the IBL sets interchangeably across different applications.
The main technical differences compared to the Smart IBL addon seem to be:
- Pro-Lighting doesn’t break out the Reflection image as a separate map.
- Pro-Lighting doesn’t support direct light sources
- Pro-Lighting doesn’t include any full dome HDRs (this is true for the demo, so I assume it also applies to the full version).
- Pro-Lighting doesn’t provide the option to generate a ground plane with your background plate mapped to it.
- Pro-Lighting doesn’t include grading of your input plates.
- Pro-Lighting uses a slider on its UI panel rather than a rig in the 3D scene to control world rotation.
I might quibble a little bit with the claim that “Pro-Lighting: Skies: [is] the fastest, easiest and most realistic outdoor lighting available for Blender.” It seems like a perfectly reasonable implementation of the Smart IBL lighting concepts that have been around for nearly a decade, but it certainly isn’t unique. The main criticism I would have is that the bundled images are all half dome: What about bounce lighting off the ground?
For reference the world node setup used by Smart IBL addon is attached below.
Somewhat offtopic, but do you guys realize all this stuff is evaluated at runtime with every environment light sample? The shaders are interpreted, so all these constants aren’t getting optimized away or anything.
I’d love to see a performance comparison between such a complex environment light setup and a simple HDR. Also, some of the sIBL concepts (like using pre-convolved maps for diffuse lighting) are good practice in other renderers, but not necessarily in Cycles where you have importance sampling for the environment.
that’s good to know, thanks.
That’s simple to test. Some results using this set:
rendered with 200 samples and multiple importance sampling turned on. All other settings are defaults.
First the simple HDR setup, which required 515 M of RAM and rendered in 9.34 seconds:
Next the sIBL version, which required 261 M and rendered in 10.28 seconds:
The render time for the simple version will need to be much longer to reach the same noise threshold as the sIBL version. Note that this test only uses an 8k background plate, if you want a higher resolution background plate the differences are going to be even more dramatic. I would say that even with importance sampling the general approach is still worth pursuing whether you do it with sIBL, Pro-Lighting, or your own homebrew configuration.
Wow I did not realise that the difference was that dramatic.
Oh well, I should’ve been way more specific.
I was interest in a performance comparison between a noodle soup like the sIBL addon seems to create by default, and a simple image in a real scene, not sIBL vs full-res HDR. Of course, if 85% of your image is not even geometry, the environment is going to be sampled much less.
Obviously, the approach of sIBL to use a blurry image results in less noise, but it wipes out the detail, which is why you want secondary lights with sIBL to get sharp shadows. This may not be necessary in your HDR, because there is no dominant small lights. If you want to use this image for lighting directly, your MIS resolution is way too low. Try something like 2048 or 4096 and you’ll get rid of the noise. You don’t have to use a full-resolution HDR for lighting either - separating lighting and camera visibility is still a valid approach, you just don’t have to blur it that much.
Feel free to post your own test results. All of the necessary code and data is freely available.
It took me longer to write-up my results than to run the test and that, after all, is half the point of cookbooks like sIBL and Pro-Lighting.
OK I couldn’t help myself, how about this scene with 12.2 million verts?
Simple HDR setup; MIS: on, MIS resolution 4096
Required 1027 M of RAM and rendered in 85 seconds:
sIBL setup; MIS: On, MIS resolution: 256
Required 264 M of RAM and rendered in 83 seconds
sIBL still resulted in less noise with the samples allotted and in this case did it in less time (although the difference is still a rounding error). What’s notable though is that it did it while using a quarter of the RAM of the naive approach.
Feel free to post your own test results. All of the necessary code and data is freely available.
It took me longer to write-up my results than to run the test and that, after all, is half the point of cookbooks like sIBL and Pro-Lighting.
I’m sorry, I have no intention of installing these sIBL programs/addons for which I have no use. If you can post a .blend file with such a noodle soup, I’d like to test it however.
To illustrate the difference for using the blurred environment and the 2K HDR, using Ditch River:
(using 512 samples)
Ditch-River_Env.hdr with MIS resolution 512, render time: 12.8s, memory: 5.26M
Ditch-River_2k.hdr with MIS resolution 2048, render time: 13.3s, memory: 66.31M
Notice the sharper shadows. (Unfortunately I wasn’t able to find a free HDR which truly captures the dynamic range of the sun.)
As you can see, the only argument in favor of using the blurred image would be the reduced memory image. However, I could’ve gotten away with a lower-res HDR too. There is no need to blur.
Um, it actually should work, for the construction of the sampling distribution the full shader is evaluated. Are you sure that your threshold value is not too big?
sIBL still resulted in less noise with the samples allotted and in this case did it in less time
Well, your sIBL result has a much lower dynamic range (and thus less chances of noise/fireflies). Is this really using the blurred HDR for environment lighting, or is it mixing with LDR? (are there secondary lights?)
As for the noodle soup, I did make a test with two dozen useless math nodes where it did give an overhead of about 30%. I guess your sIBL setup has way less nodes than that, or the difference exists only on the GPU (I didn’t test CPU, which I assume you are using). Either way, thanks for testing.
Here’s my results with that HDR:
blurred HDR:
[ATTACH=CONFIG]392299[/ATTACH]
8k HDR, (4k MIS res):
Indeed there’s more noise, but same dynamic range.
I used a treshold so that only the sun comes through. I’ll try it again…
I don’t know about you,beer but, back in my Cinema 4D days, Sibl was essential
saved so much render time and it had a really realistic result.
That HDR doesn’t have a visible dominant sun. Try the Ridgecrest Road instead, and when placed on a small ground plane, observe:
Shadows well enough defined? Plane must be small enough to allow ground indirect light.
Diffuse terminator well enough defined?
Is the sun still bright enough to be reflected off very weak plastic reflection (<4%)?
Ref: http://www.bernhardrieder.com/images/Kugeln.jpg
If reflective ground is overpowering the sun, which can easily happen because there so many more pixels of it compared to a sun disk puny 0.5° size, the setup is wrong. The setup I showed where you push a slider to “isolate the sun disk”, the trick is to exclude pixels that do not belong to the “sun neighborhood”, but keep it as big as required to reduce noise (including some corona and glare). Nobody would spot sun illuminating “sun disk” being somewhat bigger (within reasonable inputs :)) than the real thing, as nobody can judge this based on a weak reflection. Depending on how many pixels are scaled up, resulting in a much brighter illumination, you’d have to scale down the output to compensate. And rely on good old fashioned eye balling.
Cinerender and vray are not what I would call “old”
I didn’t call them “old”. What’s “old” to you? Renderman? It doesn’t matter, they’re certainly older (and way cruftier) than Cycles. sIBL was designed to solve problems that don’t really exist in a pathtracer with MIS (like Cycles) and that probably don’t exist in recent versions of Cinerender and VRay, either.
Exactly, that’s the entire point of sIBL. Image based lighting is great for GI it isn’t so great for direct light sources (even with MIS). Therefore, sIBL doesn’t try to rely entirely on image based lighting, it uses an environment map for the diffuse light and lamps (by default sun lamps in the case of the Blender addon) for direct light sources. Effectively it is user driven MIS and says that the direct lights are the most important light sources and therefore the artist should be given as much control as possible over them.
Really? All the results posted so far, including yours, show the sIBL approach using significantly less memory while rendering in an equivalent amount of time and producing less noise, all while providing more control to the artist.
You’re also neglecting the most important benefit of using a cookbook like sIBL or Pro-Lighting, the recipes they come with. Those recipes might not be the perfect solution to every situation, but they do enable an extremely quick iteration time.
Having a lower dynamic range is the point of sIBL? IBL is good for GI and bad for direct light?! sIBL wasn’t created for flexibility, it was to make IBL possible in older renderers at all. In Cycles, nothing stops you from adding secondary lamps or reducing the dynamic range of your HDR if you want that flexibility, but you can’t get back the lost accuracy from the approximations done with sIBL.
All the results posted so far, including yours, show the sIBL approach using significantly less memory while rendering in an equivalent amount of time and producing less noise, all while providing more control to the artist.
I’m not that convinced about this, to be honest. You didn’t provide an image that showed a comparable result (that is, comparable dynamic range) between sIBL and regular HDR. You can’t argue that you really didn’t want that dynamic range.
You’re also neglecting the most important benefit of using a cookbook like sIBL or Pro-Lighting, the recipes they come with. Those recipes might not be the perfect solution to every situation, but they do enable an extremely quick iteration time.
I’ll give you the memory usage, although the overhead with 2k HDRs is already negligible. I’m mainly arguing against the use of pre-blurred maps for lighting the environment. It’s marginally less noisy, and it destroys your “natural sun” (or other sharp light sources), which you then have to make up for with an artificial lights. For all your “flexibility”, you’re either relying on someone else to have provided a decent sIBL file for you, or you have to create it yourself (at which point the “iteration time” argument becomes moot, because using simple HDR files is faster).