My TEDx Talk 2016-01-19

I gave a talk at a TEDx event, TEDxLund here in Sweden, this past autumn (October 10, 2015). The event was organized by a group of University students. I was very surprised to be invited to speak at the event, and immediately I became nervous about the prospect of giving a TEDx talk. I have seen many amazing TED talks in the past and I feared being compared to other much better speakers and end up looking like an amateur. I am also not entirely comfortable with being filmed, and the idea of a video of me ending up on the Internet made me uncomfortable. I decided to give the talk despite this because I hoped that I might inspire a few people to learn programming.

The video is now live on YouTube: Rendering Minecraft | Jesper Öqvist | TEDxLund

My script went through many big revisions and even complete rewrites. My initial goal for the speech was to motivate young people to learn programming, so the first version of my script was all about that. I didn’t mention Chunky because it seemed unrelated to the topic. However, Chunky is probably the most noteworthy thing I have done in my life, so it seemed like my talk should be about Chunky in some way. Chunky is also a nice and well-contained success story and part of the advice I got about writing a TED talk was that you should use a story to engage the audience. The story of Chunky seemed more engaging than just talking about programming in general.

The final speech is about three things: Chunky, programming, and Minecraft. I had some key points I wanted to talk about and this was the best way I could think of to touch on each point. Those key points were:

  1. Programming is fun.
  2. You can do cool things if you learn to code.
  3. Programming is not as difficult as it may seem.
  4. Minecraft and other video games can be a great inspiration to learn programming.

Talking about Chunky was tricky because although it sort of helped the second point it could easily undermine the third point. I didn’t want to make Chunky seem too impressive. It is probably easy to think “I could never make anything like that”, especially for non coders, but the message I wanted to convey was that anyone can make something like Chunky, at least that was implied. Such a statement is difficult to make convincing without seeming arrogant, it might turn out sounding like I am too good at programming to be able to see the difficulties about learning to code. I tried to not trivialize the amount of work I have spent on Chunky, and I wanted to emphasize the iterative nature of coding – you make something crappy first and keep on improving it until it becomes better. That’s the way I made Chunky, and I am certain that with enough time and motivation anyone could make something similar because the math you need to know to make a ray tracer, like Chunky, is very simple and there are tons of tutorials online for both the math bits and the code bits.

One thing that made writing the talk difficult was that I had to write it for an audience that probably does not know what “ray tracing”, “path tracing”, or maybe even “rendering” means. I tried to use as simple words as possible, and explain any more complex words that I used. Rendering ended up in the title of the talk though, which might have been a bad idea. The title of my talk was a quick decision, “Rendering Minecraft” literally describes what Chunky does, but I started regretting the name afterwards because it might be misleading and imply that I have worked on the actual Minecraft game, which I have not. I hope there is not too much confusion about that.

There are probably many things that could have been improved in my TEDx talk, but I feel like I did the best I could with the limited time I had to prepare for the talk. I was very relieved after the event, because all of the script writing and rehearsing had been making me really stressed.

One of the people who came up and talked to me after my speech was the mother of a boy who plays Minecraft. She said her son was interested in programming, and wondered if I had any tips for where to learn programming. The one site I could think of then was Code Academy, but I have compiled a list of other sites I know of where you can learn more about programming below:

  • code.org has free programming courses, and a few small programming games in the “Hour of Code” section of the site, for example there is a Minecraft-inspired game that teaches the basic principles used in programming. Check out Minecraft Hour of Code here. I played it myself, and later I showed it to my younger sister (13 years) who played through it on her own. It is quite constrained and does not let you do a lot of interesting things, but it might be a good starting point.
  • Scratch is an online programming playground that lets you make interactive graphical things by dragging control blocks around to build a program. There are examples of things people have created on the site, everything from simple animations to playable games.
  • Kojo, a learning environment based on the Scala programming language, lets you experiment with more “real” programming – you write your programs in plain text rather than by connecting boxes.
  • Code Academy, and Khan Academy are sites that offer free courses in programming. I have not tried these, but I have heard good stuff about them.
No Comments on My TEDx Talk
Categories: Uncategorized

Entity posing and UI redesign 2016-01-06

