The DOs and DON'Ts of Filter Construction

+1024 on the Perlin-into-Blur thing.

My only suggested improvement would be to type it in HUGE BLINKING RED LETTERS. Also, some irritating sound would be nice, something like the NAVY alarm

Dilla, that is excellent!!! Nice work!!!

Quote
Vladimir Golovin wrote: My only suggested improvement would be to type it in HUGE BLINKING RED LETTERS.

If anyone could assist in wiki markup editing to this end, I'd be grateful.

Quote
Crapadilla wrote: feel free to contribute, all ye who feel like contributing!

Are you sure you want me involved in this??? You might have to do alot of editting..... LOL....

I'm holding out for my first Editor's Pick before I go to the next level of contributing..... ......J/K LOL....

looks good - the channel trick is something I often use, helps alot not only to speed up the rendering, but also to keep the memory usage down (by limiting the number of components). For example if you are using bitmap based components to process grayscale sources, then you can process 3-4 sources seperately with one component (high pass ignores/bypasses alpha, so its only 3, RGB).

One thing.. in the stuff about Noise and Blur, it does look like a general statement - "never fed your noises to a blur" alike - but as I recently showed, it can speed up the rendering dramatically - specially when worleys are used on a height tree or get distributed out to many post processing branches that breaks with the single sample cache system (like offsets etc).

Ofcourse its a special case where the actual purpose not is smoothening, but rather buffering. But if the blur is there in first place to serve as buffer, and you later on figures that it actually looks good with a higher radius, well then you have a blur avail. at no expense since it already sits there for another purpose.. I wouldn't be so angry at those blurs (Just so you know.. I'm not opposing the motives here.. I fully agree on the overall point in it .. just adding in a little perspective here)

Ooooo. Thank you muchly. This will be lots of help.

Quote
Sphinx. wrote: One thing.. in the stuff about Noise and Blur, it does look like a general statement - "never fed your noises to a blur" alike - but as I recently showed, it can speed up the rendering dramatically - specially when worleys are used on a height tree or get distributed out to many post processing branches that breaks with the single sample cache system (like offsets etc).

Sphinx,

would you be willing to supply a short paragraph about this 'caching' behaviour to complement the perspective on blur components that I gave?

Quote
Sphinx. wrote: I wouldn't be so angry at those blurs Big grin (Just so you know.. I'm not opposing the motives here.. I fully agree on the overall point in it .. just adding in a little perspective here)

Actually I like blurs very much, and I use them often.

But! With blur components (and the other the bitmap-based ones) you have to know exactly WHERE and WHEN to use them, or they do more harm than good. Consequently, it is also very beneficial to know when and how you can do WITHOUT them.

one might also mention that blurs can be used with perlins in certain circumstances, like feeding blurred results INTO perlin noise or backgrounds, AND feeding blurred results into the perlin controls themselves. when you take into account how, in your noise lab, you utilize a number of the perlin control slots with other things, those controls often cant blur as you state in the do's and donts. so, a separate blur is sometimes necessary there, also... i think.

sorry, everyone pokes their two cents in AFTER someone makes some excellent points and tutorial helps. and mention shld be made of the ORIGINAL work you've done here, dilla. excellent stuff! so, forgive my mods/two cents, please.

Quote
Crapadilla wrote: would you be willing to supply a short paragraph about this 'caching' behaviour to complement the perspective on blur components that I gave?

Well, I would like to hear an "official" statement from Vlad about the buffering method, because it essentially opposes the procedural sampling concept (in that it forces a rasterization of the blur input, and thereby prevents further real subsampling) - I can understand why that might not be considered good practice, and if that is the conception, it should not be promoted. Then again it could just be a "novel" unrelated method for which all the blur/bitmap-based component lynching seen here and there don't apply

However I think the performance gain shown in the snippet argues for it self, and what I really should do is to add a section to the optimization section of the wiki, which we then could add a small note about in the Noise and Blur text (e.g. "This ofcourse don't apply for cases where blurs are used for buffering mechanisms" or something). By the way.. today I played with the method for buffering large curve "systems".. and it works very well there too, and the side effects are perhaps even less visible here (some of the curve components are quite heavy performancewise, specially when controlled by map inputs)

