W3C home > Mailing lists > Public > public-fx@w3.org > July to September 2012

Re: Perlin and simplex noise

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 31 Aug 2012 10:05:25 -0700
Message-ID: <CAAWBYDCoWtJZZ6tx=QqPqTF+JmzMZSK-=uZkU+z8RT84W+1-xQ@mail.gmail.com>
To: Erik Dahlstrom <ed@opera.com>
Cc: www-svg@w3.org, "public-fx@w3.org" <public-fx@w3.org>
On Fri, Aug 31, 2012 at 1:57 AM, Erik Dahlstrom <ed@opera.com> wrote:
> On Thu, 30 Aug 2012 18:51:32 +0200, David Dailey <ddailey@zoominternet.net>
> wrote:
>> I know you all found the concepts of declarative randomness a bit
>> distasteful (we're giving a talk on it at the conference in Switzerland,
>> soon) and given the history of society's reaction to randomness, one can
>> perhaps understand if not appreciate that reaction.
>> However, I wondered if thought has been given to Simplex noise in addition
>> to Perlin noise[1]?
> Some thought has gone into that[2], but there's no concrete proposal for it
> yet. It's listed as issue 15 in the filter draft [3].
> I would like to see a more hardware friendly noise algorithm in the spec,
> e.g simplex noise (or something with the same characteristics), but if we
> want existing content to look the same we can't just switch the algorithm in
> feTurbulence since the algorithm in the spec and the simplex algorithm
> generate slightly different results. But, it may well be that the
> differences are small enough that it would be acceptable, anyhow I think
> that needs to be investigated.
> 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.  ^_^

(While we're at it, though, we should pay attention to how it would be
possible to do declarative randomness in properties.  Marrying a
stateful RNG with a nominally stateless language is hard. :/ )

Received on Friday, 31 August 2012 17:06:17 UTC

This archive was generated by hypermail 2.3.1 : Monday, 22 June 2015 03:33:48 UTC