I’ll also be showing you how to use FLARToolkit, RenderLayers, and loads more. I may even share a few little tips and tricks from the epic Big and Small project! Read a full description of the Papervision3D training course at Flash on the Beach.

And I look forward to welcoming you to Brighton!

But this year Adobe have ruined our fun by blatantly covering speakers full expenses including flights and hotel!

Seriously though I think this is a major improvement. It sometimes feels like I only complain about Adobe and so this is a good opportunity to prove that I can be positive about them sometimes! I think it’s pretty much down to the efforts of Ted Patrick who I’m fairly certain has been beavering away in the background trying to make this happen.

I have no doubt that it’ll encourage speakers who have exciting work to share with the community and it sends a good message out to speakers that Adobe appreciate their contribution to their conference.

Of course the irony is that they haven’t invited me to speak this year. I won’t hold it against them.

You may have noticed that I’ve been a little quieter than usual over the past few months. And for that, I’m sorry. But there’s a very good reason for that! Me and the my very talented colleagues at Plug-in Media have been hugely busy working on the biggest and most ambitious Papervision3D project we’ve ever attempted; Big and Small.

Big and Small from Plug-in Media on Vimeo.

Big and Small is a comedy TV show for kids (3 to 6) about a big character (called Big) and a small character (called Small) who, despite their differences, are the very best of friends.

There are so many details that I want to share, I’m not sure where to start! There’s the close collaboration with the BBC and Kindle (the TV show’s production company). And then there’s the studio sessions with Lenny Henry (famous UK comedian) who provided the voices, and the recording of Dom’s (Plug-in’s creative director) band for the music game. Not to mention all the incredible artists, coders and producers at Plug-in who all did an amazing job of bringing it all together.

But as the head geek at Plug-in I’ll concentrate on the technology.

The first hurdle was to recreate the Big and Small house in Papervision3D; tricky, given the cluttered, busy and warm look that Dom came up with (our creative director). We spent about a month just getting the model for the living room to look right.

Many things in the living room are point sprites; a 2D image of an object that looks the same no matter which way you look at it (like the flowers). We built our own PointSprite object that uses Papervision particles to render this.

Big looks 3D and changes as you move the camera around, but he’s also a 2D point sprite. Our animator Ben rendered him on the timeline spinning around, so we work out the angle of the camera and jump to the relevant frame.

We really wanted to make sure that any 2D graphics seamlessly fit in with the 3D world, not only stylistically but also technically. We created custom 3D mesh animation to make the bed spring up and down in reaction to a 2D Small jumping up and down.

There are many clever effects that took ages to program, and although you wouldn’t necessarily notice them, we like to think they add a certain quality to the project :

The mobile in the bedroom with a custom built verlet physics system:

A custom mesh animation system for the radio in the living room, allowing our designers to animate in 2D and apply it to a 3D mesh in real time.

The mirror in the bathroom with realtime reflections.

The toothpaste particles that collide with the walls and furniture.

The lighting that changes in the bedroom when the blind is closed.

It was a massive project, and phase one alone was over 200 days of coding, not to mention the artwork, 3D modelling, sound design and music.

And brilliantly, the BBC were so pleased that they’ve also commissioned phase 2 and we’re well underway with it. Phase 1 brought you into the house, but phase 2 takes you out into the garden, with magical plants, a reflective pond, and a Doom-style mysterious woods to explore!

You can see a little more in this (very rough cut) of a behind the scenes video, exploring the less geeky aspects of the project, including collaboration, concepting, and user testing.

Making of Big and Small Rough cut from Plug-in Media on Vimeo.

It’s been a brilliant experience, Rebecca at the BBC has been a joy to work with, and it’s been really exciting to stretch what is possible in Flash and Papervision3D. I’ll let you know when phase 2 is released.

Try out the site for yourself here.

And I really would like to give major kudos to everyone on the Plug-in team that worked on this, I’m very proud to work with such talented people :

Juliet Tzabar : Production Director
Dominic Minns : Creative Director
Alan Owen : Senior programmer
Jack Lang : Programmer
Sarah Bird : 3D Modeller
Ben Mantle : Artist / Animator
Cath Lloyd : Animator (lip synching)
Lee Needham-Park : Project Manager
Kate Fowler : Sound design / production assistant
Kirsty, Ellie, Bruce (and Dom!) : Musicians

