The DOs and DON'Ts of Filter Construction

Quote
onyXMaster wrote: Sphinx, you're correct, the Height input in both root component (in surface filter mode) and Refraction component takes three input samples for one output sample.

So if the incoming coordinate to a refraction is (1, 1), what are the three coordinates it will pass to its heightmap source?

Quote
Crapadilla wrote: And once we've gotten to the bottom of all this sample cache stuff, it should really be made into a dedicated, heavily illustrated wiki article officially licensed by Vlad, or even better: end up in the help file, where it belongs! I would certainly read it often, because now I am more confused than ever about sample caching, and I thought I had it so well nailed down!

Yeah, Along with a good explanation of the coordinate and sample flows.. i.e. coordinates are passed from result (top node) to end components(leaf nodes), and samples are returned from leaf to top node. It seems like this is not something you'd intuitively think when looking at - and working with the components and connections.. The sample cache functionality is easily explained when this flow is understood: "When a component receives a coordinate, it checks if it is equal to the last rendered sample coordinate. If that is the case, it returns a cached sample"

Btw. with regards to the build in sample cache stuff, think of the blur buffering snippet again: when a blur receives a coordinate, it must fetch alot of samples from its source (actually a bunch of sample tiles), but the optimizations of the blur ensure that any future sample requests within these already rendered tiles are not rendered again from the blur source - so what you have here is not just a single sample cache, but a sample tile cache - this is why the snippet is so fast in buffered mode.

Quote
Sphinx. wrote: Also I'm really not sure about the elevation gradient - could be that the upper row of the gradient input is rasterized somehow..

No, definitely not -- we don't rasterize anything unless there's a strong need. We always try to keep things procedural. Rasterizing involves bitmaps. Bitmaps take memory. This becomes very cumbersome when rendering big images, say, 65000x65000 pixels.

The only cases where we rasterize stuff are bitmap-based components (see Help).

I just noticed something.
As noted in the wiki: when using noise and alike it is best to keep your details <= distortion. But when you add a component like Perlin noise or Noise distortion the default values do not match that idea.

Default Perlin noise: roughness 20, details 100
Default Noise distiortion: roughness 10, details 100
Default worleys: roughness 20, details 40

It might be a good to fix that, so people don't get wrong ideas.

Quote
Sphinx. wrote: and thus only would need to store a row and not a complete map

Any such storage would convert the procedural signal into an inherently discrete representation with a lower resolution, which in many cases can kill the image quality. Try to run a Checker through a Noise Distortion, then stick a buffer between the Checker and distorter (as you do here) and compare the results.

Quote
Sphinx. wrote: [...] and I think its worth mentioning on the wiki (but as stated several times, I don't want to do that, if you don't officially think it should be promoted).

I suppose it is similar to the case of the "Channels" technique: not applicable at all times but generally a neat trick to know. You could also turn it into a separate article.

Quote
Crapadilla wrote: I suppose it is similar to the case of the "Channels" technique: not applicable at all times but generally a neat trick to know. You could also turn it into a separate article.

Yeah, however the channel combining trick don't suffer from the same essential "problems" (it do not limit sampling to integer coordinate precision, like the blur do because of the rasterization - well interpolation is actually performed, but thats really not changing the fact). Also I think the channel trick is more than an optimization: it is a very nice way to unite similar processing steps under same roof, it can reduce components used and thus make the filter graph easier to overview and tweak.

Quote
Kraellin wrote: ..so, here's a way to do it such that the two arent being used at the same time: just plug both the blur and sharpen into a switch and use a checkbox. this way you only get one or the other and not both like you can get when you randomize with it the other way.

Or utilize the principles described in One Blur does it all... and make something like the attached filter, which uses only one high pass

Sharpen _-_ Blur.ffxml

but that's a cool filter. who came up with the snippet there of using the two linears, a blend and a tone curve? that's the same sort of thing CF&M just used in his perspective frame he just posted in the user gallery forum. looks to be VERY useful!

well, i thank you. that could turn out to be one very useful snippet!

Note that the jagged edges in the buffered version can be remedied by turning on anti-aliasing for sources of bitmap-based components (Tools > Options > Rendering). However, this can considerably slow the rendering down, thus negating the benefits of buffering.

Here's the filter:

Buffering Artifacts.ffxml

thanks, CF

I've added two new entries to the article, and expanded on another entry...

High-Pass Vs. Threshold (NEW) [inspired by Carl ]
Reverse-Engineering Noise Distortion (NEW)
Getting The Most Out Of Your Components (expanded)

Nice one, Sphinx! Looks like you did it.

You should probably make a snippet out of that...

You do realize that trying to follow you guys is making my brain hurt again

Shamefully I've not noticed this thread - its excellent I don't know whether being the poster boy for don'ts, Crapadilla wrote:
High-Pass Vs. Threshold (NEW) [inspired by Carl] is so great LOL the wiki will be a big help

Quote
Crapadilla wrote: Yes, this needs some reliable way of getting more exposure

Vlad, this thread has great value for people like me, could it be stickied please, as I had missed it and maybe I'm not alone

Vlad?

Added a new section on Seamless Tiling. As usual, suggestions and critique are welcome!

Crapadilla: You've done this community a really great service with these wiki updates. I personally never wanted to even dive into filtermaking but after reading that really helpful section felt inspired to experiment.

Props +1

+3

Quote
Crapadilla wrote: I'm glad to read that the articles are being appreciated (even though I may be stepping on a few stickers ermmm... neckties)!

LOL..... Don't get me wrong.....I personally wouldn't submit one like that because I don't like the idea of having to tell users not to use the size control.....thus my efforts to have a "disconnect/fixed" global size option on components that are currently hardwired to it.....

Quote
Crapadilla wrote: my secret plans for utter world errr... filter library domination

Can I be the villain trying to foil your plan with poorly constructed filters??? ..... LOL....

***swooooosh.....Razor of Occam lops off StevieJ's head***

I'm sure Vlad and the FF team would agree..... ..... LOL.....