There’s been an add-on available for quite some time that allows IES light profiles to be used in Cycles, but recently Lukas Stockner (the guy who brought you portal lamps) has been working on a patch that implements IES profiles natively (without requiring an add-on), which potentially means faster renders and more accurate results.
This patch adds support for IES files, a file format that is commonly used to store the directional intensity distribution of light sources.
The new “IES Light” node is supposed to be plugged into the Strength input of the Emission node of the lamp.
The user interface of the node is similar to the script node, the user can either select an internal Text or load a file. […]
The local coordinate system of the lamp is used, so that the direction of the light can be changed. For UI reasons, it’s usually best to add an area light,
rotate it and then change its type, since especially the point light does not immediately show its local coordinate system in the viewport.
For now you’ll have to wait for the patch to be approved and added into master before you can try it out, unless you’re capable of applying the patch and building blender locally (which I failed at miserably).
BVH caching was originally added in 2.62 in an effort to bypass the (at the time) slow process of building the BVH (Bounding Volume Heirarchy, which is used speed up ray tracing). It would basically store the BVH on your hard drive so that the next time you render the scene (assuming no geometry had changed), it would just read it from the hard drive instead of rebuilding it.
But after just two more releases (2.64), BVH building was sped up dramatically by using all the CPU cores instead of just one. From then on, it was usually quicker to rebuild the BVH for each render than to read the cache from your hard drive, particularly in the case of animations where the BVH changes for each frame and has to be rebuilt anyway.
And thus, that little Cache BVH checkbox became obsolete.
To add fuel to the fire, the BVH cache was never actually cleared automatically (on Windows at least), leaving you with many gigabytes of cached data that you had to delete yourself. Just look in
C:\Users\<you>\AppData\Roaming\Blender Foundation\Blender\2.75\cache to see what I mean. Mine was 170 GB before I realized what was going on.
So finally, Thomas has removed the BVH cache feature:
Cycles: Remove the BVH cache feature. […] The BVH cache was added before we had a multi-threaded BVH build, and a lot of other optimizations were done since then, which makes this not useful anymore.
Finally, we are free from the clutches of accidentally slow renders and congested hard drives.
I just happened to come across this on blendswap, which then pointed me to a youtube video that shows how to set up a node group that gives you some much easier (and probably more realistic) control over fresnel reflections, taking roughness and minimum reflectance into account :)
The author of the video didn’t provide a link to download the node group, so I figured I’d copy his setup and upload it here.
Sergey Sharybin added sphere and tube mapping options to the image node yesterday:
[12ccac6] Cycles: Support sphere mapping for the image texture
[dda3554] Cycles: Support tube projection for images
What is it?
Just the same mapping types we’ve had in BI for years ;)
Sphere mapping allows us, for example, to painlessly map a texture of the Earth onto a sphere without needing to do any UV mapping.
How do I use it?
Simply change the projection method on you image node from Flat to Sphere or Tube, and probably you’ll want to use generated coordinates.
Check it out! https://developer.blender.org/D808
A patch for adaptive stopping and sample distribution has been made off the massive metropolis sampling patch, so I’m guessing that sometime in the next few releases we’ll see it merged to master :)
What is all this you ask? To quote from the patch:
Adaptive stopping: For every tile, the remaining error is estimated after a certain number of samples … Once the error is below the threshold, the tile is stopped. In case the maximum amount of samples per tile is reached, the tile stops as well, even if the threshold is not reached yet. This does not affect the individual pixels in the tile, that’s what adaptive distribution is for.
Adaptive distribution: If this option is enabled, the samples inside every tile are also distributed accordingly to noise levels. Once the warmup interval is over, an importance map is generated and samples are drawn from it (this happens on the CPU even for GPU rendering). This helps mainly for big tiles (usually >32×32) with different levels of noise, for example, at the edge between scene and background.
In retrospect, the name for this blog was a pretty terrible idea.
Most of you have probably downloaded the 2.70 RC by now and probably started playing around with volumetrics in cycles. Immediately you probably noticed how slow it renders, although that was probably expected. Here are the results of a little test I did to find out exactly how to speed up volume rendering for the world up so that it’s actually usable.
The very first and foremost thing you need to know about volumetrics is the difference between Homogeneous and Heterogeneous volumes. Basically, a volume where the density is driven by some texture is a heterogeneous one, and a volume with consistent density is a homogeneous one. The difference in render time and quality is… well, quite drastic:
Homogeneous (2m 40s, 512 samples) vs Heterogeneous (1h 4m 55s, 128 samples)
Yep, you read that right. Under 3 minutes for homogeneous volume and over an hour for a quarter of the samples in the heterogeneous volume. The heterogeneous render seems to have a less dense volume, and I guess it does since it was driven by a noise texture where I couldn’t easily control the density and honestly couldn’t be bothered to wait long enough to give it a decent try. Continue Reading…