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

Being Creative with Numeric Literals in Java

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:


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)

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


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:

0x.1921FB54442D1100P5   (Java 6)
0x.1921FB54442D11__00P5 (Java 7+)

Java 7 added underscores in numeric literals, so you can make the OOPS more noticeable with an underscore or two!

If you want to make your floating point literals really unreadable you can add a sign to the exponent and surround the literal with addition or subtraction expressions. Here are some examples:

-.0e-0_0f  (Java 7+)

One final example of perfectly legal Java code:

class E {
  double e;
  double e(E e5) {
    double d5e = .8-0- -0-8.; // palindrome expression!
    return .5e-5f-5.e+5d-d5e+e5.e;

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!


Joe Bolder at Egmont sent me a copy of their book “Blockopedia”. The book came in a nice box:

Blockopedia Box

The design of the book is interesting. It fits awkwardly in a bookshelf without the companion box.


Joe sent the book as thanks for my work on Chunky. Nearly all pages of the book have a nice background image rendered with Chunky:

Blockopedia Inside

It is really awesome to know that Chunky renders are used in real books. I’ve previously noticed images in other books that were clearly rendered with Chunky, for example the Minecraft handbook series. Those seem to sell pretty well because I have seen them in several of bookstores. The Minecraft handbooks are even sold in my local grocery store!

I’m sure the Blockopedia book will do well too, and the images in it might be seen by millions of people. To me that is a very cool thought!

Analyzing Traffic Spikes

The current Chunky documentation site has been live since June. I installed Google Analytics on it for fun. When looking at the overview on Analytics a couple days ago I noticed that there had been two very large spikes on October 10 and 19:

Traffic Spikes

You can see a more normal period before and after the two spikes in the graph above. The number of visitors during the spikes was some orders of magnitude greater than during a normal period. I was immediately curious about where the visitor spikes came from. When I looked at the referral traffic, i.e. traffic caused by people clicking links on other sites, I saw only the second spike:

Referral Traffic

Although minecraftforum is the largest total referral source in the above image, when I narrowed the time period to just around the 19th and 20th, Kotaku was clearly the largest traffic source. In Google Analytics you can see even more detailed reports about which page a referral came from, and using this I found a Kotaku article about a beautiful Chunky render that was posted to the Minecraft subreddit on October 19.

So that explained the second traffic spike, but what about the first? There was only a slight hump in the referral graph at the 10th of October, but a large spike in direct traffic, i.e. many people just typed the address into their browsers. Here is the graph of direct traffic:

Direct Traffic

I went back to looking at the few referrals and saw that there were slightly more referrals from YouTube than normal. Then I realized that if someone sees, or hears, a URL in a video they might type the address directly in their browser rather than check the video description for a link. I could not see referrals from a particular video (the video ID parameter seems to be filtered out by Google Analytics), but I did see referrals from the channel of a particular YouTube user named alexelcapo. I went to alexelcapo’s YouTube page and found a video posted on October 10 which seems to be a tutorial for using Chunky. I have never heard about alexelcapo, but they have nearly 1 million subscribers so it seems plausible that their video caused the October 10 traffic spike.

Chunky 2014 Fall Update

It has been a few months since the last Chunky posts on this blog, and since I have referred people interested in the development process to this blog I thought it was time to give an update on the current status of Chunky.

Some of you may already be aware that I am a PhD student. This is in practice a more-than-full-time occupation. I work on Chunky mostly during my summer vacation, and a bit during Christmas. I can’t let Chunky interfere with my work, and that is the main reason that development has been on a hiatus now since summer.

With that in mind, I have some short-term goals for Chunky that I hope I can reach when I have time to tinker with Chunky again. First, entity rendering should be added in a snapshot release. There is some partial entity support currently that I have in my development branch. The rendering pipeline and scene graph is in need of some significant refactoring in order to implement entities in a nicer way, so it might require a lot of work.

During the summer I worked on some improvements for sky rendering, but there is more that can be done in that area. I would like to improve the fog/atmosphere effects. This also ties in to the rendering pipeline refactoring. The new 3D cloud feature was hampered by a really bad rendering pipeline architecture.

In the distant future I would like to add an entity posing tool and a material editor. These are large components that would take a lot of work to design and implement but I think they would be really great additions to Chunky.

Of course, the often-requested GPU rendering support would also be fun to continue work on.

I don’t know when I can start working on the entity support again. My work is taking up much of my “free time” currently. I might be able to code some on Chunky around Christmas, hopefully!