(Well done guys, you all rock!) And this project will be finished in a few weeks so we’ll be open for more projects! Can you use some Plug-in magic for your project? Need some Papervision3D expertise? Drop me a mail. seb@pluginmedia.net.

PS There’s an easter egg somewhere in the Big and Small website… can you find it?

I’m always on the lookout for ways to speed up our project work and also some of the inner workings of Papervision3D, and I must admit, sometimes it reaches fairly obsessive levels, bordering on unhealthy. In fact sometimes the minor optimisations are so insignificant, it can just be an exercise in problem solving. Which let’s face it, we all do from time to time just for fun, right?

The latest target for my obsessive compulsive attention is the triangle / rectangle intersection check that happens just before rendering. It’s way after any of the clever 3D stuff, we’re just literally looking at whether the 2D triangle we’re about to draw is within the rectangle that represents our screen.

The current check is a simple bounding rectangle check. The bounding rectangle for the triangle is calculated and we use a simple intersect check for the two rectangles. Which is simple and fast. But it was bothering me that huge offscreen triangles were not getting culled because their bounding rectangle overlapped with the viewport rectangle.

So how do you accurately check that a triangle is intersecting a rectangle? Here’s one way :

1) Check if any of the triangle’s points are within the rectangle, if yes then intersection is true.
2) Check if any of the triangle’s lines intersect any of the rectangle’s lines, if yes then intersection is true.

Check 1 is relatively simple, but if no points are within the rectangle, we have to move to check 2, and that means we have to check each of the 3 lines in the triangle with each of the 4 lines of the rectangle, 12 line intersection checks altogether. Which just felt a bit dirty to me.

But then I got to thinking, this rectangle is an AABB (or axis-aligned bounding box, which basically means that it’s not rotated), so that should make things a little easier. And I developed this little technique loosely based on existing systems but I haven’t seen anything exactly like this before. I’m not sure if it’s the best way but it seems fast and accurate to me! Here’s how it works :

1) take the first line of the triangle

2) calculate its equation and then work out the y position that it intersects the left and right edges of the rectangle

3) take the maximum and minimum y bounds of those two intersection points and calculate the overlap between those and the max and min y values of the line.

4) if these new overlapping min and max y values overlap the top and bottom of the rectangle then the line (and therefore the triangle) must intersect the rectangle, so return true.

5) Otherwise move on to the next line of the triangle and try again.

It seems to be much more accurate than the existing bounding rectangle check and for positives is 30% faster. For negatives it’s about the same or a tiny bit slower. The only innaccuracy I’ve found is if the triangle is entirely containing the rectangle it returns negative. And also I should put in a check for vertical lines and do a simpler check on those.

But my challenge to you! Can you get this to be slicker / faster? I’m sure there are some maths wizards out there. Full code below and you can even fork it and have a play at the rather awesome Wonderfl

I realise that you could unroll the method call to triangleAABBIntersectionTest but I’m more interested in improvements to the maths/logic.

Good luck!

