The red circle represents the perceived position of my eyes, and the green line is just a line that moves with a speed that is based on the circle position (when the circle is on top, the line moves up; when the circle is in the middle, the line stays; when the circle is at the bottom, the line moves down).

It uses a face tracking algorithm for initial face detection, then some other color-separating code to find where the eye is looking at in real-time. An initial calibration is necessary (the code must know when the eye is looking at the top and at the bottom of the screen; then it can find where you’re looking at, in between those two).

The face detection used an AS3 port of OpenCV, based on the work of Ohtsuka Masakazu and Mario Klingemann with a bunch of modifications for speed and varying levels of accuracy (nothing too crazy though, just better for our specific use case).

The result was SoBe’s Staring Contest, where you have to keep your eyes in a specific part of the screen to “win” the game (try the “experimental version” for the eye-tracking webcam version; otherwise it’s a mouse-based game). It doesn’t work in all situations – it relies heavily on the amount of light available at the visitor’s environment, and on the visitor’s ability to not rotate their head too much during the experience – but I still consider it a success.

As a developer, it’s very important to take some time out to try not only new techniques but also new platforms. The tools we have available for us change constantly and to keep up you need to make time for some private investigation of new methods and capabilities. This time for research & development with something that may or may not be fruitful is hard to come by, but it’s certainly of utmost importance in this career. It’s also fun, of course.

This recent presentation by Joon Park, our Chief Creative Officer, talks a little about this, talking not only about the above example but also about some other great “personal” projects by some of our developers that started as an exercise but turned out to be so much more.

P.S. As always, we’re hiring.

I love it here.

Whether you’re a student blazing your path to digital superstardom or you’re well-versed in the interactive world and hoping to expand your experience, we’re looking for the best of the best to take it to the next level as a Firstborn intern.

Our interns aren’t treated like nobodies – they’re here to gain knowledge and improve their skills by working on high level, award winning work. You’ll have the chance to work closely with the Firstborn team on a number of projects and campaigns that include strategy and planning, concept development and design,

Flash programming and animation, 3D modeling and motion graphics, video production and editing, iPhone and mobile application development… and anything else that comes to life in the digital world.

All of our intern positions are paid and you will also receive a monthly Metrocard, a roundtrip flight to NYC if necessary and other fun extras. Our internships usually last 3 – 8 months and could open the doors to join the Firstborn crew or be the jumpstart you need to launch an exciting career.

For consideration, email us a little information about yourself, your resume and a list of URLs or your portfolio to jobs.intern@firstbornmultimedia.com

You can find a full listing of the positions available here. And you can also watch our new intern video below – our homage to Nike’s iconic “Take it to the next level” spot.

No, I don’t appear in the video. I’m not photogenic enough. Or, to use my favorite excuse, I was too busy doing actual work.

Enfim, a Gringo precisa de um profissional SilverLight pra se juntar à sua equipe supercompetente de desenvolvedores. O candidato ideal irá trampar a princípio de agora até março na Gringo, desenvolvendo um projeto bem bacana. Valores são negociáveis, e é imprescindível que o profissional cumpra prazos e toque o projeto sem maiores surpresas.

Quem estiver interessado, favor contactar Mylena Mandolesi no email mylena (arroba) gringo.nu.

Acho que não preciso nem falar nisso, mas a Gringo é uma agência que mais do que recomendo a qualquer um. Pra quem curte SilverLight, esta é uma puta oportunidade de trabalhar com uma equipe extremamente criativa e competente.

Also, apparently they’re still looking for people to join their ranks on their New York and Los Angeles offices, so if anyone’s interested, here’s my recommendation of a great company to work at.

Candidates looking to join their ranks should have vast experience in AS 1/2 and breath OOP. Having AS 3 knowledge/experience is a plus, but willingness to research and learn is even better. They should love what they do and be committed to pushing the boundaries of the platform further both visually and technically with each new work. This is for full-time, on-site roles; Gringo is based on São Paulo, Brazil.

The studio is focused on creating rich advertainment websites that differ from generic websites. They have won several prizes on their relatively short life of one year and a half, including several FWA site of the day awards and a couple of recent bronze Cyber Lions on Cannes 2007. They have an awe-inspiring crew and work with some of the coolest clients from all over the world, so it’s a terrific place to work at. Apparently they also have a Nintendo Wii in the studio, although I haven’t personally certified it yet. Visit their website for more information about the company and the kind of work they do.

