Skip to main content

A star field WebGL demo application with three.js

WebGL with three.js

As an avid gamer I've always been interested in what it might take to create a simple game. I started looking into frameworks and ways to develop and publish games across multiple platforms using things like Steam, Python, or Javascript. I've been interested trying to span both desktop and mobile devices with the same codebase.

I stumbled across three.js, a javascript library, and it looks like a great framework to get started with WebGL development. I thought it might be neat to put together a star field simulation demo to start to learn more about WebGL and refresh some of that college computer graphics material. With some guides and examples of three.js I put together the demo application in the window below.



If you see the star field simulation above then you've got WebGL support in your browser. If not you'll want to search on the web about how to enable WebGL in your browser, or get a browser like Chrome that has WebGL support. I'm using Safari under OSX and had to jump through a few hoops to enable WebGL support, for some reason Apple doesn't enable it by default.

I pulled in the stats.js library to show frame rate. This is the box in the upper right that, when clicked, toggles between showing frame rate and frame rendering time. three.js tries to maintain 60fps.  If your application is doing too much, such as creating a ParticleSystem with a large number of points or adding too much processing to the render loop, the stats window will let you quickly see if your computer can't maintain 60fps.

In the upper right is dat.gui. This helpful module made it trivial to expose the speed setting of the particles and to allow showing / hiding the stats window.

Start to finish it took me about three hours to put together the star field demo with no prior three.js experience. three.js an impressively well documented and supported framework with tons of examples and great support on stackoverflow.

Publishing the demo

Then came the question of deployment. A simple javascript application like this could probably get away with linking to web versions of three.js, stats.js and dat.gui and in fact I am linking to the web version of stats.js off of GitHub (through rawgit.com so the Content-Type is correct for browsers like Chrome that won't run javascript if it comes across as text/plain). For the rest of the files, the index.html, the particle image file etc, I needed a place on the Internet to put them so they could be loaded when the application started up.

It turns out that Google Drive supports hosting websites, and supports hosting any kind of file. The only trick was to disable file conversion on upload of known types. Otherwise Google Drive was converting the index.html file into a document and losing all of the javascript, the only important part in the file. Once this automatic conversion feature was turned off I was able to upload the supporting javascript, the index.html and the image used as the texture map for the stars in the star field. If you right click on the star field application you should be able to open it in its own tab. Notice the crazy looking Google Drive URL that corresponds to the shared folder in my drive account. Using Google Drive to host website files was a piece of cake.

I'm relatively happy with the look of the star field. I did try for a while to implement a far field of stars to better represent how I would imagine open space to look. I had trouble getting this to look good. On Safari on a MBPr the sub pixel dithering made the far stars look great, some were bright, others dim. Under Chrome on the same MBPr the far field appeared as bright 1 pixel points. In the end I decided to get this more simple example done and complete this post.
Labels:

Comments

Post a Comment

Popular posts from this blog

Debugging an imprecise bus access fault on a Cortex-M3

This information may apply to other cortex series processors but is written from practical experience with the Cortex-M3. Imprecise bus access faults are ambiguous, as noted by the term "imprecise". Compared to precise bus errors, imprecise errors are much trickier to debug and especially so without a deep understanding of arm processors and assembly language. Imprecise and precise flags are found in the BusFault status register, a byte in the CFSR (Configurable Fault Status Register). BusFault status register bits The definition for imprecise and precise bits is: [2] IMPRECISERR Imprecise data bus error: 0 = no imprecise data bus error 1 = a data bus error has occurred, but the return address in the stack frame is not related to the instruction that caused the error. When the processor sets this bit to 1, it does not write a fault address to the BFAR. This is an asynchronous fault. Therefore, if it is detected when the priority of the current pr...
5 comments
Read more

Travelling on Spirit airlines out of Boston Logan airport? Here are some tips.

I attended CES 2017 in Las Vegas. Booking the trip late I ended up on Spirit airlines. It was both non-stop, making it six hours to Las Vegas from Boston, and affordable, less than $300 for a one way trip compared to around $700 with JetBlue. Here are some tips that might help you when travelling on Spirit from Boston Logan airport. Eat Spirit is located in the B-terminal, gates B-37 and 38, with its own TSA security checkpoint. While it does have restrooms and places to sit the food selection is limited to a single food stand. I'd recommend eating at the Legal C Bar (number 77 in the image below) prior to going through the terminal security checkpoint. The food and service there were great. Drink The water and other drinks are cheaper if you buy them at the food cart rather than on the flight. Seats The seats on Spirit don't recline. They do this to reduce weight, seat cost, seat maintenance costs, and so seats don't impact the free space of other passengers,...
3 comments
Read more

Yocto recipe SRC_URI for a BitBucket / GitHub ssh git repository

This is a particularly geeky post but because Google searches didn't turn up any information I thought it would be helpful to document the issue and solution for others. I was writing  Yocto recipes that pulled from BitBucket git repositories in ssh form and ran into several issues getting a SRC_URI that worked. GitHub uses the same syntax for their ssh repositories. A BitBucket / GitHub git url, in ssh form, looks like: < username >@bitbucket.org:< account name >/< repository name >.git a more concrete example for a git repository in one of my BitBucket accounts looks like: git@bitbucket.org:cmorgan/somerepository.git Yocto recipes can pull from git repositories by setting the SRC_URI variable appropriately. Unfortunately you can't just do: SRC_URI = "git@bitbucket.org:cmorgan/somerepository.git You'll get errors because the Yocto won't know what kind of url this is. You need to specify the protocol for Yocto to k...
2 comments
Read more