blender -b eevee_duplis.blend -f 60

Wouldn't generally supporting lamp nodes in Eevee be important anyway? The current system means even blackbody lights and lamp intensities in Cycles won't translate to Eevee correctly. Eevee is effectively using BI's shading system for lamp settings, and Cycles' system for surface shaders.

A modifier like this can be used to clone geometry for use with duplis, such as turning a single face into a ring of faces for use with duplifaces for the real geometry. This particular modifier could also be useful for radial symmetry when poly modeling, something that is currently much more awkward than it needs to be in Blender.

The OSL shaders that were floating around BlenderArtists had an optimization to skip everything except camera rays. Obviously that won't work for baking, but for rendering it can work well. (might want to include singular rays as well?)

There are actually few cases where you want to render at those exact sizes. It usually causes more harm than good, see here: http://endcrawl.com/blog/2048x1152-is-a-total-crock/

The problem is, nobody uses OSL because it doesn't run on GPU and is frequently much slower even on CPU. As long as SVM is faster even on CPU, no one will use OSL except as an absolute last resort. And maybe not even then, since OSL doesn't run on GPU and there's no reasonable way to change that anytime soon. There will always be user pressure to add this or that texture to SVM, just to have it on the "fast side".

Left enum as is for now. Not sure what's actually better here.
Using absolute values will be somewhat more flexible for adding
new hard-coded values, but wouldn't let us using some special
values like "Auto texture size based on screen space".

An idea I had in the aforementioned Twitter discussion: why not put it in the Geometry panel under render settings? It seems more natural than the scene panel, they are Cycles' specific geometry settings, after all.

I think I mentioned this to DingTo in IRC, but if we're eventually going to be running all textures through MakeTx or our own pre-chewing utility, it can do this while building the mipmapped version.

Wouldn't the "both"/auto-bump mode remove the need to use render dice rate = 1.0 in a lot of cases?

Sorry about that. I didn't realize 16bit PNGs went in as float textures (makes sense though).

Why not add a checkbox for a randomized seed? That's the most common solution I've seen in most other renderers.

"don't think mipmaps are really so crucial for the material preview"

I am still able to reproduce this bug (both red color, and the dot) in both ee5936c and 2.72a official.

Ok, got it built.

Patch doesn't build on OS X/Clang:

8837bb2 should have the red fix, though, right? (seems the OS X buildbot ran right before I checked it this morning)

Oops, somehow I got confused. This function is part of the node wrangler addon, not the regular compositor. The regular image sequence functionality is fine. Do bug reports for addons go someplace else? Or can this task be converted?

Do we really need to be filling up task/tracker pages with requests for builds? There's plenty of that at BA as is. There's no pages here, so it makes it much harder to follow progress when there's tons of "compile for me plz". BA's forum setup makes it a lot easier to work with general discussion, plus there's a lot more people there who can help with building anyway.

@loptataasdf: cranking tolerated error to 0.25 seems to get rid of it. I only see that error at preview-quality settings.

Time based could be a problem when the scene is rendered on another computer with much different performance (say, an old workstation that retired to the render farm).

Sorry about that. I swear, every other bug report I file I manage to grab the wrong .blend...

Isn't Yafaray's just a simple contrast-based sampler? Just hunts edges, not high-noise areas?

Oh crap, forgot to drag it in. Very sorry! Here it is!

Ok, patch 14 did the trick! Here's two test renders. The thing that hit me immediately was how slow MLT mode is now. It took 90 seconds to do 10 samples. Progressive can do a 120-sample render in the same amount of time. (here's the outputs of those two)

Clang barfs there too:

OS X/Clang is complaining about something else:

The rest of the settings on that test were the defaults for the BMW scene, so 128x64 tiles, 200 progressive samples. I'm not sure it's realistic to expect much better when we still have the same number of AA samples on all tiles. Large tile sizes have a performance hit of their own in CPU mode, so just making them bigger isn't realistic either. I think we really need to wait until there's an option to stop some tiles before max samples (that way you can just pad out the max AA value and only use it on the tricky tiles).

Quick test on the Mike Pan BMW scene:

Do both! Use the importance sampling within the tile to hit the threshold faster. As far as a avg noise vs max noise vs changed pixels vs pixels below threshold, I don't really know. Might be best to just give several options so people can test. After running it through some scenes, you could hide/disable modes that prove unreliable.

How did you plan the adaptive sampling to work? Adaptively distributing a fixed number of samples across the image? Or setting a range of possible AA samples and letting each tile cut off where needed in that range? Because Vray/MR do the latter, and that avoids the problem of some tiles needing more samples than others. For example:

reflection/refraction working fine here on both patches. Something I should've pointed out before: In intern/cycles/util/util_color.h line 240, Clang/OS X doesn't like

Here's a test of the noise map generator with some pokemon models I have laying around:

@Greg Zaal (gregzaal) I kinda like 0.2 as the default. Most of the time you don't actually want a perfect mirror. 0.2 is closer to the value i end up using a lot of the time.