Dev Blog: Alpha Outlines

Hey guys,

In this blog post we are going to take a look at the use of alpha, and the horrible artifacts that can occur in it’s implementation. There are a wide variety of shaders that utilize the alpha channel of a texture to create transparent objects. These can range from glass to grass, but we are focusing mainly on how alpha can get those garish white or black outlines even though the alpha channel is crystal clear.

The problem lies essentially in mipmapping, which is texture LoDing (Level of detail) using texture compression. So we need to understand that when the texture is compressed or mipmapped, the texture is changed from how one painted it. This is effectively rescaling the image and blurring the alpha.

Suddenly the texture that was once saying only show the nice tree leaves, is now telling the shader to show a slightly larger outline around the shape, due to the blurring of the texture. There are few options available here.

• Don’t use mipmaps and texture compression (such as disabling them in unity).

• Paint your own mip maps.

• Paint an average approximation of the colour filling the rest of the texture.

By far the easiest and quickest solution is to fill the background of the image with a colour close to the borders of your image.

Alpha can cause a lot of annoying little problems, and I see this one pop up all the time. I hope it can help you guys out and if you have any tips for working with Alpha images, leave a comment.

Tim out.

Oculus Rift Day 2: Developing with Unity 3D

Our engine of choice is Unity 3D and luckily enough, thanks to the great folks at Oculus, it has day 1 development support for the Rift. Not just token support either, this stuff is robust and documented. You can download the OVR library from the Oculus dev portal, and it plugs into Unity as easily as any Unity Package, a double-click and you're away.

Oculus provides prefabs for their two-camera setup, including one with a basic character controller. Adding basic Rift support to your games is as easy as choosing which prefab to add.

Unfortunately the Unity preview window can't go full-screen, so unless you like headaches, testing your game with the Rift requires a quick build. The Oculus plugin provides a button to make this an express procedure.

There are a few issues to be aware of regardless of the game you make; camera clipping through your avatar's shoulders, the low resolution making distant detail and text difficult to read, and rendering everything twice from two cameras. Like any hurdles in game development these can be addressed with time and effort.

Overall the process is essentially painless. Kudos to Oculus and Unity Technologies for this great integration.

Join us next week for our experiences playing a few Rift-ready games and some predictions for where VR goes from here.

Oculus Rift Day 1: Set up and Demos

In case you missed it Cardboard Keep received our two Oculus Rift developer kits on Tuesday. We were early backers of the Kickstarter and have been itching to get them ever since, and finally the day arrived. Since they're currently occupying the majority of our attention it seemed like a good idea to document some of this process.

Set Up

Attaching a Rift dev kit to your computer is the most painless experience possible, and puts other peripherals to shame. There are no drivers or custom set up hassles, it's literally plug and play. The only thing to take care of is setting it as your primary (or duplicated) monitor and setting the right resolution, and some software (like Team Fortress 2) even takes care of this for you.

Using the correct focal lenses and adjustments make or break the experience, and add a lot of downtime when switching between people with different eyesight.

As for using the device itself, as has been said all along, the low resolution is a big issue and is noticeable immediately, making it hard to discern details or read text from even a moderate distance. The other key function of the Rift, the sensor tracking, is phenomenal, with the only disappointment being the lack of positional tracking. Both of these issues should hopefully be fixed by the release version hardware.

Demos

There were only a dozen or so demos already available on Tuesday and there aren't many more now, but it's still early days. We've tried everything we could find and there are many different preferences across the team.

Proton Pulse - Calum and Rob's favourite

This demo, the third or fourth we tried, immediately grabbed Calum and Rob because of it's great atmosphere and use of the Rift itself as the (only) input method. The game plays like a first-person breakout where you play as the bat, and it is fantastic.

RiftCoaster - Tim's favourite

The name says it all; an Oculus Rift Rollercoaster. This seems to be the first public non-Epic made Unreal Engine demo, and rockets you through a coasterized version of Epic Citadel.

Sixense Tuscany - Blair's favourite

The basic Tuscany demo made by Oculus themselves was repurposed by Sixense as a demo for their motion controller, the Razer Hydra. It takes the basic walk-and-look gameplay of Tuscany and adds hands, physics objects you can grab and some you can set on fire. While the Hydra itself has accuracy and stability problems - even more prominent next to the perfect tracking of the Rift - the demo is impressive and unique, and it shows the promise that a motion controller with functionality as solid as the Rift itself could lend to the VR experience.

Planet1 - Glenn's favourite

Planet1 is a basic hover-car/Mars rover hybrid that gives you atmospheric flight controls across an alien surface while being bombarded by meteorites. It demonstrates scale and velocity from the eyes of the Rift. Glenn loves this demo because controlling a vehicle delivers a more immersive feel than a biped when your legs in the real world are staying still.

Join us tomorrow for a first-look into developing with the Oculus Rift and Unity 3D!

Announcing Up, Up and Awry!

Created in just 48 hours, Up, Up and Awry is the story of a cheapskate private space company told via the medium of a silly rocket builder.

Visit the game page to download it now for FREE!

Love it? Hate it? Let us know! Reply to this post, email us, or leave a comment on our Twitter or Facebook.

Dev Blog: Two Constants of Game Development

Hey guys and gals, I’d like to talk about two concepts I've discovered in my experience to be constants any time you develop games. Hopefully arming yourself with this knowledge can help defend against some potential issues of game development.

#1.  As a project approaches completion the appearance of progress exponentially slows.

"The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time." —Tom Cargill

People completely new to game development aren't familiar with this concept, and those just wetting their feet are conscious of it but probably don’t allow time to plan for it. (Methods like burn-down charts exist to solve this problem.)

Even worse is the accidental ignorance of the difficulties faced by other development disciplines, or all disciplines for non-developing managers/stakeholders.

• To those who aren't programmers, with each feature that is added more things break. Old things break, new things break, and they all take time to fix.

• To those who aren't artists, even if you think something looks great the artists will still want to improve it, and just like code, each art revision takes longer too.

#2. The chance of “burn out” increases both with project length and project intensity.

Burn out is when developers get sick of working on a singular project or aspect. They tire of the similarities of their day to day work and lose both motivation and the quality of their work.

Burn out occurs not only when a developer spends a lengthy amount of time on a project, but this can be accelerated if the project is particularly intense; requiring long hours, stressful conditions, or tough challenges to be overcome.

In our experience the best way to mitigate burn out is to provide short term breaks, and long term partitioning. In the short term, the entirety of a single day should never be spent on a single project, breaks should be taken to work on research or side projects, which also has the benefit of pushing several carts uphill at once. Looking at the bigger picture, you should be prepared to partition a project at the first signs of burn out; spend a whole week or longer on a side project or prototype, then you can come back with a fresh point of view and no burn out!

Make sure to watch for and plan against these issues in your projects to keep your team happy and your project on track!

Until next time, Calum.