ricardocabellov5.5

This time around, the now traditional making of blog post is a video instead..

I didn't go much into detail but hopefully there are some interesting bits:



Thanks to Mozilla for sponsoring!

Don't include in your portfolio projects you wouldn't enjoy doing again.

That's something I learnt right when I started this site. The aim here was just to share some experimentation and have fun, wasn't meant to be my portfolio but people started contacting me proposing interesting projects. At that point I took down my old (and boring) portfolio and kept doing experiments.

So it's not time to apply that concept again... At this point I've no interest on doing Flash projects any more, hence I've removed all the Flash projects and experiments (files are still there, just not linked).

One of the things WebGL will bring us is Fragment Shaders. If you're familiar with Pixel Bender you know how Fragment Shaders work.

Although they usually go with Vertex Shaders, you can set it up for doing just 2D effects with it. Iq did exactly this some months ago with Shader Toy — a browser based Fragment Shader editor.

This week I started experimenting with this. First thing I needed to do was a sandbox with the basic WebGL initialisation code. With that done is just a matter of testing values and refreshing the browser. I tried to have a compile button right in the page so I wouldn't even need to refresh the browser but it was over complicating the code...

These are the tests I've done so far:









Next thing on the list is to implement render to texture so I can use the output of the fragment shader as input. That'll allow crazy feedback effects and even crazier drawing tools!

Feel free to use the sandbox code for your own experimentation.

Seems like WebGL is about to land. Chrome 9 beta, Firefox 4 beta 8 and Safari Nighly Build have it enabled by default already. It's just a matter of weeks for the final versions to be released.

I think we're going to face a funny situation... For web developers OpenGL may be a bit intimidating — at least it was for me! For game developers it's piece of cake, but because some features have been disabled some of them feel like a step back in their careers. So it's an area where there won't be so many people for a while.

You may know that, for the last few months, I've been busy developing a library that aims to make this as painless and fun as possible. Hopefully there will be more libraries like this in the near future.

If you're a web developer I would suggest you to start tinkering with all this. I have the feeling things are going to move quite fast as soon as it lands. Won't be long until Mobile Safari — iOS and Android browser — also enables this.

Exciting times! :)

This is something I've spent a fair amount of time on already. Last year I wrote about some of my findings but the truth is that it didn't anywhere.

The main problem is that, for whatever reason, Lagarith is not finding its way into ffmpeg and rumours say Youtube uses ffmpeg for doing the transcoding. So if you tried to upload that 2gbytes video file to Youtube you'd end up getting a "unknown format" error.

Early this month I checked what was the status with all this, and seemed that nothing had changed so I thought about looking for other lossless codecs. This time I tried with Huffyuv. Video file size is bigger but at least ffmpeg supports it.

The idea is to let Youtube host the uncompressed files for me (5gb-20gb each). I don't know if that's what happens or not, but I would think such service must keep the original.

This is how the process looks like:

1. kkapture the demo using Huffyuv for encoding.
Note: I have antialias enabled on my nvidia config as that compresses better than non-antialias stuff.
2. Now you'll get a bunch of .avi files that you need to merge. To do so just use Virtualdub. While you're on it, go ahead and remove the aspect ratio black bars.
3. Upload the file to youtube. This may take a while. It takes about 24 hours per video here.

And that's it. Now it's up to Youtube to keep updating their videos as technology evolves. It's a slow process, but if the theory is right it just needs to be done once.

You can see the ones I've managed to do already in the (just re-opened) demoscene section.

That was a slow year on this blog. Only 3 posts...

It's been one year since we decided to move back to Spain. Since then some people have asked if we had moved already or what. Well... not yet.

There are a few things you need to deal with when moving. Specially if you own a property on the country you're leaving that you want to keep. On top of that, it was my first year as freelancer. Things were unstable and it was also quite hectic.

2011 seems to be a bit more stable so there it's more likely to happen. Once again we aim for June/July. We'll see how it goes...

Anyway, have a great 2011! :D

Continuing with the three.js development, after implementing multi lights the flat shading was starting to be quite a limitation.



In order to get smooth faces I needed to figure out a way to create what it's called 3 point gradients. I took a look at the usual Flash 3D engines and what was my surprise when I found out that they tend to be limited to just 1 light (correct me if I'm wrong). This is probably because by supporting 1 light they just needed to create a light map per material. Something like this:


That's indeed a fast approach, but it limits to just 1 light, and then you need to update the map if the ambient light changes or the color of the material... not really up my street.

The old way of doing this with OpenGL is by using Vertex Colors. Basically, I was after this:



I wondered if there was a way to create this kind of gradient with the Canvas API. I googled a bit to see what people had come up with, but all the approaches seemed quite cpu intensive. Like this one from nicoptere.

