Main menu

I have been an intern at Google in Mountain View for nearly two months now. I’ve reached the midpoint of my stay here so I want to share some of my experiences of living in Silicon Valley.

I have had an absolutely amazing time so far. When I was on the plane from Sweden to California I almost couldn’t believe that this was happening. I never imagined that I could work at Google, so the first days at work seemed almost unreal. I’ve learned so much from working here and I’ve met very many friendly people. I feel really lucky.

I have never lived outside of Sweden before, so it is interesting to note the differences between living in Sweden and the USA. The first differences I noticed were the much wider roads, larger cars/trucks, and more talkative people. The California weather is very different from Sweden: much hotter and drier, mostly. There were a few rainy days last month, but according to the locals those were freak occurrences. Unfortunately health care and housing is extremely expensive here compared to Sweden.

California is much less bike friendly than Sweden, but there is one nice bike path where I bike to work every day. The bike path goes along the shoreline where there are lots of birds. I’ve seen Geese, Egrets, Pelicans, and other birds I don’t know the name of.

To get around on bike you often have to bike on the road next to cars. Usually the roads have a bike lane, but it still feels much less safe than biking on an isolated bike path. Speaking of cars, there are many Teslas, Priuses, and self-driving cars on the streets here.

My favourite thing about California is the nature and landscape. Palm trees are a common sight here, and all trees are huge compared to trees in Sweden. There are also plenty of awesome places to hike on weekends. On my third weekend here I went to Yosemite with some friends. Yosemite is probably the most beautiful place I’ve visited so far, and hiking there was one of the best experiences I’ve had.

I’m happy to announce that Chunky 1.3.5 has finally been released after a slow trickle of features and bug fixes over the past several months! This post will highlight some of the notable changes since 1.3.4 with pretty pictures!

Mac bundle

I am now building Mac bundles again for each release. Mac bundles are a simple way of installing Chunky on your Mac if you have one, however I currently only test it with the Oracle Java distribution on a 64-bit machine, so it might not work for other Mac systems. There are some minor problems with the Chunky UI on Mac to improve in the future.

Paintings

Paintings are now rendered by Chunky. This was not a highly requested feature, but one that relied on entity support. With the entity rendering framework in place it will be easier to add rendering of other entities in future updates!

Camera view indicator

Chunky now renders an approximate outline of the camera’s field of view on the 2D map, seen as a yellow rectangle in the screen shot below. You can right-click on the map to bring up the context menu and select all visible chunks inside the camera view indicator! This makes it much easier to load the right chunks for a specific view. Hilly terrain can still be problematic because the camera view indicator is based on the assumption that the world is flat (and supported by elephants).

New icons

The icon for the “Water” tab in the Render Controls dialog was loaded directly from the current texture pack. This caused the tab to become ridiculously large when using a high-resolution texture pack. There is a new icon for this tab now with a fixed size, so that the tab will keep its intended size. There are some new icons for a few other things as well in the UI.

Single color textures

A new option to render each texture as a solid color was added. It can be used to create a fun look:

Improved fog

The fog and atmosphere rendering system in Chunky was a hastily designed piece of junk. It has been rewritten to be simpler and faster. The new fog system allows everything from very light haze (aerial perspective) to thick fog to be emulated with a single fog density slider. You can even choose the color of the fog! Check out my previous post for more info about fog.

Render bugs fixed

These rendering bugs were fixed:

Certain configurations of stairs rendered incorrectly.

Some mushroom blocks rendered with wrong textures.

Fog did not work correctly around stairs.

Fixed lighting bug for underwater blocks.

Fixed rendering of buttons using the new button orientations (since MC 1.8 buttons can be placed on the top/bottom of a block).

Note that some of these fixes require reloading the chunks in scenes created with Chunky 1.3.4.

Scroll bars

The Render Preview window now has scroll bars, and no longer stretches the rendered image to fit the window. This seems like a small thing, but I was constantly annoyed that changing the window size stretched the preview image. Scroll bars make a lot of sense on a small screen or when rendering a huge image.

To simulate real fog is surprisingly complicated, and computationally expensive. The way real fog behaves has to do with how light scatters in air when interacting with scattering particles (aerosol). The same phenomena occur in clear weather and are responsible for making the sky look the way it does.

The light scattering that happens in the sky is usually categorised into two types: Mie scattering and Rayleigh scattering. Mie scattering describes how large particles (relative to the wavelength of visible light) scatter light, while Rayleigh scattering deals with smaller particles. Rayleigh scattering scatters light with shorter wavelengths more, i.e. blue light is scattered more than red light, the root cause of the sky being mostly blue.

