Chunky 2015 Fall Update

In this installment of Chunky news I will discuss the current development progress and my plans for the future.

Current Development

I recently uploaded a snapshot for the upcoming version 1.3.6. Version 1.3.6 which will include sign text rendering, bug fixes, and rendering for some new block types and previously unsupported blocks. The new entity rendering system allows me to implement rendering of some types of blocks which were really difficult to render previously, so that makes me really excited. However, I will not tackle more complex entities such as players and animals/mobs for the 1.3.6 release.

1.3.6 Preview

I recently experimented with a new rendering technique that proved to be very successful. It’s a neat trick that can drastically cut render time for complex scenes with difficult lighting. The idea is to split up the render into two separate passes: sunlight and emitter passes. Splitting these two light sources makes it possible to blur the emitter light where it is too noisy.

I posted about this rendering technique on reddit, and this imgur album sums up the technique. I plan on writing a more detailed tutorial for this rendering technique to post on the Chunky website. I’m also thinking about adding a black sky mode in Chunky to make the scene setup for the emitter pass a bit faster.

Future Plans

I often have ideas about neat features to implement in Chunky. One of the ideas I am most excited about at the moment is plugin support. This is something that I have vaguely thought about before but never really considered possible, but with the current launcher it would actually be pretty simple to implement plugin support. The thing that really blocks plugins right now is that I’d have no way of signing/verifying plugins. Plugins would be a huge security concern for the plugin users. On a related note I really want to add verification for the core Chunky binaries.

My current priority list for future projects is this:

  • Signing and verifying Chunky core libraries
  • Player and animal/mob rendering (needs posing UI)
  • Custom models from resource packs
  • Plugin support
  • Translation support
  • Translating the Chunky website
  • Distributed rendering
  • GPU rendering

GPU Rendering

Although GPU rendering seems to be the most requested feature by users I don’t have it that high on my own priority list because of these reasons:

  • The overall main priority for Chunky is to reach feature parity with Minecraft. Every Minecraft block and entity needs to be rendered correctly. GPU rendering would require re-implementing a lot of things that are handled now by the software renderer, so I’d rather complete the software renderer first.
  • GPU rendering will take a lot of time to implement, and I think my time is better spent on other things like supporting new Minecraft features.
  • Although everyone who requests GPU rendering seems to believe that it would give a huge boost to rendering speed my estimations are much lower. I believe it will be faster, just not that incredibly much faster.
  • I believe distributed rendering will give a much higher return on investment when considering time spent implementing versus net rendering efficiency increase.
  • Aside from just implementing a GPU renderer, a lot of code needs to be restructured in Chunky just to integrate that smoothly into the existing render framework.

Two Months in Silicon Valley

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.

Geese on a bike path

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.

Here are some pictures from places I’ve visited in California:

Yosemite Falls

Yosemite Stream

Lake Tahoe

Golden Gate Bridge

Mt Tamalpais

Chunky 1.3.5 Feature Spotlight

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.

Mac Bundle


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).

Select visible chunks demo

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.

Tab Icons

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:

Shoreline with single color textures

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.

Stair rendering issues

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.

Scroll bars in the render preview window

Rendering Fog

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.

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 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:

Different inscatter equations

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.


Here are a couple of nice articles describing light scatter simulation:

The first article describes one of the most widely used methods of simulating a day sky. It is not perfect, but I used it in Chunky for the “simulated” sky model.

Chunky 2015 Spring Update

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

Camera 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.
  • Improved huge mushroom rendering: mushroom blocks with some data values
    were rendered incorrectly
  • 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.

A simpler way to read C declarations

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:

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

My new way of reasoning about what the above line means is to imagine that I were to use the declaration, inspired by Dennis Ritchies comment on similar examples in The development of the C programming language:

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[];

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);

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)).