- From: David Dailey <ddailey@zoominternet.net>
- Date: Tue, 12 Nov 2013 22:29:26 -0500
- To: "'Michael Mullany'" <michael@sencha.com>, "'Erik Dahlstrom'" <ed@opera.com>
- Cc: "'www-svg'" <www-svg@w3.org>, <public-fx@w3.org>
- Message-ID: <004601cee020$8e61ea40$ab25bec0$@net>
Hi Michael, Cool! It is a very nice review article done by people who know a lot about the subject, which I don’t. I know there are folks on the WG who are pretty knowledgeable, though. I guess the thing to do is to convince folks that it is worth the time and energy needed to research the subject and spec things out. Input from the 3D/GPU community might be helpful too since the GPU folks have possibly already implemented some of these methods in hardware. I’d be willing to invest a bit of time making inquiry about the hardware implementation issue, if there were sufficient interest. Of course, it’s entirely possible that my thoughts are naïve and that 3D/GPU implementations might be only relevant to the 3D world and have nothing to do with SVG, but a cursory glance at the article you mentioned suggests that there might be a good degree of overlap. One issue that comes to mind as I think about it is the following: the folks at Pixar who developed all the wonderful 3D stuff for Toy Story and beyond, were a bit dismayed to find that they had made obsolete a class of highly professional and talented 2D illustrators at Disney. Sometimes, the 2D “simulation” of 3D is actually preferable, from an artistic, cognitive and educational perspective to the full-blown 3D approach to the same topic. Not that the SVG WG needs to be reminded of this, of course, but I can imagine readers of the list who might forget the value of effective planar communication on things that are generally 2D display devices. Is using 3D noise to make a tornado, really better, for example, than displaying the vortices of vectors that comprise the physics of the tornado? One looks more realistic (in a European Renaissance – post development of the lens – perceptual sort of sense), the other might BE more realistic (in a gongbi / cognitive sort of sense). Cheers David From: Michael Mullany [mailto:michael@sencha.com] Sent: Tuesday, November 12, 2013 6:37 PM To: David Dailey; Erik Dahlstrom Cc: www-svg; public-fx@w3.org Subject: Re: Gabor noise [was RE: Perlin and simplex noise] I am not a graphics engineer, so this may be review for folks on this list, but I found this 2010 survey of procedural noise generation algorithms from to be helpful in understanding state of the art and trade offs among various noise functions. State of the Art in Procedural Noise Functions A. Lagae1,2 S. Lefebvre2,3 R. Cook4 T. DeRose4 G. Drettakis2 D.S. Ebert5 J.P. Lewis6 K. Perlin7 M. Zwicker8 1Katholieke Universiteit Leuven 2REVES/INRIA Sophia-Antipolis 3ALICE/INRIA Nancy Grand-Est / Loria 4Pixar Animation Studios 5Purdue University 6Weta Digital 7New York University 8University of Bern http://www-sop.inria.fr/reves/Basilic/2010/LLCDDELPZ10/LLCDDELPZ10STARPNF.pd f On Tue, Nov 12, 2013 at 3:48 AM, David Dailey <ddailey@zoominternet.net> wrote: Hi folks, Nikos A., from Canon, gave a recent and very well-documented talk at The Graphical Web (some of you may remember it as SVG Open?) on diffusion curves [1]. I found the rationale for their inclusion in a future spec quite compelling, btw, but that's a different issue. He also mentioned something quite cool: Gabor noise (related to Gabor filters). [2] I'm not sure of the computational complexity of it relative to Perlin noise, but at the end of the paper [2] one can see a large variety of very interesting textural effects that are simply not expressible with feTurbulence at present, short of, for example, overlaying two or more feTurbulences with different frequencies, octaves and directionality, and thence using an feDisplacement to combine them. Likely, this strategy would be computationally more intense than unpacking the rather dense-looking math of Gabor filters. But Gabor noise appears to be scalable, like feTurbulence, and, most importantly, it adds a rich set of textures that would enable more naturalistic approximations to the sorts of things humans might want to draw. Combine Diffusion curves with Gabor noise, and I suspect you'd go a very long way toward enabling very economical approximations to many real world images (hence, phenomenal image compression) and while image analysis is not, per se, a part of the SVG WG's purview, it is, nonetheless, the ancestor of zillions of use cases for SVG. And, of course, there is always the ability to draw pretty pictures with it! Regards David [1] I gather he's been working with Cyril, and mentions this paper. Apologies, if I misunderstood the relation between this work. http://biblio.telecom-paristech.fr/cgi-bin/download.cgi?id=14268 [2] http://peterwonka.net/Publications/pdfs/2011.EG.Jeschke.DiffusionCurveFittin g.AdditionalMaterial.pdf -----Original Message----- From: Erik Dahlstrom [mailto:ed@opera.com] Sent: Friday, August 31, 2012 4:58 AM To: www-svg@w3.org Cc: public-fx@w3.org Subject: Re: Perlin and simplex noise 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). [1] http://en.wikipedia.org/wiki/Simplex_noise [2] http://www.w3.org/2009/02/05-svg-minutes.html#item01 [3] https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#feTurbulenceElem ent -- Erik Dahlstrom, Core Technology Developer, Opera Software Co-Chair, W3C SVG Working Group Personal blog: http://my.opera.com/macdev_ed -- www.sencha.com "Amazing Apps with Web Technologies"
Received on Wednesday, 13 November 2013 03:30:01 UTC