[HN Gopher] Noise Planets
___________________________________________________________________
Noise Planets
Author : atulvi
Score : 144 points
Date : 2021-01-10 09:26 UTC (13 hours ago)
(HTM) web link (avinayak.github.io)
(TXT) w3m dump (avinayak.github.io)
| mojuba wrote:
| The article uses original work of Tyler Hobbs [1] who apparently
| creates fascinating abstract art via programming.
|
| [1] https://twitter.com/tylerxhobbs
| exo-pla-net wrote:
| In his code after "and now we apply flow fields and try to move
| these points", the code is errant. It will produce errors if you
| try to run it.
|
| The variable "m" in draw() should be changed to "points".
|
| The variable "h" in draw() should be changed to "t".
| Sharlin wrote:
| _> I found this neat technique, to find random points in a circle
| where a random radius r and angle theta are chosen and the x,y
| points are obtained as x = centerX + r * cos(theta) and y =
| centerY + r * sin(theta)_
|
| This misses the crucial point of the technique described in the
| linked Stackoverflow answer: that _r_ cannot be a uniformly
| distributed random value if you want a uniform distribution of
| points in a circle. Rather you need r = R *
| sqrt(random())
|
| where R is the radius of the circle and random() gives a uniform
| distribution of random numbers between 0 and 1.
| layoutIfNeeded wrote:
| Or just do the classic rejection sampling technique:
| do { x = random(-R, R) y = random(-R, R)
| } while (x*x + y*y > R*R)
| Sharlin wrote:
| Well, that's what the author says they started with, before
| replacing it with the non-uniform algorithm.
| blueblisters wrote:
| That seems awfully inefficient.
| Sharlin wrote:
| In practice it's likely faster than the method that uses
| polar coordinates due to the latter's reliance on
| transcendental functions.
| enriquto wrote:
| Not really, about p/4 = 79% of the times you will have a
| single iteration. The expected number of iterations is the
| geometric series with this ratio, which is smaller than 2.
| monroewalker wrote:
| What keeps the lines from intersecting? Is that a property of
| "Perlin noise"?
| kmm wrote:
| The flowlines of any vector field cannot intersect, because
| that would mean the flowline has two tangent vectors at that
| point. For smooth vector fields, they cannot merge either, an
| intuition for that is perhaps that you could theoretically run
| the flow "in reverse", which would turn a merger into a split,
| and that's not possible.
| efsfwer wrote:
| The Perlin noise is generating a scalar field in this case
| (which gives the direction of the movement vector at each
| point). Here's a very similar bit of code that can be tweaked
| easily: https://openprocessing.org/sketch/494102/
|
| Setting the particle speed to more than about 0.5 (on line
| 46) results in "aberrations". The dynamics are quite
| interesting and I'm not sure exactly what's going on, but I
| think wetmore's answer is correct--when the steps are small
| enough, everything remains as smooth as the underlying scalar
| field produced by Perlin noise.
| bhickey wrote:
| 'Procedural Landscapes with Overhangs' by Gamito and Musgrave
| covers exactly this!
|
| http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.2.1.
| ..
| wetmore wrote:
| I think it comes from the noise field being relatively smooth,
| and the particles taking such small steps each frame.
| huhtenberg wrote:
| More like noise _circles_ rather than _spheres_. Still looks good
| though.
| gameswithgo wrote:
| a while back I got into fractal noise, simd instructions, and
| unity and made a bunch of planets:
| https://www.youtube.com/watch?v=dqNXpU9d2_I
___________________________________________________________________
(page generated 2021-01-10 23:02 UTC)