Interested candidates should send an email to quero@gringo.nu with all information needed – including a bit about yourself, your experience, and links to previous work.

The most recent of such challenges was implementing beziér curves on tweenings. At a simplistic level, this feature allows for an object to slide on screen by following a curved path; at a more complex level, it allows any number of properties of a object to follow a complex ‘path’ of values until it reaches its destination.

In the most basic sense, this could easily be achieved with, say, a special property. Using Tweener, it could work like this, for a sliding based on a quadratic bezier curve path:

Tweener.addTween(myMC, {_x:10, _y:10, _controlX:20, _controlY:0, time:1, transition:"easeoutquad"});

That is, the _controlX and _controlY properties actually define the location of the control point of the bezier curve, as one would expect when using, say, the curveTo method from the actionscript drawing API.

At close analysis, however, this seemingly natural syntax poses two significant problems. For one, it uses special, separate properties for control points that are hardcoded into the engine – they should know in advance which properties should be modified: _x and _y, on this case. What would happen if, instead of tweening properties of a MovieClip instance, I was tweening properties of a custom StageWindow instance, with respective cameraX and cameraY properties? I’d need to create a new hardcoded special property just for my own custom classes.

One alternative solution would be to make a guess on what should be tweened: for example, “the first two properties to be defined on the tweening parameter object will be respectively considered to be x and y”. That would work on the above case and in many other cases where bezier tweening was needed on two dimensions. It would create new syntax rules which are not exactly healthy, though — on Tweener, the parameters order itself doesn’t matter.

The second problem is that it’s limited to one control point. Paths based on bezier curves can, instead, use several different control points, allowing a more complex path to be taken. For that, the above solution would need separate arrays, or additional control point variables, and it could become quite clumsy.

Hence why a more flexible solution is needed. I spent a good deal of thought on this matter, and I honestly believe I’ve reached a good compromise. So the final syntax for bezier transitions on Tweener is as such, just as an example:

Tweener.addTween(myMC, {_x:10, _y:10, _bezier:{_x:20, _y:20}, time:1, transition:"easeoutquad"});

That is, the tweening or sliding is done the same way it’s always done – by using _x and _y properties, or whatever’s the norm at that specific language version or Class – and a bezier point can be defined by the special property named _bezier, which contains one object with the properties that define its position.

Here’s the first good point: by using the destination property names themselves when defining the control point, the bezier code already knows what to tween and how. You don’t need any other special parameter rule when writing the code – you could tackle an _alpha tweening there on the same object and it would still work – and, specially, you can use whichever property you need when doing a bezier tweening. So, for example, if you had my hypothetical StageWindow instance there, you can still tween it by using this syntax:

Tweener.addTween(myStageWindow, {cameraX:10, cameraY:10, _bezier:{cameraX:20, cameraY:20}, time:1, transition:"easeoutquad"});

That is, you just need to define your points based on the properties you actually want to tween.

The second good point is that, because of the way the _bezier special property is used – it’s only one property – it’s easier to allow several different points to be used. This is done, obviously enough, by allowing this special property to use an array of objects as its parameter, instead of just an object. So to make an object do a path following two bezier curves (or a curve defined by two quadratic bezier curves), it would be like so:

Tweener.addTween(myMC, {_x:10, _y:10, _bezier:[{_x:20, _y:20}, {_x:30, _y:30}], time:1, transition:"easeoutquad"});

Obviously this can be split into several different lines, it’s the same thing.

var myPath:Array = new Array();
myPath.push({_x:20, _y:20});
myPath.push({_x:30, _y:30});
Tweener.addTween(myMC, {_x:10, _y:10, _bezier:myPath, time:1, transition:"easeoutquad"});

Anyhow, I probably write too many boring details though; it’s better to show it working. So check it out, the Tweener bezier example, appropriately named Bezier Maker:

Download the source here (Flash 8, AS2) or here (Flash CS3, AS3).

To operate it, click and drag each point to change the path origin, destination, or bezier control points, and to better understand how it works. Clicking on “Add Bezier Point” adds a point next to the currently selected point; clicking on “Remove Point” removes the currently selected point. For demonstration purposes, the code one would use for such animation is generated at the bottom. The animation time is set to 1 second. Try adding more points and noticing how the path adapts to the control points, and how the ball travels through the path.

