Re: Perlin and simplex noise

On Sep 4, 2012, at 8:41 AM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:

> On Mon, Sep 3, 2012 at 1:11 PM, Dirk Schulze <dschulze@adobe.com> wrote:
>>> The type of noise I'm interested in is sufficient as a plain image.
>>> It would also be useful as a filter function, sure, but I just want to
>>> add a noise() function to the <image> type, and I'll rely on SVG
>>> making a good decision about the type of algorithm to do it with.
>>> 
>> This is already specified by Filter Effects[1].
> 
> Yes, if you already have an <feTurbulence> filter set up.

That is correct. You would reference a SVG Filter.
> 
> Actually, though, I don't really understand how that works.
> <feTurbulence> is one of the silly filter elements that's not a filter
> at all, but actually just a paint server (created, if I recall earlier
> explanations correctly, because nobody thought of just letting filters
> accept paint servers directly as inputs, so you had to choose, and
> turbulence seemed more useful as a filter input than a paint server).
> This means it doesn't accept any inputs.  Do you just have to provide
> a dummy image that then gets completely ignored and replaced with the
> turbulence?
If you rely on the referenced syntax, then yes. You would need to provide a dummy image, which is stupid. However, this syntax should change and take an optional image input instead - because of the primitives that create but don't take inputs like feFlood, feTurbulence and eventually custom().

> 
> If so, then that's all the more reason to have a shorthand function
> for this that's just an <image> type, not a filter at all.  
No, it would be redundant which should not be the desired solution. If you take a look at the usage of feTurbulence, you'll see that most examples combine feTurbulence with other primitives like feComposite, feMerge, feColorMatrix and feBlur to create clouds, fire or even brushed metal. So like you said turbulence makes most sense in a filter chain. That would be the case for any generic noise algorithm.

> Like I
> said, I'll just wait for SVG to settle on an algorithm, then I'll
> reference it and define a new function in Image Values or something.
> 
Filter Effects don't live in SVG anymore but have their own module with the same name.

I am absolutely not opposed in moving filter() to CSS images, since it belongs to this specification anyway. But duplicating a feature that is mostly used in combination with filters doesn't sound like the best idea. Instead we should improve the filter() syntax and clarify if we want to have a noise() primitive function (maybe on top of a modified feTurbulence primitive or a new feNoise primitive).

I would like to hear the proposal on The Graphical Web conference before coming to a final conclusion.

To your paint server proposal: we discussed taking <image> as a paint server for SVG shapes during the last WG call. We thought that there are some things to clarify first before we do that and go at least with <gradient> from CSS3 images (or CSS4 images if it is ready before SVG2). But this would allow taking filter() (with turbulence) as paint server.

Greetings,
Dirk

> ~TJ

Received on Tuesday, 4 September 2012 16:13:44 UTC