package
{
   import flash.display.Graphics;
   import flash.display.Sprite;
   import flash.events.MouseEvent;
   import flash.geom.Point;
   import flash.geom.Rectangle;
   import flash.text.TextField;
   import flash.text.TextFormat;
   import flash.utils.getTimer;
   [SWF(frameRate="100", backgroundColor="0x000000", width="500", height="500")]
 
   public class TriangleAABBSpeedTest extends Sprite
   {
 
 
      public var outputText : TextField;
 
      public function TriangleAABBSpeedTest()
      {
         super();
         outputText = new TextField(); 
         x = y = 250; 
         outputText.defaultTextFormat = new TextFormat("Arial"); 
         outputText.textColor = 0xffffff; 
         outputText.text = "Click to start test"; 
         outputText.x = outputText.y = -250; 
         outputText.width = 500; 
 
         addChild(outputText); 
 
         stage.addEventListener(MouseEvent.MOUSE_DOWN, startTest); 
 
      }
 
      // I'm thinking that storing these values as properties rather than declaring them as local vars 
      // should be faster...
 
      private  var x0 : Number; 
      private  var y0 : Number; 
      private  var x1 : Number; 
      private  var y1 : Number; 
      private  var x2 : Number; 
      private  var y2 : Number; 
      private  var l : Number; 
      private  var r : Number; 
      private  var t : Number; 
      private  var b : Number; 
 
      private  var top_intersection:Number ;
      private  var bottom_intersection : Number; 
      private  var toptrianglepoint : Number; 
      private  var bottomtrianglepoint : Number; 
 
      private  var m: Number;
      private var c : Number   
 
 
      // THESE ARE THE TWO FUNCTIONS YOU CAN OPTIMISE. 
      // I realise that you could inline the lineRectangleIntersect method, but I'd rather not do that just yet... 
      // I'm looking for maths/logic improvements. 
 
      public function triangleAABBIntersectionTest(rect:Rectangle,  vertex0:Point, vertex1:Point, vertex2:Point ) : Boolean
      {
         // YOU MUST LEAVE THESE DECLARATIONS; they simulate necessary data exchange within PV3D
         l = rect.left; 
         r = rect.right; 
         t = rect.top; 
         b = rect.bottom; 
 
         x0 = vertex0.x; 
         y0 = vertex0.y; 
         x1 = vertex1.x; 
         y1 = vertex1.y; 
         x2 = vertex2.x; 
         y2 = vertex2.y; 
 
 
         return lineRectangleIntersect(x0,y0,x1,y1) 
               ||   lineRectangleIntersect(x1,y1,x2,y2) 
               ||   lineRectangleIntersect(x2,y2,x0,y0);
 
 
 
      }
 
 
      public function lineRectangleIntersect(x0: Number,y0: Number,x1: Number,y1: Number):Boolean //, left:Number, right:Number, top:Number, bottom:Number) : Boolean
      {
 
            // Calculate m and c for the equation for the line (y = mx+c)
            m = (y1-y0) / (x1-x0); 
            c = y0 -(m*x0); 
 
            // if the line is going up from right to left then the top intersect point is on the left
            if(m>0)
            {
               top_intersection = (m*l  + c); 
               bottom_intersection = (m*r  + c);
            } 
            // otherwise it's on the right
            else 
            {
               top_intersection = (m*r  + c); 
               bottom_intersection = (m*l  + c); 
            }
 
            // work out the top and bottom extents for the triangle
            if(y0<y1)
            {
               toptrianglepoint = y0; 
               bottomtrianglepoint = y1; 
            }
            else
            {
               toptrianglepoint = y1; 
               bottomtrianglepoint = y0; 
            }
 
            var topoverlap : Number; 
            var botoverlap : Number; 
 
            // and calculate the overlap between those two bounds
            topoverlap = top_intersection>toptrianglepoint ? top_intersection : toptrianglepoint; 
            botoverlap = bottom_intersection<bottomtrianglepoint ? bottom_intersection : bottomtrianglepoint; 
 
            // (topoverlap<botoverlap) : 
            // if the intersection isn't the right way up then we have no overlap
 
            // (!((botoverlap<t) || (topoverlap>b)) :
            // If the bottom overlap is higher than the top of the rectangle or the top overlap is 
            // lower than the bottom of the rectangle we don't have intersection. So return the negative 
            // of that. Much faster than checking each of the points is within the bounds of the rectangle. 
            return (topoverlap<botoverlap) && (!((botoverlap<t) || (topoverlap>b)));
 
      }
 
 
 
 
 
 
 
 
 
 
 
      public function startTest(e:MouseEvent = null) : void
      {
         var g : Graphics = graphics; 
         g.clear(); 
         var cullingRect : Rectangle = new Rectangle(-100,-75,200,150); 
 
         var iterations : int = 100000; 
         var timerIntersecting : int = 0 ; 
         var timerNotIntersecting : int = 0 ; 
                        var intersectCount : int = 0; 
 
         var v0 : Point = new Point(); 
         var v1 : Point = new Point(); 
         var v2 : Point = new Point(); 
 
         var i : int = iterations; 
 
         while(--i>-1)
         {
            v0.x = Math.random()*400 - 200; 
            v0.y = Math.random()*400 - 200; 
            v1.x = v0.x+ (Math.random()*300 -150); 
            v1.y = v0.y+ (Math.random()*300 -150); 
            v2.x = v0.x+ (Math.random()*300 -150); 
            v2.y = v0.y+ (Math.random()*300 -150);             
 
            var startTimer : int = getTimer(); 
            var intersecting : Boolean = triangleAABBIntersectionTest(cullingRect, v0, v1, v2); 
            if(intersecting)
            {
               timerIntersecting += (getTimer() - startTimer);
               intersectCount++; 
            }
            else 
            {
               timerNotIntersecting += (getTimer() - startTimer);
            }
            if(i<300)
            {
               g.lineStyle(0,0x000000); 
               g.beginFill(intersecting ? 0x006600 : 0x660000,0.5); 
               g.moveTo(x0,y0); 
               g.lineTo(x1,y1); 
               g.lineTo(x2,y2); 
               g.lineTo(x0,y0); 
               g.endFill(); 
            }
         }
 
         g.lineStyle(0,0xffffff,0.5); 
         g.drawRect(cullingRect.x, cullingRect.y, cullingRect.width, cullingRect.height); 
         outputText.text = "Average time per triangle : "+(timerIntersecting+timerNotIntersecting)/iterations; 
         outputText.appendText("\nAverage time per intersecting triangle : "+(timerIntersecting)/intersectCount); 
         outputText.appendText("\nAverage time per non-intersecting triangle : "+(timerNotIntersecting)/(iterations-intersectCount)); 
 
      }
 
   }
}

