I discovered last year these tutorials by Jasper Flick on how to make and use noise in Unity, and a couple of terrain and particle use examples. They present the difference between value noise and gradient noise, how Perlin noise and simplex noise work, and among others how to use curl noise to control the flow of particles.
The order information is presented is well thought, although the intention might not be clear at first. Don’t let the beginner’s tutorial tone (“You’ll learn to: create and fill a texture;”, etc.) turn you away, as the series do a great job at detailing the concepts and algorithms in a simple manner yet without cutting corners like so many articles on the topic do (when they’re not blatantly wrong and go ahead calling a blurred noise “Perlin noise”). I thought I had a pretty good grasp of gradient noise already, but reading it gave me an even better understanding.
While at it, other resources on the topic include Ken Perlin’s GDC 1999 talk and his two pages paper Improving noise explaining why use a 5th order polynomial for interpolation (a function I’ve sometimes seen called “smootherStep”).
Christophe Riccio posted on his twitter feed some pictures comparing the quality of different texture compression formats, including the PowerVR’s native compression format, PVRTC2. In the light of his tests, it seems to me the new compression is a lot better than before (unfortunately they are not compared).
Last year at my work, in a context of trying to reduce loading time, memory consumption and application size, we gave a try at PVRTC and in our use case it was a clear no go. The quality was so badly impacted that the texture size we’d need for the artists to be happy was well beyond the weight of a PNG of equivalent quality. In the end we settled with WebP.
Here it is interesting to see that even at 2bpp, PVRTC2 seems to retain a lot of detail and texture. The edge tend to be muddy but this is still very good for the price.
Published in early 2014, it is a book written by a programmer, Andy Weir, and it is his first book. As any first book, and as any book written by someone whose day job is not being a writer, it’s not perfect. The style is so so, and sometimes even poor. But it is good enough. It is written with an engineer’s attention to technical detail though, and that makes reading a very fun experience for technical people, even if at moments it gets long and hard to follow.
The story is fairly well exposed by the trailer of the upcoming Matt Damon starring blockbuster movie: in a near future, a Mars exploration mission is aborted and the crew leaves the base, leaving one dead crew member behind. Except he’s not dead, and as he wakes up, he realizes he’s alone, without means of communication, forsaken on a lifeless planet, with a month worth of food, and about four years until a potential rescue mission reaches him.
From there, the author tells the story of how his character tries to survive with what he has at hand, while maliciously throwing at him all sorts of traps, accidents and set backs: “haha, today while working you create a short circuit and kill an essential piece of circuit”. It is all story told with care for realism that turns some parts into challenging puzzles (wait, you just killed him there! How can he make it out of that? Oh, nice, that’s clever! – or on the contrary – Ha! I know, he can use this and that, haha, I’m so smart) and includes some parts that rank pretty well on the adventure scale, like when he decides he’s gonna fetch an exploration rover 800km away to use its communication system.
Most of the book is narrated as logbook entries on the Mars side, and from a spectator’s point of view on the NASA side. It makes the reader aware of both sides while appreciating how each side tries to understand and anticipate what the other is doing. So this narration works very well for suspense.
xkcd alt text: “I have never seen a work of fiction so perfectly capture the out-of-nowhere shock of discovering that you’ve just bricked something important because you didn’t pay enough attention to a loose wire.” Funny coincidence: at the time of writing I didn’t realize I chose the exact same example as the xkcd alt text.
But on the down side, as I was saying, there are weaknesses in style. Essentially, I’d say there are mainly two of them. One is the fact that most of the story is told by shiplog entries, and those entries contain details to serve exposition that would never be logged in real life, like an astronaut explaining how the base works. The other one is the tone of the book, upbeat, casual and funny, conveyed by the tone of the character’s log entries and meant to show his personality in the face of adversity and dire situations. This would be all good if it didn’t prevent log entries from being on par with the strictness and ethics one would expect from an engineer sent to Mars. But of course, that would also make the book reading a much more dry experience, so the author’s choice is understandable.
As a conclusion, I recommend this book, I had a lot of fun reading it and learned a couple of things about practical space exploration along the way which is pretty cool for a novel.
In this 45mn talk, the author Andy Weir presents the book, reads the first chapter, then present a tool he wrote to compute the trajectory of the ship:
Mitsuba is a research-oriented rendering system in the style of PBRT, from which it derives much inspiration. It is written in portable C++, implements unbiased as well as biased techniques, and contains heavy optimizations targeted towards current CPU architectures.
We present an integral equation which generalizes a variety of known rendering algorithms.
We mention that the idea behind the rendering equation is hardly new.
However, the form in which we present this equation is well suited for computer graphics, and we believe that this form has not appeared before.
The basic idea is that particles are shot at the same time from a selected light source and from the viewing point, in much the same way. All hit points on respective particle paths are then connected using shadow rays and the appropriate contributions are added to the flux of pixel in question.
Our statistical contributions include a new technique called multiple importance sampling, which can greatly increase the robustness of Monte Carlo integration. It uses more than one sampling technique to evaluate an integral, and then combines these samples in a way that is provably close to optimal. This leads to estimators that have low variance for a broad class of integrands. We also describe a new variance reduction technique called efficiency-optimized Russian roulette.
The second algorithm we describe is Metropolis light transport, inspired by the Metropolis sampling method from computational physics. Paths are generated by following a random walk through path space, such that the probability density of visiting each path is proportional to the contribution it makes to the ideal image.
Nathan Reed recently published a blog article plotting his numerical findings of Z-buffer precision under different uses. On the way he references a couple of previous articles, that also reference other resources; I think it’s a good opportunity to list some of them. They all tell a part of the story and I recommend reading all of them to get the complete picture.
Since the beginning of 2014, there has been a lot of videos demonstrating the realism that can now be achieved with Unreal Engine 4.
Often, these videos showcase a static scene or even concentrate on a single detail: lighting in an architectural structure, the look of rain hitting the ground, or some wet pebble on the beach.
Physically based rendering, global illumination and screen space reflections seem to manage to trick the brain an get it confused between what is real and what isn’t. Even when some artifacts get salient, like reflections popping in and out or changing with camera orientation, we are quick to forget them and find the image very believable.