Re: Perlin and simplex noise

On Sep 3, 2012, at 1:03 AM, Erik Dahlstrom <ed@opera.com> wrote:

> On Fri, 31 Aug 2012 22:49:24 +0200, David Sheets <kosmo.zb@gmail.com>  
> wrote:
> 
>> On Fri, Aug 31, 2012 at 10:05 AM, Tab Atkins Jr. <jackalmage@gmail.com>  
>> wrote:
>>> On Fri, Aug 31, 2012 at 1:57 AM, Erik Dahlstrom <ed@opera.com> wrote:
> ...
>>>> What do other people think? The computational cost of the noise  
>>>> algorithm in
>>>> SVG 1.1 is fairly high, and that does limit what you can use it for in
>>>> practice. If we chose to go for a new noise algorithm I would also  
>>>> like to
>>>> be able to animate the noise continously (I think this means we'd need  
>>>> the
>>>> 3d version of the algorithm). That is, I'd like to simulate say fire or
>>>> smoke, and link the z dimension in the noise algorithm to the time  
>>>> dimension
>>>> so that the animation is continous (without strange gaps and without it
>>>> looking like the result is scrolled along either or both of the x and
>>>> y-axis).
>>> 
>>> I *strongly* suggest that we make this decision in concert with
>>> relevant browser devs, so we can get something that's legitimately
>>> implementable by them.  I definitely support a decent-quality, fast
>>> noise algorithm, because I desperately want noise usable in CSS.  ^_^
>> 
>> Why not through custom shaders?
>> <https://github.com/ashima/webgl-noise>
>> <https://github.com/ashima/webgl-noise/wiki>
>> 
>> The above is compatible with WebGL (GLSL ES 1.0) and is purely
>> functional (no uniforms, arrays, textures, external state, &c).
>> Classic Perlin and simplex noise are provided in 2, 3, and 4
>> dimensions under the MIT (expat) license.
> 
> By not adding a CSS shorthand and a corresponding filter primitive element  
> we're raising the bar for usage (and requiring every author that wants to  
> use noise generators to copy these shaders), but you're right that it's  
> possible to implement this as custom shaders. It's just nicer if this is  
> part of the required functionality, as is already the case with the  
> classical perlin noise algorithm in SVG 1.1.
Actually, what is the problem of copy pasting shaders or use generators? I think this is more helpful then introducing yet another filter primitive. We already have enough in my eyes. Introducing more makes it harder to maintain those - from the spec and the implementor side. I have nothing against regular used short hands, but another noise filter does not really fit into this concept in my eyes.

Greetings,
Dirk


> 
> 
> -- 
> Erik Dahlstrom, Core Technology Developer, Opera Software
> Co-Chair, W3C SVG Working Group
> Personal blog: http://my.opera.com/macdev_ed
>

Received on Monday, 3 September 2012 14:51:56 UTC