Kévin Dietrich has been working on something I didn’t even know was possible: motion blur support for meshes that have a changing number of vertices, like fluid simulations.
Tag Archives: blender
Commonly Ignored Feature #18: Alt-Click
If you Alt-Click on a property, it’ll work on all the selected objects at once, not just the active object. This works on most properties, including modifiers (as long as all the modifiers have the same name, which they do by default).
I don’t think it needs any more explanation than that :)
Rolling Shutter Coming to Cycles
Sergey is working on another cool motion-blur-related(ish) feature: The rolling shutter effect, which you find in most photo and video cameras these days.
This is presumably to help with integrating renders with fast moving camera footage, but of course you can use it for whatever crazy purpose you desire ;)
It’s not in master just yet, but there’s a solid patch awaiting review:
This is an attempt to emulate real CMOS cameras which reads sensor by scanlines and hence different scanlines are sampled at a different moment in time, which causes so called rolling shutter effect. This effect will, for example, make vertical straight lines being curved when doing horizontal camera pan.
Sergey did a quick render test to demonstrate it a bit more clearly:
(with rolling shutter, a vertical pole is moving left to right)
New Pixel Filter Type: Blackman-Harris
A new type of pixel filter called “Blackman-Harris” has been added to Cycles by Lukas Stockner to compliment the existing Gaussian and Box filters.
From the commit:
This commit adds the Blackman-Harris windows function as a pixel filter to Cycles. On some cases, such as wireframes or high-frequency textures, Blackman-Harris can give subtle but noticable improvements over the Gaussian window.
See also: The initial patch with some discussions.
What is a pixel filter you ask? As I understand it, it’s basically the function used to apply anti-aliasing in your render. Different filters use slightly different math and methods to calculate how each pixel appears relative to its neighboring pixels, which makes edges look smoother.
The difference between the three types is most noticable on thin details like wires:
Native IES Support on its Way
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.
See D1543:
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).
Cache BVH Is No More
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.
Fix T46162.
Finally, we are free from the clutches of accidentally slow renders and congested hard drives.