Then a crazy idea pop into my mind. What about having a 2x2 image, and change the colors of each pixel depending of the vertex color and do that at render time per polygon? The browser will then stretch that image and create all the gradient in between those 3-4 pixels.

This is the 2x2 image:


Can't you see it? Ok, this is the same image scaled to 256x256 with no filtering (using Gimp):


However, by default (whether you like it or not) the browsers filter scaled images. This is what you get within the browsers:


Each browser gets slightly different results but pretty much that's what you get. This wasn't exactly what I was after, there is too much color on the corners. However, by looking at all the results from all the browsers I realised that the center part of the image was the only part that was always similar.


Then I realised that that's the actual gradient I was after!


Here it's the code:

var QUALITY = 256;

var canvas_colors = document.createElement( 'canvas' );
canvas_colors.width = 2;
canvas_colors.height = 2;

var context_colors = canvas_colors.getContext( '2d' );
context_colors.fillStyle = 'rgba(0,0,0,1)';
context_colors.fillRect( 0, 0, 2, 2 );

var image_colors = context_colors.getImageData( 0, 0, 2, 2 );
var data = image_colors.data;

var canvas_render = document.createElement( 'canvas' );
canvas_render.width = QUALITY;
canvas_render.height = QUALITY;
document.body.appendChild( canvas_render );

var context_render = canvas_render.getContext( '2d' );
context_render.translate( - QUALITY / 2, - QUALITY / 2 );
context_render.scale( QUALITY, QUALITY );

data[ 0 ] = 255; // Top-left, red component
data[ 5 ] = 255; // Top-right, green component
data[ 10 ] = 255; // Bottom-left, blue component

context_colors.putImageData( image_colors, 0, 0 );
context_render.drawImage( canvas_colors, 0, 0 );

So it was just a matter of changing 3-4 pixels, scaling up and cropping and then use that as a texture for each polygon. Crazy? Yes. But it works! And fast enough! And what's more, it's not just limited to 3 points, but a 4th point comes for free (quads).


Here it's an example of the first material I've applied the technique to (use arrow keys and ASWD to navigate).

At this point I was surprised that I didn't see this before. And that I hadn't seen this being done in any of the usual 3d engines. I did another search and I found this snippet from Pixelero that uses the same concept. Good to know I'm not the only one with crazy ideas! :)

Thanks to this, now I'm able to do smooth materials (gouraud, phong) that support multiple lights, fog, even SAAO :) We just need the browsers to become faster (which they seem to be on it already).

Of course, if your browser supports WebGL you should be using that instead, but if it doesn't, at least you'll have something better than a text message.

For the last few weeks I've been quite focused on developing the engine and I think the API is starting to get quite stable. I'm still unsure on what parts of the API need to be included in the actual build and what parts should just keep outside.

For instance, primitives is something you don't want to have in the compiled .js file. If you need a Cube, Sphere, ... I think it's easier to have it in /js/geometry/primives/*. Otherwise we end up having a 100kbytes file just for drawing a bunch of particles. I really want to avoid that, right now it's 60kbytes. But that includes all the renderers, if you're only going to use CanvasRenderer, you can save 20-30kb by removing the SVGRenderer, WebGLRenderer, ... logic. These scripts do that automatically.

Mr. AlteredQualia has been doing an awesome job with the WebGLRenderer these past weeks. If you have WebGL enabled, these 400k polys are waiting for you.

There is still quite a bit of work to do here and there, specially on the materials side (Mapping types, Blending, Gouraud, Phong... ) but it'll all come in good time :)

Joe Parry suggested by email to write a follow up to the post about JavaScript IDEs. That's also one of the common questions and I intended to include it on the first post but I forgot :S

I've heard many people referring to Firebug as the best way to debug when coding JavaScript but I've never got to try it out properly as I started coding directly with/for Chrome. So in my case I mainly use the Webkit Inspector/Developer Tools panel.

However, rather than debug the code I usually log stuff instead for which console.log(), console.log(), console.error(), console.warn(), console.info() gives me way more than I need. Specially coming from Flash where the console is so basic that everyone keeps building their own logging library.

At this last Google I/O I saw this presentation about the Developer Tools that left me quite impressed of how much stuff I was missing.

Last week Matthew Lein shared a very interesting tip over twitter.

Apart from FFFOUND!'s bookmarklet I haven't seen myself using many of these as I've never felt they were that useful. However, this case is different and, once again, the possibilities of JavaScript amaze me.

Just drag and drop this link to your bookmarks toolbar:

Display Stats
By clicking on the saved bookmark you'll be able to insert the Stats.js widget in any website and monitor the FPS/MS/MEM by doing so \:D/.