Pixel filtering
Hi, it would be cool if we could get some advanced pixel filtering algorithms like Mitchel. The lack of filtering forces you to always render with a pixel size of 1.0 and deal with jagged edges, anti-aliasing and crisp fireflies. The standard Gaussian blur doesn't look great on the final render.
It has actually been requested/brought up before by a few users (myself included) and would be indeed welcomed.
However,
Fireflies is a different issue (this guide might help).
Worth to mention that the texture-level filtering ≠ Render Kernel Pixel Filtering, as I've seen some users mistaken one (former) for the other, likely not you.
However,
Mitchel is considered as a legacy Pixel Filter for legacy rendering solutions that were designed differently (lacking shading samples per pixel), pre path-tracing era - among some others that are also not appropriate to a path-tracer (such as, box/triangle, catmull-rom, sinc). I would tend to think that Blackman-Harris (quite standardized in production renderers, for animation or VFX) would be the alternatively offered filtering option as being a fair middle-ground between sharp and soft and being a recent up to date filter to this date, or rather last time I checked.kabakZ wrote:it would be cool if we could get some advanced pixel filtering algorithms like Mitchel.
There is a pixel-filtering, currently. It's mandatory for rendering, which I'm sure you knew already and might have been a phrasing matter.kabakZ wrote:The lack of filtering
It isn't forcing everyone.kabakZ wrote:forces you to always render with a pixel size of 1.0 and deal with jagged edges, anti-aliasing and crisp fireflies.
Fireflies is a different issue (this guide might help).
If this is referring to the current Pixel Filter, it may be subjectively not matching your needs. Aside from that, it is "fine" and has been for many years, for many projects done with Octane by numerous users. It doesn't change the fact that more filter(s) would be welcomed.kabakZ wrote: The standard Gaussian blur doesn't look great on the final render.
Worth to mention that the texture-level filtering ≠ Render Kernel Pixel Filtering, as I've seen some users mistaken one (former) for the other, likely not you.
- Andreas_Resch
- Posts: 319
- Joined: Sat Jul 28, 2018 6:29 am
In one of my recent render tests I also saw that some textures were a lot more blurry in Octane than in the same rendering done in Cycles. Even when setting the Octane pixel filter to 1, the textures were quite a bit more blurry in Octane. In product shots where you have small text on labels, this can make a difference sometimes.
Here's a comparison between Cycles and Octane. Pixel filter for Octane was at 1.05.
Here's a comparison between Cycles and Octane. Pixel filter for Octane was at 1.05.
There has been discussions for more filtering options at texture level.
Meanwhile, an OSL node can alleviate that.
Meanwhile, an OSL node can alleviate that.
- Andreas_Resch
- Posts: 319
- Joined: Sat Jul 28, 2018 6:29 am
Is there an OSL version that works with Blender as well? Those seem to be C4D files.
OSL is "[nearly] 3D DCC agnostic/universal", and rather integrated with the renderer than host software.
For instance, here's the "OSL Implementation In OctaneRender®" page (Octane Core, theoretically all plugins included).
It usually goes along the line of "testing it first, finding what works and doesn't, adjusting/adapting to the supported renderer's OSL implementation".
For instance, here's the "OSL Implementation In OctaneRender®" page (Octane Core, theoretically all plugins included).
It usually goes along the line of "testing it first, finding what works and doesn't, adjusting/adapting to the supported renderer's OSL implementation".
- Andreas_Resch
- Posts: 319
- Joined: Sat Jul 28, 2018 6:29 am
Cool. So which version of those in the previous linked thread should I use in Blender? Will a C4LIB file work somehow? The shader in the embedded code window throws an error.