Quote
Sjeiti wrote: But I can't help feeling these gray height maps are wasting information. When you have a 0-255 range why not use it?

I'm not sure I agree here. FF does range checking and clamping just for about every component output (e.g. if output > 1 then output = 1), so there is a good reason to stay in "safe" mid area ranges to prevent things from getting overblown (resulting in flattened heightmap areas). Since the internal precision level is way higher than 8 bits per channel, it is not a problem at this point. The problem may arise when the user choose to export to an 8 bit per channel format, and that is, I think, the area where the guiding effort should be put. If users want to ensure full exploitation of a given target bit range, they should render the maps to a HDR format, and do the appropiate adjustments afterwards in relation to the target bit depth. It would also make a good feature if FF had an option to maximize heightmaps for a given bitdepth (most relevant 8 bit).

Well, personally, I prefer my height maps sprawling fully between the 0..1 range; call it an old 8-bit habit, if you will, but I think it feels somewhat clean and tidy this way. It is true though that - with the advent of HDR formats and floating point precision - this becomes somewhat less of an issue.

The threshold trick...
In the image I use levels to alter the stones... I've attached two threshold, one 100, one 0, black and white. When you adjust the the levels both thresholds should remain perfectly black and white. So in this image I've set the white point too far.

Damn Wiki... how do you apply breaks? <br/>

Quote
Sphinx. wrote: I wonder how this works when some of the outbound connections end up in offsets, refractions or noise distortions at some point, and others don't.

As I understand it, the sample cache for a component with multiple outbound connections is 'located' at its output, and each component with multiple outputs has its very own sample cache. The component gets rendered once and the result is then cached for other components to quickly 'look up' as needed.

Quote
Sphinx. wrote: Yeah, but doesn't that imply that the cache is invalid (and thus a new rendering is needed) if we have different offsets for the outbound connections?

I don't think so. If you connect a 'sample cached' perlin noise into three different offsets, the same sample cache is read by all three offsets, and SUBSEQUENTLY each offset calculates its own coordinate transformations using the cache as its source.

Quote
Sphinx. wrote: Hmm, but that implies that there is more than one cached sample

Yes, the way I understand it, each component that has multiple outbound connections maintains its own sample cache.

Continuing the example of the perlin and three offsets in my post above, if you were to connect one of those offsets to three other components in the filter tree, this offset component would in turn be enabled for sample caching and build its very own cache. I presume that any given component's sample cache remains valid until the components' source input or its parameter values change.

This means that depending on where the sample cached component is located in the filter tree, tweaking filter controls may force a whole cascade of caches to be rebuilt.

Quote
Sphinx. wrote: Seems like its a generic mechanism:

That is a question for Vlad or a programmer to answer. Sadly, there is not much info on FF's sample architecture available, so I'm just deducing how all this might work from the help file, Vlad's postings, etc. ...

I've added some general guidelines for contributors...

*** nudge nudge Sjeiti nudge ***

And it seems the article is growing!

Ok... consider my contribution guided

Maybe a good idea to put these general 'guidelines for contributors' on the main page. Add to it a link to the Wiki help.
A lot of the people on the fora might feel a bit reluctant to contribute to the Wiki (the FF Wiki was my first too) so some small pointers on how a Wiki works might convince them it's not all that hard.

Quote
Sjeiti wrote: Ok... consider my contribution guided

Great! And how about adding an image?

Quote
Sjeiti wrote: Maybe a good idea to put these general 'guidelines for contributors' on the main page. Add to it a link to the Wiki help.

Well, people have different opinions on how to design and structure things, so currently I feel it is sufficient if the originator of an article provides some guidelines.

as I see it roughness defines how the different octaves are mixed, and details control how many octaves are in play, but moreover it controls the contribution of the last added octave (given some sort of fractional range). What I'd like to know is how many octaves are in play when Details is = 100...

The article has been updated significantly...

Time to get some close-eye!

Quote
Sjeiti wrote: Maybe a good thing to refer to it from the wiki more often. For instance: each time the Perlin noise component is mentioned link to it.

Yes, good idea!