I have been working on adding controls for posing and skinning entities in Chunky. I added a new tab in the Render Controls dialog which has a list of poseable entities and controls for adjusting each entity individually. It also allows adding/removing entities. It is still unfinished but somewhat useful, so I uploaded a new snapshot build with this work in snapshot 1.3.8-alpha1.

A screenshot showcasing the new Entities tab:

Entities Tab

I want to add some more features to the Entities tab before I release version 1.3.8:

  • Automatic downloading of player skins based on player ID.
  • Ability to save poses for easier posing.
  • Allowing multiple entities to be edited at the same time.

User Interface Redesign

I have been thinking about a redesign of the Chunky UI recently. I would like to get rid of the 3D preview window and integrate it into the main Chunky window. I also want the Render Controls to be inside the main window by default. I’m imagining something similar to how most 3D editors work where there is one or more 3D views of the scene in the middle of the window and toolboxes on the sides of the window. I also want the Render Controls tabs to become individual toolboxes that can be repositioned individually in the UI by the user.

Part of the motivation for this redesign is that the default mode you enter when Chunky starts is a plain 2D map viewing mode, while the most common task in Chunky is creating 3D scenes so the 3D scene mode should be the default mode. The map should just be a tool you use to load chunks from a Minecraft world.

One source of inspiration for me is the Blender UI:

Blender UI

Another idea I had was to migrate the Java 8 and JavaFX, but that is a larger change and nothing I want to deal with anytime soon.

3 Comments on Entity posing and UI redesign
Categories: Uncategorized

How I make temporary accounts 2015-12-22

I don’t like creating new accounts with my real email address, because:

  • I don’t want to be automatically subscribed to newsletters. This is annoying and happens very frequently, often without the offending site asking if I want to receiver their newsletter.
  • The more databases my email is in, the more likely hackers get it and sell it to spammers.

To avoid using my real email address for websites where I want to do low-priority stuff I have a process for generating a temporary public email address using mailinator, maildrop.cc, or similar providers. These websites let you go to a static public URL to view an inbox for any email account on the domain, for example if I go to https://mailinator.com/inbox.jsp?to=foo I will see all email recently sent to foo@mailinator.com. This is super useful, because now I can register accounts that are in no way tied to me personally.

To pick unique email address, username, password and first/last names I use a few Python scripts. This is the script I use to generate passwords:

import random, string
chars = string.lowercase + string.uppercase + string.digits
print(''.join(random.choice(chars) for i in range(10)))

This can also be used to generate an email address. For example, if I run the script to get a random string:

$ python genpass.py 
rcEf21llGs

I can use rcEf21llGs@mailinator.com as the email address for my new account. I also generate a separate random string for the password. Some sites have banned accounts from using @mailinator.com email addresses, so then I use maildrop.cc or another similar site.

To generate username and first/last name I use another script called namegen.py:

import string
from random import choice
prefix = [ 'Dr', 'Captain', 'Mr', 'Ms', 'Big', 'The', 'Not' ]
first = [ 'Happy', 'Crappy', 'Flappy', 'Jiggly', 'Wobbly', 'Neat', 'Freaky', 'Honking',
    'Prickly', 'Picky', 'Pixly', 'Random', 'Sick', 'Slippery', 'Slim', 'Shady', 'Wily' ]
last = [ 'Pants', 'Dog', 'Cat', 'Bird', 'Bag', 'Toe',
    'Waffle', 'Truck', 'Jeep', 'Beep', 'Boop', 'Phony', 'Puff', 'Rocket', 'Panda',
    'Hat', 'Boy', 'Girl', 'Crunch', 'Bee', 'Morty', 'Rick', 'Biggles' ]
for i in range(10):
    print(''.join([ choice([ '', choice(prefix) ]), choice(first), choice(last) ]))

The name generating script uses word lists for parts of a name, and picks randomly one first-part and one last-part. It also picks one prefix for half of the generated names. It prints ten names so that I have some alternatives to pick from and can pick one that I like. The word lists here have been shortened, my real lists are much longer so that I get more variety in the generated names.

Here are some names generated by the above script:

$ python namegen.py
BigJigglyMorty
NeatBeep
CaptainSickTruck
PickyBeep
DrRandomRocket
BigWilyTruck
CrappyJeep
TheHonkingPuff
CaptainSickPanda
CaptainFreakyToe

