I want a benchmark.

I just had another filter rejected. For what appears to be an umbrella rejection reason. "filter renders too slow..." Ok... maybe. The filter in question was one I spent many hours on to donate to the 3D community... it takes a single quad image containing already existing (outside FF) 3D maps and plugs each one into the appropriate channel so that one could use FF to render your library of 3D maps. Also, the filter could easily be modified to work with any four bitmap inputs, hand drawn, photographic, whatever.

This filter I built on an anemic Dell laptop, and when I test rendered it prior to submission it took 20 minutes... that's correct. 20 minutes. This means on any normal workstation class it would render the default image in under 5 minutes. Seriously! My 100 year old tugboat filter is perhaps 10 times more complex and takes HOURS to render... so, why was that one and so many others of mine accepted, but this wasn't... ???

So, if as suggested I go looking for 'fixes' to make it more streamlined and faster rendering, will it then be accepted? If I get the render time down to 2 minutes on my Quad core Windows workstation... would that be fast enough?

Can I please get some definitive answer about what qualifies as 'fast enough' for filters? Faced with the seemingly incongruous results submitting filters, I'm a little leery about sinking another 10 hours of development time into community filters if it's always going to be a crap-shoot as to if it will be acceptable.

What would be really helpful is for FF to post a filter for developers. One that you considered to be as complex and slow rendering as you would be willing to accept as a submission. Developers could download this benchmark filter and render it. Everyone will have a different render time of course, but it doesn't matter, since the rule would be simple. If your own filter renders faster, all is good... if it takes longer it will be rejected. If you change your 'bar' to allow more complex filter, you can update the benchmark filter.

Ok. Vent over.

Ian

if i'm remembering correctly, the criteria was a filter had to render within 15 minutes on a single core, 1 ghz machine.

also, altruistic donations of filters can also be done through the forums here. just upload it like you would an image. the .ffxml filetype is recognized in the forums.

Quote
GMM Wrote:We're unable to provide a benchmark filter that would take exactly 15 minutes. However, this one is one of the toughest (though really nice), we don't recommend to submit filters slower than Clay Sticks.

LOL, Ironically the most optimization obsessed guy has the slowest filter - It uses most of the optimization tricks I know, and I barely passed the submission.. Perhaps I should take another look at it

Here's the filter in question. let me know if there is some sort of glaring slowdown if anyone finds such a thing? thanks.

also, It just popped into my head... that indeed FF may have cracked down a bit on long rendering filters. In the beginning it may have been that they just wanted decent looking filters, and it's likely they wouldn't accept similar filters now.. not ones like my early monsters.

Quick3DVisualizor.ffxml

Quote
IONclad wrote: umm...GMM "genetically modified moderator"?

Generic Moderator Module

Quote
IONclad wrote: but is there certain functionality we should not try to duplicate with filters? Is it policy

We don't have any policy of such kind. However some filters may become unneeded as we add new functionality in future versions.

Quote
IONclad wrote: using v1. I wonder if this is in any way connected to the speed issue.

IIRC, there weren't any significant speed changes in v2. The only exception would be v1 filters that use workarounds to make rhombs, circles, spirals and other shapes — v2 has separate fast components for that.

IONClad, I'm taking a look at your filter now - Do you have an example image for use with this filter?