I was interested in implementing physically based fog rendering, using equations for Mie/Rayleigh scattering, in Chunky. The version currently in the stable release of Chunky (1.3.4) was a half-assed implementation of that. I did some experimentation in a separate Java project to see if I could produce a better scattering implementation. The result was rather nice:

Sky rendered by light scattering simulation. The sun is not explicitly rendered, though it is visible due to the elliptical phase function giving a sharp increase in incoming light from the direction of the sun.

The advantage of simulating light scattering for fog rendering is getting the right color at the horizon. In video games you can often notice a clear border between objects on the horizon and the sky. If both the sky and the fog is rendered by light scattering simulation you will get a nicer transition from horizon to sky.

The problem with using scattering equations for fog simulation is that it’s too computationally expensive, and does not allow tweaking the fog color. I wanted to allow changing the color of fog, contrary to the way real fog works where the color is an indirect result of the light scattering behaviour.

Most equations for light scattering involve an exponential extinction factor. If you really simplify the equations you can make believable fog by using the extinction factor to blend in a fixed fog color. This entirely short-circuits the whole simulation aspect of fog rendering and is much less computationally demanding. I have implemented this system in the latest version of Chunky, and it seems to be working rather well.

There is however a problem with my new fog rendering system: inscatter light intensity (the fog color blending factor) is based on the fraction of lit fog along each light path, i.e. how many inscattering events happen on the light path proportionally to all simulated events. This causes light shaft intensity to drop off too much if there is a lot of non-lit space around the light shaft. This undesired effect can be illustrated with a room where the camera looks through a light shaft at two walls that are far apart:

The light path to the near wall has proportionally more inscattering events when path tracing than the light path that hits the far wall, though they should both have the same inscatter contributions.

The fog color scaling by room depth can be “fixed” by multiplying with the light path length for each inscatter contribution. However, that fix makes the inscatter component much larger for distant objects and decreases the convergence rate. If I was better at solving differential equations I might be able to work out how to make the inscatter component same as in the no-shadows case when using the simpler equation, but that would still mean convergence is slower (grain/noise in the render). I think I will just leave the current system as it is because the rendering error is difficult to notice and the fog looks reasonably nice. Here is a comparison between two inscatter equations I’ve been testing:

The lower part of the above image was rendered with an improved equation that tries to compensate for the light path length. It took much longer time to render than using the simpler equation, seen in the top part of the image. The improved equation generates slightly nicer results but it might not be worth the increased rendering time.

Chunky development has slowed down significantly during the spring, as usual, because I have been swamped in work. There are some important things to discuss however:

Google Internship

I will be doing an internship at Google (at the Mountain View office) during the summer. I will avoid working on Chunky during this time in order to not cause a conflict of interest with my internship work. This is unfortunate because otherwise I would have as usual spent some time working on Chunky during my summer vacation.

Paintings and Entities

A few new versions of Chunky were released during Christmas/New Years, with a big improvement to water rendering. While working on water rendering I rewrote some important parts of the render pipeline to better handle entities and since then I have released a few snapshot releases that can render painting entitites! This is not a huge step yet, but it enables me to add rendering of other types of entities such as mob heads, floating books, and even players and monsters. In my private development branch I already have a semi-working player entity rendering system, which I have posted about previously on this blog.

Camera View Indicator

I added a simple camera view indicator, and posted about it on the Chunky subreddit. The post got a surprisingly positive reception so I decided to include it in a snapshot release. The feature is currently a bit buggy, and not super useful.

I would like to make it possible to automatically select all visible chunks within some radius, but didn’t get around to implementing that yet. The camera view indicator can also be quite misleading since it is only an approximation based on the estimation that the ground-height is fixed. So it would work correctly with a completely flat world, but for hilly worlds it is often quite incorrect.

Bug Fixes

During the periods when I don’t have much time to work on Chunky I still fix bugs occasionally, and the list of fixes tends to become large enough to merit its own release, however I do not want to release the currently half-working camera view indicator yet. I’ll try to improve the camera view indicator feature before the next release. Bug fixes you can look forward to in the next version include:

Fixed stairs with fog render issue

Added a notification after changing the Y cutoff setting about reloading
the chunks for the setting to take effect.

Added new tab icons in the Render Controls window. This fixes the issue
with huge tabs when a high-resolution texture pack was used.

Fixed a rendering issue for corner stairs causing various configurations
to render incorrectly

Fixed an error causing incorrect lighting of underwater blocks

Fixed button rendering (render new button orientations correctly)