For starters, the display didn’t use scan lines like a normal telly, instead, the cathode ray moves around to make shapes, the same way that laseriums used to make pictures with lasers. (If you don’t remember the 80s you’ll probably have no idea what I’m talking about).

Secondly, it’s actually very, very difficult. So you feel a real sense of achievement when you actually land the thing safely! I was actually lucky enough to see an original vector based arcade cabinet, and the thing that immediately strikes you is how bright the screen is, and how beautiful those glowing lines are.

Sadly, Lunar Lander had a fairly limited life when it came out. It was quickly superceded by perhaps the most famous vector game ever, Asteroids. In fact most of the early Lunar Landers had their insides unceremoniously ripped out and were converted to Asteroids cabinets, so they’re pretty rare now.

A few years ago, as a tribute to the early pioneers of arcade gaming, I decided to recreate Lunar Lander in Flash, with painstaking attention to detail and accuracy! And what did I do to celebrate this great achievement? Did I shout about it from the rooftops? Did I post it on the internet for everyone to share and enjoy? Did I write a blog post about it? Well actually no, I just sat on it and it’s been laying there burning a hole on my hard drive all this time.

My flash Lunar Lander

But don’t worry, you can now play this online here to your heart’s content. Use left and right arrows, and up arrow to thrust. It’ll take a little effort to get used to, but that’s half the joy.

But that’s not what this post is about. A local Brighton geek group, £5App decided to run a 5KApp competition, where you could submit any program that was 5120 bytes or less. And you were allowed to use Flash, so I got going to see how if I could make a Lunar Lander clone within the file size limit.

I’d worked out how to use Perlin noise to create a 2D landscape and got pretty much all of the physics and collision detection working, but I’d only used about 3K.

So to make it a bit more interesting, I decided to add 3D! To create the landscape I used the same Perlin noise image to store all the data, and drew the landscape in strips from back to front, with a very basic 3D to 2D formula, and before I knew it I had 3D Lunar Lander!

Lunar Lander 3D in only 5K

My final submission was 5118 bytes, only 2 bytes under the limit! Interestingly, swfs seem to fluctuate by a few bytes every time you publish them. (My theory is that it embeds the time and date?). The one I’ve posted here on the site is exactly 5120 bytes!

Lunar Lander 3D from Plug-in Media on Vimeo.

Just like the original, it’s very, very difficult, use the arrow keys to move left, right, forward and back, and the space bar thrusts. Look out for flat landing pads of 4 lines, and head towards them. You need to go in really close, and you’ll know you’re over it as the land turns white when you’re directly over it. And you need to land right in the middle of the 4 lines, and very, very gently! See the playthrough video if you need more help.

Despite some stiff competition from the Brighton geek community, this was voted the winner! And the prize was exactly 5120 pence. So I went and bought everyone a drink with it.

It’s actually been really fun, and it’s given me a lot of ideas for future projects. I’ll post up the source with a bit of explanation soon, but for now you can play the game here.

Believe it or not over 100 people have already signed up for it, but I’m sure Tink and his friends will be able to fit you in.

I’ll be showing you how to get started in Papervision, and I expect I’ll also be talking you through our latest project for the BBC, Big and Small, which is such a huge project I feel like I should devote an entire blog post to it soon!

