I can see the power of FSA, but unfortunately it’s TOO good for my specific app. I’m compositing my final picture, of which one layer is stars using the built-in star generator. Because my target app is low-rez, I need to keep the stars to a maximum sharpness, just a full pixel or two at max brightness. Unfortunately, FSA blurs out that layer badly.
Is there a way to control which layers are oversampled, so that I can composite oversampled layers with my sky layer?
I’m also little confused about the pipeline. How does ‘Shift-R’ in the compositor relate to the ‘FSA’ button in the render panel? If the ‘FSA’ button is off, do I still have some kind of manual control of the layers? Perhaps the ‘FSA’ button only controls the final comopositing operation?When does the ‘OSA’ button (in the materials panel) have relevance with respect to the other over-sampling settings, particularly FSA.
If somebody knows a pipeline diagram, that would be cool.
thanks
If you want stars @ 2 pixels max then you probably need to render these without FSA OR OSA, render the rest of the scene with FSA then composite the two with Z Combine (if the stars are mesh objects) or Alpha Over (if you are using the standard sky’s stars) in another scene or .blend file.
I’ve tried playing with the FullOSA button in the materials buttons and can’t see any difference when using it but that could be because I don’t understand it’s application.
Shift+R reads back all full sample layers whereas R will only read back the first sample for each render layer (check your temp file directory and you can see each FSA sample for each render layer rendered as a numericallly sequenced multilayer file). FSA also causes the sample filter type (Gause, Mitch, etc…) to function as a post render operation ((they also seem to have an inverse function with FSA, i.e. Gause is the most SHARP filter with FSA but is the most blurry filter with OSA)) whereas these filters are part of the render process itself when using OSA and cannot be changed in post as it can with FSA via SHIFT+R.
FSA release log:
Full Sample Anti-aliasing
When the Blender render pipeline was redesigned - for Elephants Dream in 2006 - one of the unresolved specifications was to tackle the artefacts you get in anti-aliased polygon edges when you use high dynamic range color (colors beyond the 0.0-1.0 visible range), or when you do color correction or remapping. Not to mention that while compositing, you actually want to get the same quality anti-aliasing for zbuffers, id masks, etc.
Analyzing this problem resulted in only one possible quality solution: a composite should never happen on anti-aliased images, but instead be done on all raw samples as they come from the renderer, which then as a last step maps it all to the visible 0-1 range, and then combines the samples to an anti-aliased result.
In other programs this is being achieved by just rendering 2 or 4 times larger, do the compositing and then scale it down. In Blender we use the more advanced ‘distributed jittered sampling’, which actually already renders 8 complete images (for “OSA 8”). It’s just a matter of saving all those images on disk, then after render read it back, and do the composite.
Or to summarize, this is the FSA pipeline:
Render -> save all samples -> composite -> map to visible range -> filter-combine samples
Whilst previously OSA did:
Render -> filter-combine samples -> composite -> map to visible range
The key benefits of FSA
- Dynamic range renders
When you use lamps or textures that have colors beyond the standard 0-1 range, you can use the compositor to adjust this and map to a visible range. Only after all compositing and remapping, the anti-aliased filtering and sample merging happens.
Even without compositing, FSA will in this case benefit a rendering as well. - Solve AA issues caused by solid - ztransp - strand combining
Blender renders solid, ztransp and strands in seperate ‘layers’, combining it with alpha-over functions. By anti-aliasing such layers first, and then combining them, you can get artefacts (looks as if the background peeks through the anti-aliasing). FSA efficiently solves this. - Allow color/contrast/brightness mapping.
Whatever you do in a composite, even make it 2 color black & white, by having these operations done on the raw samples, the end result will always look correctly anti-aliased. - Use passes with full anti-aliasing
Passes like zbuffers, id-masks, motion vectors, normals… these don’t anti-alias well, and work much better when you can apply them directly on the samples before merging it all into the final image.Memory usage and overhead
FSA makes use of Blender’s efficient tile-based pipeline, so you won’t need much more memory for renders to use it. There’s a couple of considerations to make though.
- For each tile rendered, FSA allocates layer/pass buffers for each sample.
Example: for a 2k render, 8 samples, using 4 x 4 parts, it means that per tile 8 x 128k pixels have to be stored. - Therefore it’s a good convention to make tiles smaller, especially when rendering in threads (each thread allocates for each tile).
- However, after a tile render is finished, it saves the entire result to disk, using the ‘save buffers’ convention. So by rendering tiles smaller, you can compensate for the FSA overhead quite efficiently.
- The render time overhead for FSA is a constant. Only the overhead of allocation, writing in buffers, and saving them is added to the render times, disregarding scene complexity or render features.
- Compositing overhead is also a constant, but here the most time gets “lost”… since for each sample a full composite happens. We’ll be looking at smarter threading for compositing to overcome this.