- From: David Dailey <ddailey@zoominternet.net>
- Date: Mon, 3 Sep 2012 11:19:13 -0400
- To: "'Erik Dahlstrom'" <ed@opera.com>, <www-svg@w3.org>
- Cc: <public-fx@w3.org>
Erik Dahstrom wrote: >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 agree -- such would be very cool, and potentially speedier (though I gather that Simplex's speedup emanates mainly at higher octaves). I am quite familiar with the strange gaps and scrolling effects. In order to make scrolling smooth, many of my examples have relied on an old technique borrowed from the Adobe SVG Zone: the area contained in the turbulence is moved in one direction while a group containing it, moves in the opposite direction. http://cs.sru.edu/~ddailey/svg/feTurbulence19.svg shows a simple example of what I mean. It works in FF, Opera and ASV, WebKit doesn't seem to handle turbulence yet, and IE9 doesn't like animation. Other examples can be seen at http://cs.sru.edu/~ddailey/svg/Turbulence.html But one might like to randomize the seed of the turbulence from invocation to invocation. Let me explain, and explain the oddities I've seen, enroute: First look at the example at http://cs.sru.edu/~ddailey/svg/embedpatterns.html It behaves differently in all five browsers (maybe six, though I can't tell for sure about IE/ASV vs IE9 since my IE seems to flip to ASV when I used embeds) Firefox does not always re-randomize the pattern from embed to embed; Opera never does; Safari always does but doesn’t handle the HSL color space (I think), Chrome always does, but doesn’t replicate; IE seems to ignore the whole business. I think that whenever an author finds a new example that works differently in all five browsers, they should get a reward: let him or her rewrite the relevant sections of the spec. In this case, I would prefer a combination of Safari and Firefox: re-randomize the instance for each invocation (not just for some) but also go ahead and handle HSL values. (The Safari monochrome shaping is sort of fun though) Who knows what new elements, attributes and microsyntaxes some people might add if given the chance?</kidding> Anyhow the relevance to turbulence is that users of turbulence may like to be able to randomize the seeds, so the turbulence is not always so darn predictable from instance to instance. Accordingly, I did these things: http://cs.sru.edu/~ddailey/svg/embedturb.html and http://cs.sru.edu/~ddailey/svg/embedturbRand.html Note how in the first one (not using <random>) each of the six is the same. However, in the second, as seen in Firefox which does most what I want it to, the pattern changes from embed to embed. Opera suffers from the same problem above, as does ASV. I played a bit with controlling <random>'s seed of the values of the seed attribute of the feTurbulence (so that all six turbulences would be the same from reload to reload, despite differences from embed to embed, but didn't get anything working right and can't honestly tell if it's our problem or the browsers). Controlling seeds can be seen at http://cs.sru.edu/~ddailey/svg/seeds.svg Notice how the uniform and normal distributions at left are the same from top to bottom. The ones at right are not. All are random, but the ones at left are seeded so that they will always give the same diagram from invocation to invocation. This was an oft-heard requirement as we were collecting use cases from the community. Cheers David
Received on Monday, 3 September 2012 15:19:54 UTC