Wiki

Because Crapadilla added another Wiki page I took another critical look at the Wiki's structure. But before doing anything drastic I thought I'd ask your opinions. Right now the Wiki looks like a loose collection of pages. I suggest the following:

The heading 'Articles' is unnecessary: it's a bit 'Lorem ipsum'. I say loose it.

'Most Asked Support Questions' is important and should still be at the top of the page.

The pages 'Optimizing Filters for speed', 'Snippet Guide', 'The DOs and DON'Ts of Filter Construction' and 'Hints, tips, and tricks' could be filed under 'Filter creation'. And maybe these pages should be ordered by newbieness.

The pages 'Noise Lab' and 'Kaleidoscopes Unveiled' could be gathered under a heading 'Components' since these topics are about specific (types of) components.

That leaves us with 'Feature Wishlist' and 'Requested Articles' that could both be considered 'Special pages' (although special pages sounds a bit... I don't know.. suggestions?). The requested article 'Best Practices' can now be scratched since 'Do's and Don'ts' is here now.
'Requested Articles' was already in there and 'Feature wishlist' should be there because it is not so much a reference page for Filter Forge users (although hopefully it is for the Filter Forge team).
Who assembled the 'Feature wishlist'... oh it says Crapadilla at the bottom . At the bottom it also says the last update is 21 October 2007. But the last post reference (if the numbers are chronological) is April 11, 2007. Does this mean later posts are not in here? Maybe it's handy to start with a date in this page, so anyone who wants to archive the rest of the Feature Wishlist forum has a post date to look for.

Maybe it's also better to not have an entire heading 'Articles under construction' but to put them in the right spot right away and put '(under construction)' immediately after the title.

----I have a really obvious/dumb *bit* to add to any filter making intro/advice column/wikipage. Perlin Noise can be fast, and using it instead of ProfGrads makes your texture Pixel/size independent (ie = it doesn't repeat and screw up like if you use ProfGrads for black/white/gray or whatever coloration/offset/sizing), but please, turn the *Details* setting down to match the *Roughness* setting if it isn't stretched, otherwise, that's just 100% wasted render time eh. That is the single most common mistake I see, in like 3/4 of filters I look inside of, really simple, and can save from 1%-15% or 20% render time, and at an average of around 3%-5% per instance even in simpler filters, it can add up fast if you are using 2-4 of them in your filter.
----Kraelinn has said this before, and it bears repeating, those of us even 1/10th up the food chain of FF knowledge will make a faster version of your filter to use, and you won't get "usage" points for it after we "fix" it and resave it. We don't need to do that but it's just instinctive, so if people know and can "efficientize" their filters from the beginning (or at least have been told how to, and have that choice of knowledge), then we can just use the stock versions and they get the usage points like they should, and all's fair in technology and progress etc.

jffe