The render reset confirmation feature now works as it should when the
target SPP has been reached

Pull Requests

We got an interesting pull request on GitHub for improved trigonometric function performance. I have not had time to benchmark it yet and see how it affects rendering speed and correctness, but I hope to do that before next release and maybe it will improve render speed slightly.

Next Release

I will try to release version 1.3.5 with the above mentioned painting entity rendering and camera view indicator and a bunch of bug fixes that have accumulated over the past several months. Hopefully the release happens soon, before I go to Google, but it is difficult right now since I am very busy with my regular work.

The advice I usually see about reading C declarations is to read them from the inside out. This method works fine for me, but I recently found a simpler method based on the idea that a declaration in C mirrors the use of the declaration.

Let us take for example the declaration of a pointer to a function returning an integer:

In all these cases the declaration of a variable resembles its usage in an expression whose type is the one named at the head of the declaration.

In other words, the use of the declaration would look nearly the same, in fact just remove the int and you get

(*f)(); /* use of f */

This may not seem like a big difference, but I believe that to people who are used to reading C code this is immediately recognizable as dereferencing a pointer and calling the result as a function. The usage example thus explains what the declaration means!

It seems to me that this method is useful because reading the declaration as a usage leads intuitively to an inside-out interpretation of the syntax. This might be because you actually imagine the execution of an expression, rather than the abstract meaning of a declaration. C programmers have this inside-out parsing technique internalized in the context of expressions, while in the context of declarations, at least to me, it is a more conscious effort.

Below are some more examples of different kinds of C declarations, and their corresponding as-if-used interpretation.

Example A

int *f(); /* declaration */
*f(); /* use */

The above declaration is for a function returning a pointer to an integer. Normally one would not dereference a pointer without using the result, so you could imagine that the use occurred as the right-hand side of an assignment.

Example B

void (*f(int, float))(); /* declaration */
(*f(3, 1.4f))(); /* use */

In this case there are parameter types which should be substituted by literals of corresponding type in the use example. From the use example one can conclude that f(3, 1.4f) is a call of function f, which returns a pointer to a function.

Example C

float *a[];
*a[3];

Arbitrary array indexes should be added in place of empty square brackets. The use case here shows that the declaration is an array of float-pointers. One could make the declaration slightly more readable by adding parenthesis around a[].

Example D

void (*a[])(int);
(*a[5])(0);

Now this example I find a bit difficult to parse using the inside-out method, yet reading the use case leads me on the right track faster. The declaration is an array of function pointers (array of void (*)(int)).

Did you know that 0X0.P0D is just an odd way of writing 0.0 in Java (and C)? Or that 0x.1921_FB_C0P5 is a rough approximation of Pi? On the surface the specification of floating-point literals in Java seems simple, but you can write some really confusing stuff that still parses correctly. Let’s look at some simple floating-point literals to start:

1.1
1.
.1

These are valid floating-point literals, and they are easy to read. Things get more interesting when you add in the optional exponent part:

1.0e2 (= 100.0)
1e-2 (= 0.01)
1.e2 (= 100.0)
.1e2 (= 10.0)

The first two examples are easily recognizable as numbers, but the third and fourth examples are a little more difficult to read. I think the third example could easily be misread as I.e2 which has an entirely different meaning. Things get even harder to read if you add a precision specifier (F or D):

.1e0d (= 0.1, double)
5.E0F (= 5.0, float)

The 5.E0F literal looks a bit like S.EOF.

Let us get even more crazy with hexadecimal floating-point literals! These look like an ordinary hexadecimal number but can contain a decimal point and must end with an exponent part where P replaces E as exponent prefix character, and the exponent uses powers of two:

0x1P2 (= 4.0)
0x1P4 (= 16.0)
0xC3P0
0xCAFE.P00

There are lots of word-like strings that can be formed in a hexadecimal floating-point literal. For example

0xA.P00F
0xB00P-0F
0xBAD.P0D
0xC0P5
0xCAP5
0x00P5
0xDEAD.BEEP5

These word-like strings work best if your typeface has zeroes without slash or dot, so that they are more similar to Os. The 00P5 (OOPS) suffix can be put at the end of anything. You just have to divide the number you want by 32, and write it in hexadecimal floating-point notation and append 00P5. Here is Pi with the 00P5 suffix:

Compiler Bugs!

I tried out some of these floating point literals in Eclipse and incidentally found a bug: Eclipse accepted 0XP00 as a valid literal, however it is actually invalid because it does not have any digits in it! I reported this bug to the Eclipse developers and they seem to have made a patch for the issue already!