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

Graco Swing By Me - Battery to AC wall adapter modification

If you have one of these Graco battery powered swings you are probably familiar with the cost of C batteries! The swing takes four of them and they only last a handful of days. I'm not sure if the newer models support being plugged into the wall but ours didn't. If you are a little familiar with electronics and soldering, here is a rough guide on how you can modify yours to plug in! I wasn't sure how exactly to disassemble the swing side where the batteries were. I was able to open up the clamshell a bit but throughout this mod I was unable to determine how to fully separate the pieces. I suspect that there is some kind of a slip plate on the moving arm portion. The two parts of the plastic are assembled and the moving arm portion with the slip plate is slid onto the shaft. Because of the tension in that slip plate it doesn't want to back away, and because of the mechanicals that portion of the assembly doesn't appear accessible in order to free it. I was
Post a Comment
Read more

Memory efficient queuing of variable length elements

In embedded environments memory can be a critical driver of the design of data structures and containers. Computing resources have been expanding steadily each year but there are still a wide range of systems with far less than a megabyte of memory. On systems with tens of kilobytes of memory, structures are often designed to be compact to maximize data density. Rather than splurging on memory aligned elements that would be faster for the processor to access, a developer will typically use types with minimal sizes based on the known range of values that the element is intending to hold. Fixed sized buffers At my day job a fixed size pool of messages was implemented to hold message data. While this achieved one design goal of using statically allocated buffers, avoiding dynamic allocations that might fail at runtime, it isn't efficient if there is a wide range of message sizes. It isn't efficient because each message uses a message buffer. With small message sizes the buff
2 comments
Read more