Weird “invalid serialized file header” Bug Fixed

(Sort of. It’s at least better than what we did before)

The Bug

In the last post I talked about the weird Unity serialization bug that ruined all of Tuesday night, and which we were only able to avoid by sticking with an old revision of the material.

The solution wasn’t very practical though, because if you pulled any version of the material after revision, and then accidentally clicked back on Unity, it would stall and crash. This is quite easy to do, because if you checked out the project folder in Perforce, and then try to submit, Perforce will ask you to get latest version first.

If this stalled, I would have to delete the Library and Temp folders and have Unity build again. Due to the size of the project, this would take around 20 minutes.

This is clearly not at all practical.

In the previous post, I talked about the thread I found, which seemed to pinpoint the problem to the way Unity does serialization and some weird way that it’s handled by Perforce.

What we’ve been experiencing seems to confirm this, as even making the material exactly like what it was in revision 7 and then resubmitting still led to problems.


I started to wonder if maybe the problem was actually over on the Perforce server, and so when we pulled, it messed up the project.

So what I did was to delete the asset that was giving us the “invalid serialized file header”, in our case default_prototype.mat, as well as the associated meta file from the Perforce server. I also deleted them locally.

Then I opened up a new Unity project, and reimported ProBuilder (we’re using the source version by the way).

Then I copied default_prototype.mat from this new project into the original project.


Allowed Unity to generate the meta file, and then committed those to the server.

Had no idea this would work. Here are my commit messages:


Incredibly, this actually fixed the problem!


This problem had actually been bugging us for several weeks now. David had first noticed it and discovered reverting the material to older version fixed it. However, I had only been pulling the project in bits, so it wasn’t until Tuesday that it really affected me.

Anyway, really happy that this is resolved. It’s possible that another asset could have serialization messed up in the future, so I think we will take care of changing the setting on the P4 server.

If you’re experiencing the same problem, I hope this helps.

Tools Programming – Staircase Generator

There are A LOT of staircases in Manifold Garden.

In fact, some levels consist entirely of staircases:


It took way too long for me to finally get around to writing a staircase generator, but I’m really glad I did.

Now, ProBuilder does have a staircase generator, but the stairs in Manifold Garden have to be built in a very specific way.

Thin Stairs

0.5 is the smallest unit for the geometry in Manifold Garden. All the floors, walls, etc, are at least 0.5 units thick.

Since you can change gravity and walk on any surface in the game, every staircase needs to work on both sides. The player can walk on the top surface of the stairs, as well as the bottom surface of the stairs.

If the floor is 0.5 units thick, the stairs must be built like this:


Here’s how I would build it:


The individual steps are ProBuilder cubes, which I have to manually put in place. Once there are few, you can speed up the process by duplicating multiple steps at a time. It’s still quite slow though.

Then I have to make the “ghost steps”. These are the small invisible steps that the player actually walks on. The visible steps are actually too tall for the player to climb, since the player doesn’t actually have legs and is a just a capsule.

The ghost steps are made with ProBuilder staircase tool. However, it still takes time to figure out the size of the ghost steps, the number of steps, and also to put it in the correct position.

Anyway, for a long time, due to the 0.5 thickness requirement, I actually thought that all floors had to be 0.5 units thick and no more.

Thick Stairs

Eventually, I realized that there was actually a way to build stairs to allow for thicker floors. Thicker floors are actually quite nice because this means that the player can walk on the sides of the staircase as well, instead of just the top and the bottom.

The key was to stack the steps horizontally instead of vertically, like so:


As you can see in the image above, this allows for the floor to be 2 units thick while still making the staircase work from both top and bottom surfaces.

The build process is pretty much the same as that for thin steps (here I copied the ghost steps from another staircase):


Staircase Generator

Anyway, finally decided to write a tool to automate this process:


The tool automatically decides whether to stack horizontally or vertically depending on the step height assigned, and places the ghost steps accordingly. It also puts everything inside a parent object and names it with the width, height, and number of steps. It also assigns the correct tags and layers to the objects.

Here it is in action:


The tool took about a weekend to make, and now a step that was rather tedious for me, and took minutes to do, is now done 3, 4 button clicks in the span of a few seconds.



Development Update – Sorting Algorithm

Improved the water adjustment algorithm so that it’s more accurate at figuring out which water block is the closest to the source.

This is important because the stream only needs to start from this one. If you look at the gif in the previous update, you’ll see that the number of red water blocks goes from 3 to 2. This is because it messed up the count of which one was the “smallest” water block that needed to be fixed.


The problem is that the sorting algorithm I’m using to determine the water block with the smallest index number is incredibly inefficient and is causing a drop in frame rate at the point of contact:




Unity Shader Programming Resources

I’m starting to work on making Relativity look good, and that basically translates to writing shaders. It was a little difficult to pick up at first, but after searching around the web for a bit, I finally found a couple of tutorials that explained the basics pretty well. I just wanted to list them here, in case anyone else is in the same position.

  • Shader Programming (Unite ’08) - If you don’t know anything about shaders, this is a good place to start. It’s a pretty long video (around 2 hours), and parts of it can be a little slow, but it’s a good practical intro to the topic. 
  • Cg Programming Wikibook – This is a fantastic resource, and I recommend going through the tutorials in order to get a firm grasp of shader programming. It breaks down all the example scripts, so it’s pretty easy to follow along. The writing can also be quite funny at times.
  • Special Effects with Depth – Slides from a presentation given by Kuba Cupisz and Ole Ciliox and SIGGRAPH 2011 which gives a nice overview to using the depth buffer to create special effects shaders.
  • Getting Started With Custom Post-Processing Shaders in Unity3D - Post-processing shaders are a bit different from regular shaders in Unity. This blogpost goes over the basics.