I use this process to sign up for online news sites, forums, and sometimes just to try out new services or APIs that require registration. This method is obviously not secure, because the email inbox is public and anyone can hijack your temporary account if they figure out your email and do a password recovery, so I use this method mostly for truly temporary accounts. I do use the password script to generate passwords for most of regular my accounts too because I want to avoid reusing passwords.

No Comments on How I make temporary accounts
Categories: Uncategorized

Breaking code by switching input streams 2015-11-18

This summer I was refactoring code for reading class files in a Java compiler. The code used a custom input stream, and the implementation did essentially what BufferedInputStream from the Java standard library did. I decided it was redundant to use a custom input stream, and I should be able to replace it by the standard library class. However, doing this caused many errors in the regression test suite for the compiler.

This seemed odd. Replacing one input stream by another should have no effect on the code using the stream, right? After taking a closer look at the custom input stream, it really seemed like it followed the contract of the InputStream documentation, so why didn’t it work?

The first step to solving a compiler bug is usually to create a minimal test case: a minimal input program that exposes the same compile error. I could not do that in this case because the inputs that were crashing the compiler were class files – a binary file format that is difficult to edit by hand.

Another way to start debugging a problem is to try to get closer to the root cause – even though you might not know exactly where the root cause is located you can often make an educated guess. I assumed that whatever the root cause was, it was causing the bytecode reader to output an incorrect sequence of bytes to the class file parser at some point. Figuring out when that divergence happened should help to locate the cause. I put some printouts in the class file parser to log the bytes it saw coming from the bytecode reader. I then ran the compiler on a failing test and diffed the output between the working compiler and the faulty version, it was then easy to see that the outputs diverged just a few hundred bytes into one particular class file.

When I knew where in the class file the outputs diverged I could run the compiler in a debugger and set a breakpoint right before it reached that point. I single-stepped through to see what was happening call-by-call, and I saw that the problems started appearing right after a call to InputStream.skip(). I looked again at the documentation and saw that skip() is not guaranteed to always skip ahead the specified number of bytes. The code in the bytecode reader seemed to assume that though, because there was only one call to skip(). The correct way to use skip() is to call it repeatedly, using the return value which indicates how many bytes were actually skipped:

int remaining = bytesToSkip;
while (remaining > 0) {
  remaining -= in.skip(remaining);
}

The original input stream, the custom-made one, always ensured to skip the specified number of bytes, so when it was replaced by BufferedInputStream, which does not always skip the given number of bytes, things went wrong in the code that assumed all input streams worked the way the custom-made one did!

This is a valuable lesson in programming: even if you use one class that follows a specification by another that follows the same specification, you might end up breaking your code! This was not the first time I’ve had this kind of problem, and I suspect that it is a common and especially difficult to diagnose error in programming. A recent and wide-spread example of this type of problem is HashSet ordering in Java 8, where the iteration order has changed since the Java 7 HashSet implementation. This is all within the specification for a HashSet, but many uses inadvertently depended on the order being deterministic and switching to Java 8 then breaks the code.

No Comments on Breaking code by switching input streams
Categories: Uncategorized

Player Rendering 2015-10-17

Last year I started adding entity rendering support to Chunky, with one of the big goals being to add player rendering. Adding entity support was difficult because it required doing some large changes in the rendering code – previously Chunky could only render things that fit exactly into a single block, otherwise it broke the Octree renderer.

In version 1.3.4 I had finally added a working entity renderer, and since then I’ve been adding new entities in each version. Today version 1.3.7 was released with initial player rendering support.

Alex

The problem with rendering player entities is that there are so many features that you might expect to come with that, such as armor, skins (custom player textures), equipped items (bow, sword, pickaxe), capes, etc. You might also expect to be able to reposition the players and pose them, adjusting the arm and leg directions. Most of this is not supported yet, but I’ll be trying to add some of those features in the next releases of Chunky.

No Comments on Player Rendering
Categories: Uncategorized

Chunky 2015 Fall Update 2015-09-26

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.
2 Comments on Chunky 2015 Fall Update
Categories: Uncategorized