Wondering what components get cached.

For example I know Blur does. What about complex curves and curve ops? etc.

Thanks.

And how does this work for Switch components? Are all the incoming streams cached, or only the one currently active?

Hey, that gives me an idea:

What if we had a 'render/sample diagnostics' mode that displayed over each component the number of 'samples per pixel' that are taken there? For example, with 5 samples of anti-aliasing, most components would display '5' (samples per pixel), the refraction component and all of its upstream nodes or the component tree fed into the height input would display 5x3 or 15 (samples per pixel).

This way, users could quickly diagnose their filters for rendering bottle-necks visually by looking for component combinations that force excessive evaluation of upstream nodes (like a refraction fed into a high-pass fed into the height input of the result node, which would be 5x3x3 = 45 samples?).

Additionally, the components could be overlaid with shades of green (fast) to red (slow) according to how many times they are sampled. Worley-noises with custom profile curves would also be interesting in this regard, as the sample counts are likely to 'explode' here for more complex trees.

Let's disregard the factual correctness of my sample count guesses for a second. They're just there to illustrate my point.

What do you think about the idea of having this 'sample diagnostics'? I'm thinking of displaying this number of samples over the preview thumbnail of each component. Even if things are more complex as you say - as with the Edge Only AA - we can arrive at 'generic' samples-taken-per-pixel values for each component, like '1|5' in the first case above (meaning 1 sample where no edge is and 5 at an edge).

Quote
Crapadilla wrote: as with the Edge Only AA - we can arrive at 'generic' samples-taken-per-pixel values for each component, like '1|5' in the first case above (meaning 1 sample where no edge is and 5 at an edge).

Good suggestion.

The 'sample diagnostics' could be a great visual learning tool for understanding FF's sample-based architecture. Granted, one would have to absorb lots of technical info on 'samples' first in order to make anything of it, but then again diagnostics has always been rather technical in nature. It would certainly be an advanced area of the program.

The 'sample diagnostics' would illustrate the effect that AA has on render-times. Just turn up the AA samples and see the whole filter tree update its sample counts.

Furthermore, it would illuminate why certain components and component combinations lead to slow filters, and the user could visually detect rendering bottle-necks by looking at where exactly in the filter tree the samples counts multiply.

Since the sample display would dynamically update with every change in the component tree or a component's parameters (say Noise Detail), the user could experiment with different component parameters/setups/sequences and directly gauge the effect his experiments have on the sample counts. This enables the user to optimize a filter on-the-fly while building it.

Quote
and the user could visually detect rendering bottle-necks by looking at where exactly in the filter tree the samples counts multiply.

i like the general idea here, a speed indicator. and whereas i dont make my filters on a speed priority basis, i nonetheless sometimes wonder how i can speed them up and where is the bottleneck.

vlad, this wouldnt even have to be that precise, though dilla may disageee here. but for me, even a general indicator would help. even if the thing was nothing more than a calculator of speed in rendering AT that component, it would be worthy, providing the calculating itself didnt add a lot of additional time to the rendering.

Quote
Crapadilla wrote: would it be possible to arrive at an average 'calculation cost' value for all the samples of a given component?

Blur with variable radius.
Perlin/Worley noises with different Roughness and Details.

For the above examples the variations in the calculation cost are pretty dramatic, so the average doesn't make much sense. There is a Russian joke about this kind of averages:

"The current average body temperature across all patients in our clinic is 36.6 degrees".

(36.6 degrees is the normal body temperature on the Celsius scale, don't know how much would that be in Fahrenheit).

Well, I'd be totally happy with a simple number-of-samples display that disregards sample calculation costs. That would already help a lot in getting 'under the hood'...

Well, the highest sample count measured on that component should be displayed, or - alternatively - a range of sample counts.