- User Since
- Sep 8 2012, 6:11 PM (258 w, 3 d)
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?)
Apr 19 2017
Mar 17 2017
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/
Jan 4 2017
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".
Nov 22 2016
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".
Oct 11 2016
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.
Sep 17 2016
Jul 11 2016
Jun 20 2016
May 18 2016
May 12 2016
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.
May 9 2016
Apr 26 2016
Apr 22 2016
Apr 16 2016
Wouldn't the "both"/auto-bump mode remove the need to use render dice rate = 1.0 in a lot of cases?
Apr 10 2016
Apr 9 2016
Feb 9 2016
Jan 16 2016
Jan 13 2016
Jan 9 2016
Jan 3 2016
Nov 26 2015
Sep 26 2015
Aug 31 2015
Sorry about that. I didn't realize 16bit PNGs went in as float textures (makes sense though).
Aug 29 2015
Aug 18 2015
Jul 17 2015
Jul 7 2015
Jul 5 2015
May 8 2015
Why not add a checkbox for a randomized seed? That's the most common solution I've seen in most other renderers.
Apr 24 2015
"don't think mipmaps are really so crucial for the material preview"
Apr 10 2015
Apr 4 2015
Mar 8 2015
Oct 26 2014
Oct 20 2014
I am still able to reproduce this bug (both red color, and the dot) in both ee5936c and 2.72a official.
Oct 10 2014
Oct 3 2014
Ok, got it built.
Oct 1 2014
Patch doesn't build on OS X/Clang:
Sep 29 2014
Sep 8 2014
8837bb2 should have the red fix, though, right? (seems the OS X buildbot ran right before I checked it this morning)
Aug 24 2014
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?
Aug 15 2014
Jul 10 2014
Jun 23 2014
May 29 2014
May 21 2014
May 17 2014
May 15 2014
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.
May 4 2014
@loptataasdf: cranking tolerated error to 0.25 seems to get rid of it. I only see that error at preview-quality settings.
May 3 2014
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).
Apr 29 2014
Sorry about that. I swear, every other bug report I file I manage to grab the wrong .blend...
Apr 15 2014
Apr 4 2014
Isn't Yafaray's just a simple contrast-based sampler? Just hunts edges, not high-noise areas?
Mar 6 2014
Mar 4 2014
Oh crap, forgot to drag it in. Very sorry! Here it is!
Mar 2 2014
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:
Feb 20 2014
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:
Feb 9 2014
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:
Feb 5 2014
Jan 30 2014
Jan 24 2014
Nov 21 2013
@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.