Ghost Stairs

stairsWhile Unity’s default FPS Character Controller is very good, it does have a few shortcomings, such as being unable to be affected by rigidbody physics. Granted, most of the time this is a good thing, as making the player behave too realistically in terms of physics can make it quite hard to control. For example, players expect to come to complete stop when they release the move keys, which is not very realistic. There should be a period of deceleration where the player slows down after the move keys have been released. But if you actually implemented this in the game, it would just need to very confusing and non-intuitive controls.

However, there are situations where you want the character controller to be affected by external rigidbodies (such as being pushed away by a moving platform), or be able to change the up direction of your character to something other than the y-axis (for example if you want your character to rotate and walk up a wall). In these cases then, you need to take a rigidbody object, and then roll a character controller for it, so that you get all the behaviors you would normally get with rigidbody physics.

Fortunately, on the Unify Community Wiki page, there’s a very handy rigidbody controller script. While it’s pretty good for the most part, one major feature that it is lacking is the ability to set a number for degree of the incline that the character can climb up, and the height of stair steps that the character can scale. Instead, when climbing stairs, you are basically applying a force on the rigidbody character against the staircase, and pushing the character up this way. This creates two problems:

  1. Ascending and descending the stairs can be very bumpy, since going up each step is basically a collision event, and going down each step is basically a very short fall.
  2. The height of each step is very limited, and you need a large depth-to-height ratio for each step. While this may not be a problem for everyone, it does affect the aesthetics and architecture design. For example, in my game, I want each step to have a 1:1 ratio of depth to height, so that the stairs are basically at a 45 degree incline. However, in order for the player to climb this, I need to make the steps very small, at which point it no longer resembles stairs, but a slope with ridges.

After ignoring this problem for months, I finally came up with a solution after a conversation with a friend. I call the solution “Ghost Stairs”.

Basically, the solution consists of creating two sets of stairs, overlapping one another. The first set, let’s call it the “Real Stairs”, consist of the steps as you would like them to appear to the player in the game, shown in the picture below.Real Stairs


The second set of stairs, the “Ghost Stairs”, consist of steps with much smaller height increments, basically filling in the gap of the real stairs, and smoothing out the incline. In overlaps the real stairs in the same position. In the picture below, the ghost stairs are shown in green (the weird looking texture on the side of the staircase is due to the overlapping of the two meshes).

Ghost Stairs


So there are two separate meshes on the staircase. Then, when the staircase is brought into Unity, I added mesh colliders to both sets of stairs, but disable the renderer of the ghost stairs, so that the player can collide with it, but it can’t be seen. In the picture below, you can see the mesh collider outline of the ghost stairs.



This set up really fixes the bumpiness when going up the stairs. Going down the stairs was not quite as smooth, but by reducing the mass of the player rigidbody a bit, so that the player kind of floats down while descending, helped to fix that.

However, one problem that ghost stairs produces is that now, if you place a game object, like a box, on top of the stairs, it will collide with the ghost stairs and appear to be floating in mid-air. This is fixed by using Unity’s Layer Collision Matrix (found under “Physic” in “Project Settings”). Basically, I put any movable objects such as boxes in a layer called “Movable”, and then put the ghost stairs in another layer called “Ghost”, and then uncheck the box in the collision matrix to ensure that these two layers don’t collide with one another.

So finally, this is what it looks like in the game (from the scene view) when the player and a box is on the stairs:



You can see that the player is resting on top of the ghost stairs, when the box is resting on the real stairs.

Anyway, I’m pretty happy to have solved a problem that had plaguing me for quite some time, and just wanted to share the solution. Hopefully you’ve found the information here to be somewhat helpful.


L-System, or Lindenmayer System, is a mathematical formalism originally developed by the biologist Aristid Lindenmayer to describe the growth of simple multicellular organisms. While Lindenmayer initially studied algae and fungi, the L-System was eventually applied to plants and other more complicated structures.

L-Systems can also be used to generate fractal patterns. While I had done something very similar in earlier studies of branching patterns, this time around I actually wanted to see the pattern being drawn. As such, I had to create a simple turtle object that takes the position, angle, and length as the initial parameters and draws a line accordingly.

From there, it was just a matter of creating an iterative structure in the software and setting the rules as to when branches should form, at what angle, and what size. Of course, when writing iterative programs, it’s important to set a breakpoint so that it stops at some point, and doesn’t continue indefinitely. In my studies, I set it so that if the length of a branch is less than 10 pixels in length, it no longer reproduces.

Below are a few images generated by the program:

Videos showing fractals being drawn using the L-System:

Source code

Dreams of Electric Cubes

It’s been a while since I’ve written anything. Been busy re-establishing myself in Toronto. There’s a great creative scene here, and everywhere I look there’s cool stuff happening.

I’ve gotten involved with a few projects, and have also been experimenting with creating visualizations using code, specifically Processing.

Here’s a video sketch I just finished: