Project Notes
Note: many of the pictures on this page are links. Click to view.
Origins of Incident
The birth of Part One is also the birth of Incident, so the origins of Incident are discussed here, under project notes for Part One.
It all began a long time ago. If you look into your 3DStudioR4 meshes -directory, there is a 3DS file called 50PMAN.3DS. It's a model of a man. This was the basis for my alien. At first all I did was that I stretched the head and bent it a little to resemble the alien head. I thought it looked pretty promising so I reworked it a little, moving the vertices around one by one. Then I bent a couple of tubes around and over the shoulders. After that I prepared a couple of texture maps with PhotoShop. Basically I combined some scanned pictures with something I drew with the airspray tool. I mapped those maps on the aliens limbs, torso and head. After this I thought the thing was really starting to look like an alien. Then I made the arms a bit longer and reworked the hands and the feet. (Alien has twelve fingers, two "thumbs" in each hand.) Then I added the four "tubes" into the back and a tail (which had six joints at this point). With this model I made a short animation of an alien standing up from a crouched position. The animation was simple, but impressive. It was really something to actually see the digital alien move - the possibilities were endless. From there on, there was no turning back.
Part One: First Contact
So I had a crude
model of an alien - what next? Well, the head wasn't very good. The worst part
of it were the stretched faces on the top. They made highlighting look goofy
and they couldn't be repaired. So I had to make a new head from a scratch.
This was not easy, as I had no other modelling tools than the ones in
3DStudioR4. Basically the head is a loft. And not a very simple one at that.
The entire jaw and the teeth I made with the brain-cracking method of
tesselating and vertex-moving.
When I had a new head, I found that I also had to completely rework the shoulders, the tubes in the back and the tail. After I was finfished with the tail, it had 24 joints. Compared to the previous 6-joint tail, it looked a lot better.
In fact, the whole thing looked a lot better. At this point it was starting to look quite convincing even to those who didn't know how difficult it is to model something as complex as an alien being.
All this work had taken months and a screenplay was taking form. First I was aiming at just one minute of animation: one corridor intersection, a couple of short camera shots. But by the time I had a corridor intersection, 3D modelling had become a permament hobby and I thought, why stop. That's how I came up with the idea of a series. An animation series of indefinite length should provide endless modelling opportunities. As well as coding since I noticed early on that making this kind of animation requires a lot of coding.
This in mind I started to branch off to several
directions. I wrote some history of the Incident world, I created characters
for future parts of Incident, etc. And I added the asteroid-claiming operation
in part one - first and foremost this meant designing and modelling the
spaceship, Morgan Le Fay, the claming-pod and the asteroid. Inside the ship,
where I already had a corridor, I added another and a "kitchen" between them.
To the animation I added the long camera shot moving from a corridor to the
other. I also made the actual encounter of David van Lint and the alien a bit
longer. This brought the animation up to over three minutes in length.
Originally the long camera shot was twice as long - I thought it best to cut
it in half, which made the animation come down to the final length of about
three minutes.
After all this it was time to make a program to actually play the animation. Of course I had one for myself but it wasn't good enough for distribution. I had planned to include opening and closing titles from the start. I included this in the player as well as JPEG display capability for future Incident parts.
It all sounds so simple and easy when I list the things that I've done, but believe me, It wasn't easy and it took a lot of time. Just the coding of the player took months! Not full-time work of course - I am trying to study here, you know (at Helsinki University of Technology).
Goals
For Part One, there were no goals. It started as a test and continued as an experiment. Only after I had a finished animation I was sure that I was going to release it. And it shows: there are a lot of mistakes in Part One. So many that it's useless to list them here - basically whenever you see something that just doesn't look right, it was left there because I was in a hurry ...
Outcome
Considering that there were no expectations, Part One is pretty good. The modelling is far from perfect here and there. I'm a bit embarrased about the animation of the alien and the victim ... as a defence, it isn't easy with keyframing; IK helped only marginally. The asteroid-claiming turned out almost like I envisioned it.
Points of Interest
Movement of Morgan Le Fay
First the asteroid goes up, a bit later it goes down - what is going on? Morgan Le Fay is accelerating "up" at 1G, that is, 9.81 m/s2. So, relative to the asteroid, Morgan Le Fay is falling "down" when it first passes the asteroid, but since it is accelerating "up", it stops the fall and starts going "up" to meet the asteroid again. Morgan Le Fay's constant acceleration is also the cause for the "gravity" inside the ship.
The asteroid
The mesh for the asteroid was made with the all-too-familiar tesselate & modify -method. Instead of modifying by hand, I cooked up some C code to add random numbers to the vertex position coordinates after each tessellation. This is a well known method and there are even several utilities for making fractal landscapes in this way. I couldn't find one that would have done the same thing to a cube so I had to do it the hard way.
The asteroid's bump map also required some programming. Pictures of craters are obviously available on the net. These won't do, however, if you want to do it right. Firstly, they're not elevation maps and secondly, they don't loop at the edges. A short piece of code came up with the correct map. With simplified craters, of course, but one can't have everything. I combined that with a fractal and a picture from NASA, and I got what I needed.
Mapping the texture on the asteroid was a compromise. Planar mapping would have stretched the texture uncomfortably and all other mappings have singular points (this is commonly a problem with roughly sphere-shaped objects). The compromise was to map the asteroid sylindrically and then map the faces at the sylinder ends separately. This makes the face edges visible wherever the mapping changes. Luckily, this was not a problem in the particular shots that the asteroid was needed for.
Why the flashing lights
Truth is: because I happen to like flashing lights ...
Well there is also a simple reason in the storyline. Last time Morgan Le Fay was in repairs at Tau Ceti 3 orbital dock, some of the lights on level 1 got replaced from a defective batch. Hence, they started flashing. Nonfunctional lights are very rare, so there weren't enough spare lights to replace the bad ones. Those lights will probably keep flashing until the next visit to an orbital dock.
Camera filter
Here's another bit that required a couple of tricks. I wanted a halo around the light sources in the asteroid-claiming operation. I had no plugin to do this with, so it was back to coding once again. The final animation was to be in grayscale, so I used a channel in the RGB data to signify a light source. For example, in the above shot in the rendered data the pod light would have been blue. The code then would turn everything blue into white and add a halo around it. This was again simple but effective - the result looks pretty good.
Yet another shot ruined
Here's another example of an easy-to-repair mistake that was left unrepaired because I didn't have enough time. On the wall behind the alien's head you can see a row of black pixels that look like they just don't belong there. This is the projection of the falloff cone of a spotlight. I don't know why 3DStudio did that - it should not have done it. It would have been easy to repair by modifying the falloff of the spotlight out of the frame and re-rendering.
Last updated 1997