Part III – Externalizing the panorama assets

There is an issue with distributing source code for your demo’s. Besides demonstrating what you want to demonstrate, you give people a look at how you program. But the focus is not how I program, it’s demonstrating the concepts of creating interactive panorama’s with hotspots that light up. This means I have to find some middle ground in which the code is kept to the bare minimum without hardly any framework classes or complex program structures, while keeping the example readable and extensible.

Therefore I decided to open this post with a little information on application structures. Probably one of the hardest parts of programming is rising to/with the correct level of complexity. You want to be prepared for anything, but not over complicate things (KISS).

So what do you choose for your application structure? You can choose one of the many frameworks, or you can roll with your own. And after that, do you apply that framework to any application you write?

Personally I love to use a setup which allows me to refactor fast, so I can keep the application as simple as possible and then go more complex when needed. This might not always be preferable when working with larger teams, but for these tutorials, for me it is a nice way to work.

Read more

Part II – Improved Panorama

In the previous panorama post I mentioned a number of issues that would have to be fixed. For this demo I used another image from, who has a set of amazing images, so it’s really worth to go there and take a look (the other images in the flickr equirectangular group are very good as well btw).

So in no particular order, what did we add/fix in this version?

The clipping issue was described in the previous post.

The seams were a surprise to me. I thought the render process caused the seams, and that I would have to fix it by making the planes slightly overlap however, that didn’t fix it, it only made things worse. Then I discovered that the seams were caused by the bitmapfill repeat parameter which was set to true, when smoothing was turned on for the planes. If you remember, this setting was switched on to prevent drawing lag when points crossed the diagonal of drawn triangle. Since that will never happen when rendering the inside of a cube with our field of view setting, we can safely turn it off. And poof ! No more seams.

(Fluid) motion
I updated the mouse and key movement and added mass. The slight delay after you press a key is now gone as well. See the render function for more info on this.

Correct rotation
The rotation is correct. In order to implement that, we needed to keep the original points untransformed, and store a transformed copy of those points as well. Using two rotation matrices, one for x and one for the y direction, we can correctly transform these points each render pass (but only if we have moved).

Field of vision
I implemented a somewhat more scientific way of calculating the projection plane distance based on a field of view parameter. Please refer to the sources for more info.

What’s next?
We fixed a number of minor other stuff as well and cleaned the code a bit, so we are slowly getting to where we want to be. In the next version I will refactor the DistortedPlane class into a more specific custom PanoCubeSide class to make the performance even better, although I think that for actionscript 2 it is pretty solid already.

In addition we will look at externalizing the images and the implementation of hotspots in the next version!
Demo and download after the jump!

Read more

Part Ib – Intermezzo Improved Quad Clipping

You may or may not have noticed, but the clipping procedure in the DistortedPlane class we’ve been using can be improved, since it allows for false negatives. This is demonstrated when turning around fast in the panorama from the previous post: white triangles (or whatever your background color is) will pop up.

What is going on?
Basically our clipping method tests whether one of the four corner points of the quad-to-render is within the clipped region. If true, render, if false, skip. That test is very easy to understand: “hey part of me is within the visible region, so render me!” Unfortunately it is also very wrong.

Take a look at the following image:

Wrong clipping method

Read more

Part I – Panorama prototype

So, after all the posts about rendering image planes we are finally getting to our first panorama implementation. You can test version 0.1 on the left, but be sure to read the 'Issues' section for an overview of stuff to fix in the next versions.

Basically it is nothing more than just another cube like we had in the previous example, but now the cube is centered around our camera at (0,0,0) and we are looking at the planes on the inside of the cube.

Read more

Part IVc – Intermezzo Automatic Mesh Density Reduction

One of the things I wanted to try was to automatically reduce the mesh density of a plane based on it's current size. So instead of determining beforehand that a plane has to have 6 by 6 subdivision, you would simply say something like make sure no subdivision is bigger than 30 x 30 pixels.

In effect it's a very simple LOD modifier or Level of Size modifier if you will.

Is this usable? Well there are a number of considerations:
Read more

Part IVb – Intermezzo Magic Cube

After some minor adjustments to the DistortedPlane class it was possible to render more than one plane at a time (the interpolatedPoints array was static...). Class has now been extended with a front and backside material, and here is a small demonstration of putting a number of planes together.

The material was a quick paintjob done in Photoshop on my wacom.

One major thing is that I found the solution to a certain problem: the player locks up when drawing certain bitmapfills using smooth set to true. The fix is to also set repeat to true. Hope that fixes it for you as well.

Click to activate!

Download the sources here: 3d Cube (677).

Part IV – Perspective Plane Rendering

We are getting closer and closer to generating an actual cubic panorama. In case you just jumped on in from elsewhere, I'm working on a project in which I have to create a cubic panorama with hotspots that light up and it has to be in AS2, so this is my journal on the way there. In the previous post we learned how to split a plane into multiple segments to reduce the texture distortion errors. We also mentioned that perspective is not the same as distortion. I played around a bit with perspective in the GridRider intermezzo post, which I will convert into a full game as soon as I'm done with these tutorials. After yet another short night with caffeine and Volbeat to keep me awake, it's 10 AM on a rainy Sunday morning, good excuse to post the next bit!

Read more

Part IIIb – Intermezzo GridRider

Another fun thing you can do using triangles. Hacked together but performs ok for AS2, runs at about 20% CPU. Click to start and turn the volume up!

Part III – Plane rendering


You can download the DistortedPlane class and examples here Distortedplane (1277).

In the previous example we saw how to render arbitrary triangles, and we showed an example of how to reduce the equations in right-angled cases. In this post we are going to look into rendering a plane. We will do so without any perspective correction for the z-axis, and as mentioned previously distortion is not perspective. (A good treaty on this can be found here

So distorting a plane instead of a triangle. This has been done before and more than once, by Ruben, Sandy, Phillipe van Kessel and probably more.

Read more

Part II – Arbitrary bitmapfill transforms


In the first post in this series, I discussed and explained matrix transforms and how they could be used to map a bitmap into an arbitrarily drawn triangle. However we saw that if we are ever going to render larger planes in 3d, mapping a single bitmap onto a single rectangle (or 2 triangles) will not cut it, since in order to counter the gruesome texture distortion created by the affine transforms, we will have to subdivide a plane into smaller planes. Note that this is still not perspective correct, it is simply a distorted bitmap with less texture distortion through subdivision. A grid that respects the perspective or rather z-depth of the vertices is up for another post.

Subdividing the plane means we end up with smaller rectangles, that contain smaller pieces of the texture (bitmap). So we are no longer mapping a complete bitmap to a rectangle or triangle, but just pieces of that bitmap.

subdivision sample

Looking back at the first post, we derived the transform for a complete bitmap fill using the following formulas:

Read more