From this example, it’s also possible to notice one quasi-caveat of quadratic bezier curves: depending on how you setup your control points, or how your curves are laid out, it will change the speed of travel an object could have when sliding through the path. You can notice this happens by looking at the circles distributed among the curves, when you create a very acute curve: if the circles are too close to each other on a specific point of the path, that means a point of deceleration. Code wise, there are ways to avoid that kind of behavior and provide a normalized travel speed over the curved path; this will probably show up on Tweener as an optional bezier setting on the future. Right now, however, this kind of bezier-driven speed is the way it’s supposed to work by default.

And at last, but not least, the third and final good point of this bezier syntax is that by allowing a loose object to define the bezier control points, the code is freed from the obligation to do a bezier on two properties (or dimensions) and can instead apply a bezier to one, two, three, or more dimensions. So what this means is that the same code that can be used to slide a MovieClip on screen can be used to change its _rotation value only, or even change the X, Y and Z properties of a Camera object on a 3d projection. So considering the previous bezier tweening syntax, the syntax for such task would be simple enough:

Tweener.addTween(myCamera, {x:10, y:10, z:10, _bezier:{x:20, y:20, z:30}, time:1, transition:"easeoutquad"});

This is almost accidental in design – the syntax wasn’t built with any specific class or rendering engine in mind – but shows how a flexible syntax approach can just happen to fit well into other classes that make use of numeric properties. Once again, this is better shown than explained, so check this out, another example using Papervision3D:

Download the source here (Flash CS3, AS3) or here (Flash 9 alpha preview, AS3). But again, it does not contain the Papervision3D source, as it’s not publicly released; more information on how to get the beta here.

This example operates similarly to the previous one; the difference is that it has to use three different properties for tweening, and as such, it has a few more viewports to allow setting each of the points on a 3d world. Also notice you can not only drag the points around on the bottom viewports, but also the cone objects themselves. It’s also a bit crude as it’s just a quick example, so you’ll notice you can drag elements outside of the viewports, and there are other small user interface issues.

On the question of cameras, however, one interesting point must be brought up. Moving the camera around the space is just one of the steps needed for this kind of animation; moving the camera target around is another story. On 3d views, this can usually be done by aligning the rotation of the camera according to the path traveled (on all axis) and thus achieving the desired effect. This requires some more math, though, so on the above example, a little trick is used: instead of trying to calculate the angles of the camera in real time in a way that makes it stay aligned to the path, what is done is that the camera target itself is also tweened, but ahead of the camera in time. This means that both the camera and the target are running on the same rail, but because the camera is delayed, the effect of alignment is achieved because the camera is always “looking” a little bit further its own path (this is also what causes the slight movement delay when the travel starts). Animating the target with a second, different path would allow better movement control, but I’ll let that open as a suggestion for people who download the code. Anyhow, to test the difference between the two types of camera target, click the “toggle target type” button on the above example; it toggles between a fixed target (on the center of the world) and a target that follows the path a little bit ahead in time. The generated code is also updated to match these options.

To be honest, I think that for real, professional, tight, super-controlled camera control on 3d extensions such as Papervision3D, another solution must be created; something based on curves copied straight out of a 3d editing package, maybe something that parses a collada spline to create all needed points and then tween the position of a camera; or maybe a maxscript (or similar) script that outputs a number of points from a spline in the form of points that allow interpolation. As a quick solution for many cases, however, this simple bezier tweening will do.

Is this the perfect tweening syntax? It’s difficult to say. There are other mathematical solutions to the path problem which could be based on cubic (or higher level) bezier curves instead of the default quadratic ones; different approaches should be taken if the travel speed is to be maintained the same on the entire path, as it is dependent of all properties being tweened on any given path (the default quadratic bezier, on the other hand, allows all properties to be calculated separately); and there are different usage patterns that surely make for different syntactical solutions, as are almost most features on these tweening engines and classes. For me, however, this is the perfect boat to sail through curved streams, and it might also fit other people’s needs, so there it is.

Lastly, please notice this bezier feature has been added on the latest Tweener version, 1.25.53, only available through the subversion repository. This means the zipped “stable” download version is a bit older (1.24.51), and will be like that for a few days, until the new version has been tested enough. This version is now stable and can be downloaded from the regular download page.