you get unwanted artefacts in the results if you don't use some randomness. having said that, there might ways of reducing the need for it (which would be more efficient).
It's not necessary, but it's convenient. What's actually happening here is Monte Carlo integration. Randomness guarantees you get the right answer. It prevents correlation artifacts. It also gives you a nice film grain look when you don't have the time to take samples until complete convergence.
Nice. I created a package to generate similar depth of field images in R, using a depth map/image pair. Also offers customizable bokeh shape and some other nice features.
If you don't mind me asking, can you recommend any good resources for getting into generative art?
I've been interested for a while and played around a bit, but I'd like to dive in a bit more since I have a bit more spare time now than I've had in while.
there are some references on my website. see the faq and the generative section. there are many ways to start. depends on your previous knowledge and how you prefer to work. the nature of code is a book that might be of interest. Nervous System have written up several of their projects. then there is the work by early generative artists. Vera Molnar, Frieder Nake, Manfred Mohr, Lillian Schwartz, among others. also, see https://github.com/terkelg/awesome-creative-coding/blob/mast...
Since the theory isn't really described here, anyone who wants a tad more might look at the Ray Tracing In One Weekend booklet for a touch of the optics math behind depth of field. Chapter 11 derives a defocus blur. http://www.realtimerendering.com/raytracing/Ray%20Tracing%20...
> find the new position, w = v + rndSphere(r).
For anyone wanting control over the look of the defocus blur, also known as the "bokeh", random sphere gives you more samples toward the center than the edges. For a circular aperture, it is slightly better & more correct to sample a disk than to sample a sphere, and slightly faster to converge as well. You can optionally use a hexagon or octagon on the disk if you want to get the look of a film-camera type aperture.
I'm talking about correctness in the physical optics/lens sense. With lenses, light always passes uniformly through the aperture, where sphere sampling is non-uniform.
Intention is totally fine. This is reasonable if you actually intended to do something different than what a camera does, or if the intention is not physical correctness. This blog post seems to be intending to do something easy for picking samples, as opposed to something optically correct. I'm all for easy, but I also think it never hurts to understand the tradeoff you're choosing, nor to present the harder alternatives.
It's also worth considering disk sampling rather than sphere sampling, because it's barely any harder, and it will make the code converge to the same quality something like 2x faster. Sphere sampling spends too much time in the middle and not enough at the edges. Disk sampling only takes a teeny tiny bit more arithmetic. Jittering & QMC methods will also help a lot with efficiency.
yeah, i'm going for easy. and also, easily explainable. i like to leave some of the details up to whoever tries it. which is also why i generally don't include code anymore. i guess i could have had more references though.
sphere sampling has the appearance i want. but sampling inside discs with a probability over the disc radius would also work, probably. i didn't try it here.
reply