Papervision3D founder Carlos Ulloa will be headlining with an hour full of the tricks and techniques behind his new business venture HelloEnjoy.

“The session will focus on the techniques, workflow and planning necessary to overcome the creative and technical challenges of real time 3D in Flash, giving an inside view of the entire creation process, from concept and planning, to development and art production.”

Get yourself over to LFPUG and sign up if you’re interested in coming!

And what a amazing day it was! We had Dom (from Plug-in) playing the ukulele for us during the ceremony, and were greeted by a 70 piece choir (thanks Hullaballoo!) as we left the town hall! And later, our guests were “treated” to a song from Jenny and I along with a tap dance routine (and yes I’m sure it’ll appear on youtube before too long…)

And what’s all this got to do with the world of Flash and Papervision3D? Well, nothing. Although I’m just flying out to Thailand for a couple of weeks so I expect I won’t be returning emails for a while. But I promise it’ll be business as usual when I get back, so I’ll catch up with you then!

Step 1
Navigate to /Applications/Flex Builder 3/

Step2
Right click on the app, Flex Builder and select explore package contents. A new finder window should pop up with a folder called “Contents”

Step 3
Open the file Contents/MacOS/FlexBuilder.ini with a text editor of your choice.

Step 4
Add the following line :
-Duser.name=Seb Lee-Delisle

Except obviously you’ll probably want to use your own name

Step 5
Save the file and restart Flex Builder. Now your automatically generated comments will contain your full name after @author!

Excluding external libraries

Our project has loads of external classes in libraries (one is papervision, others are various Plug-in Media libs), and I really would rather it didn’t try to document them all in the same documentation. And I couldn’t figure out how to stop ASDocs from trying to compile the classes in these libraries.

And if you don’t include the libraries, ASDoc fails badly! So I could either include them in to the docs (which seemed to break anyway) or just exclude them. But is there a way to exclude them?

It turns out that there is, and that is to list every class that you want to exclude! Er yeah that’s probably about 2,000 classes so not going to happen!

Although there is a handy way to generate this HUGE list of classes using the AIR app Dita. But I think I’ve kinda worked out how to use ASDocs now in a way that stops you needing to do that.

Adding external swcs

The big secret that no one seemed to be telling me! If you add a swc file it no longer fails to find the classes you’re referring to. But most importantly it doesn’t try to write docs for them!

So here’s how we set it up :

Step 1 : Set up an external tool in Flex.

Open Flex Builder (we’re using FB 3). See that little green play button with a suitcase on it? In the top left? Click on the down arrow next to it and then “Open external tools dialog”.

Step 2 :

Click on the “New Launch Configuration” Button. it’s the white sheet of paper with a “+” on it.

Step 3 : Find your asdoc file.

Give it a name. Maybe ASDocs or something equally unimaginative. Then set up the Location field; click on Browse File System and find your ASDoc file in the Flex SDK. For me it was in /Applications/Flex Builder 3/sdks/4.0.0.4021/bin/asdoc. If you’re on a PC you should probably point to asdoc.exe.

Step 4 : Point to the project folder.

In the “Working Directory” field, type ${project_loc} – this will point to the project folder for whichever project you are currently in.

Step 5 : Set up the arguments.

in the arguments field point to your source path with the following two arguments :

-source-path src
-doc-sources src

This assumes that you set up your projects with the default source folder called src. So it’ll look into your project folder’s src to find all the classes to make docs for.

And then add arguments to point to the swcs for your library projects, for us it’s :

-external-library-path=/Users/seb/Documents/FBWorkspace/PluginLibs/bin
-external-library-path=/Users/seb/Documents/FBWorkspace/PluginBrain/bin
-external-library-path=/Users/seb/Documents/FBWorkspace/Papervision3D/bin

Of course this assumes that you use library projects in Flex Builder. I guess this will work as long as you have swcs for your code library. Either way you need to point at it.

I’m sure that this won’t work for all of you but I haven’t seen this approach documented anywhere so I thought it may help. And good luck!

I’m just going over my presentation in my room, and I’ve just realised I haven’t actually uploaded the working files you’ll need to work along with me!

But don’t worry you can download them here!

It’s a Flex workspace so just point your FlexBuilder 3 at it and you’ll get all the example files.

See you at 4pm!

Download the source files.