Chunky 1.1.8 2013-03-27

I just released Chunky version 1.1.8. It fixes a texture loading problem caused by animated Minecraft 1.5 textures that some people were experiencing. I had planned to implement more things for version 1.1.8 but I want to get this bugfix out sooner rather than later. Since I will be away over Easter it would have taken at least a week until I could do the release if I didn’t do it now.

In 1.1.8 I’ve added a way of manually doing distributed rendering. It is now possible to merge render dumps into the current render, which means you can render simultaneously on a different machine, grab the dump and merge it into the current render. This does not work fully as it should right now, and it’s a bit tedious if you want to merge many dumps but at least it’s one first step towards distributed rendering. I used it while rendering the two Broville wallpapers from the previous post.

Here is the reddit release thread.

2 Comments on Chunky 1.1.8
Categories: Chunky

Building in Broville 2013-03-26

My go-to Minecraft world for testing the 3D rendering in Chunky has been Broville v10 by Oldshoes & Co. Here is an early render I did of Broville v10 that shows how far Chunky has come since last summer:

oldshoes1

The first time I saw Broville was while browsing /v/. I believe it was 2010. It was the first time I saw anyone attempt to build a genuine city in Minecraft. This was back when Minecraft was still in alpha, and mostly I’d just seen people building isolated structures before that. Broville was intended to be one coherent city and that was pretty damn cool!

A couple weeks ago Oldshoes, the man behind Broville, gave me a tour of the Broville v11 project. Broville v11 is amazing, it completely blows Broville v10 out of the water! Unlike it’s predecessor, v11 is a complete reboot, the Broville team has started a new city from scratch rather than continuing to expand on the old one and it is looking incredibly good already. The new map is better planned than the old map and has a SimCity-esque feel to it.

Even though I do not play a lot of Minecraft myself, in fact the last time I really played Minecraft was in the spring of 2011, I have started building my own little hideout in Broville 11. I’m building a small hobbit hole in the forest outside the city, and though it may not seem as much on the outside it’s got some secrets inside!

I look forward to rendering the Broville 11 cityscape, but until then here are two wallpapers from the v10 map that I’ve been rendering for the past week:

2 Comments on Building in Broville
Categories: Chunky

Windows Installer 2013-02-19

Yesterday I released version 1.1.4 of Chunky. Among the many changes in this version was the addition of an installer for Windows. I’ve been wanting to make a Windows installer for Chunky for quite a while now. The installer displays the GPL license and checks for an installed Java version. It can also make a nice start menu folder for Chunky with shortcuts to the program itself as well as the Wiki and the ReadMe file. I think this is a big improvement for Windows users because it is a very familiar way of installing and using a program.

No Comments on Windows Installer
Categories: Chunky

Sudden growth 2013-01-17

A week ago I was looking forward to the 500th subscriber on the Chunky subreddit. On friday, 11th of January, the 500th person subscribed! To commemorate this event I designed a new icon for Chunky and set it as the subreddit’s logo, with the number 500 in big friendly letters.

chunky

On the next monday, not four days after the 500th subscriber, the subreddit broke 600 subscribers! There was amazing activity on the subreddit all weekend with a ton of new posts! I think part of the new user influx might have been a mention I made of the subreddit in Chunky’s Minecraft Forum thread.

Anyway, welcome to the new subscribers! I hope to see the subreddit grow even more. It’s a great collection of high quality user-generated content!

Stats from the subreddit

Stats from the subreddit

No Comments on Sudden growth
Categories: Chunky

Chunky on GitHub 2013-01-04

I’ve recently started using Git for version control. Previously I have mainly been using Bazaar for my hobby projects and Subversion for work. The difference between Bazaar and Git is not big, and both have their own advantages and disadvantages. While I don’t want to say that one is better than the other Git surely seems to have won the battle for popularity, and I think there are many contributing factors, not only the version control systems themselves.

One factor in the success of Git is likely GitHub. Both Git and Bazaar have online repository hosting websites. Bazaar has launchpad and Git has GitHub and BitBucket. I have only used launchpad and GitHub so far, but out of those two my favorite is easily GitHub. There are some features I don’t care for in GitHub, for example the ability to have emoticons in comments, but overall it has a much sexier and responsive interface than launchpad.

I decided to put Chunky on GitHub exactly because of the nicer user interface. I’ve always been annoyed at launchpad being slow and complicated. I will still be putting the Chunky downloads on launchpad because I really like being able to count total downloads. I counted all the downloads of Chunky a couple weeks ago and at that time Chunky had been downloaded more than 33 thousand times!

Click here to view the GitHub page for Chunky.

6 Comments on Chunky on GitHub
Categories: Chunky

Adaptive sampling 2012-08-09

I was interested in implementing some form of adaptive sampling for the Monte Carlo path tracer in Chunky. To the uninitiated it might seem simple – you often notice while rendering that some parts of your scene will always converge quicker while noise remains in the more difficult regions. For example, the following scene was rendered with 500 samples per pixels:

The sky in this scene converges after only a couple samples, and due to the way light emitting objects are rendered the torch has converged almost just as quickly. Other areas take much longer to converge. You can still see noise on the non-transparent areas of the windows.

So the naive idea is that if you could just render fewer samples in the areas where the image converges quickly, and spend those samples in more difficult areas, you could increase the convergence rate of the image. Well, it turns out it is not that simple. I did what I usually do: I tried to implement it myself, then started reading articles about the problem. From the articles I later did read there appears to be no huge benefit from adaptive sampling. Some researchers have had marginally positive results, but the difference to uniform sampling (or fixed sampling as some call it) is marginal. Plus, it introduces rendering bias which is undesirable.

I’m posting my results here anyway. I figure someone might find them interesting.

My first idea was that I should use confidence intervals for the sample color at each pixel to guide the adaptive sampling, but then I figured that I probably wouldn’t need that (wrong!). Why not just measure the difference in sample values over a number of frames for each pixel, then focus on sampling those pixels that had the largest difference in sample values!

Per-pixel adaptive sampling does introduce significant overhead, which can of course be optimized, but I opted for a simpler method. The rendered image is already split into tiles (in this case 8 by 8 pixel tiles). I averaged the 5-sample difference over each tile. Then, every 5th frame I selected half of the tiles, those with the largest sample variance over the previous 5 frames, to be rendered for the next five frames. This is the result:

That above frame was taken after an equal number of samples to the first frame. That’s 500 SPP in average, but of course it varies between tiles. I was disappointed to see that the image looks a bit worse than the first one. Since the sample values are averaged over a tile, if only one sample has a huge difference it gets smoothed out by the other samples and not noticed by the algorithm. I’m bad at explaining this, but look at the torch. There are some noisy pixels there in an otherwise converged area, so sample difference for those noisy pixels gets outweighed by the mostly non-noisy neighbor pixels.

I continued by scrapping the tile-based approach and instead tried using the 50 sample average per pixel. This turned out to also provide disappointing results:

It’s really difficult for me to see any improvement in the previous render from the first one, using uniform sampling. With the additional overhead used by the adaptive sampling algorithm I had a lower effective sample rate. I was quite disappointed. Finally, I read some articles on the subject and found that some researchers had used the confidence interval approach, with mild success. Adaptive sampling really does not seem to do that much for path tracing. The cost to benefit ratio is too low to spend more time on this.

2 Comments on Adaptive sampling
Categories: Chunky