Tamapolis: Javi Agenjo's personal blog

After too many years developing 3D Apps using APIs like OpenGL I found myself wondering why I never did a rasterizer from scratch, creating the image pixel by pixel, using just the CPU.

It is a real useful exercise to consolidate the mental knowledge of a graphics pipeline. I even know people who use software rasterizers on their engines to solve visibility issues or as a fallback option for some extreme situations (for instance, 3D on the web on Internet Explorer! ha ha).

So today I started my own rasterizer, and I choose Javascript, which is not the best context when searching for performance., but I was surprised to see that three.js has its own build-in raster which amazing results, so, why not?

Click the image to see it in action

If you are curios about how it is done, continue reading the entry.

(more…)

For today experiment I tryed to recreate the cool sketchpad by mr doob using websockets and HTML5Canvas.

The idea is that while you paint on the canvas your strokes are send to the server and broadcast to all the users on the web in realtime using websockets, you also can see the cursor of the other people. Click on the image to test it but remember that if there are not other users online you will be just drawing alone.

Shared Canvas

If you want to know more about the coding read the full post.

(more…)

I guess that more or less all the people who love coding has seen this amazing talk from Bret Victor.

I was amazed not only by the ideas (which are great) but for the technological part of implementing those ideas, specially by the one where he keeps coding while the screen shows the output of the code without having to restart the app every time a line of code is changed, hard to do because while a coder is typing the code is invalid most of the time (could trigger parsing errors or execution errors). Parser errors are not dangeours because they can be detected easily and they dont mess anything, but execution errors are a big problem because once an error happens the data inside the vars could end up in an invalid state (because the code was partially executed).

So I started thinking about the problem and though that it shouldnt be so hard to code it in Javascript as a webapp using the HTML5 Canvas as the output. If you want to test it click on the image below.

Click to try the app

How does it works? I reevaluate the code after every keystroke (if the code is not too big the parsing is less that 100 ms), if there is a parsing error (the eval function throws an exception) I just keep executing the previous iteration (the last safe code), otherwise I try to execute the new one, if an error is triggered during the execution I fallback to the previous safe iteration.

It works pretty well, besides the problem with the persistent data between iterations, that could get “corrupted” very easily. For that I only could make a “reset state” button that clears all the state (I have to create a new Canvas to avoid problems with the save and restore functions).

There is only one unsolved issue, what about infinite loops?, well, I can’t control that, AFAIK Javascript doesnt has the tools to fix that, and it is easy to end up with an infinite loop when using whiles. I thought about injecting some code inside every loop before evaluating it, that code could act as a yield and throw an exception if the number of iterations is too big. But that would be hard to code so I will just leave it here.

Feel free to check the examples and play with the them, and dont forget to share your experiments with me 🙂

Btw, there are some candies in the app like the option of selecting and dragging a number while the Control key is pressed to modify a constant, it also works with variables.

Developing web applications has been always annoying regarding the browsers difference interpretation of the what is standard and what not, thats the reason why I stopped developing for IE. At least Google and Mozilla are serious about the standards so 99% of the code I develop for Firefox (my default browser) works in Chrome as expected. Kudos for both of them.

They have their own extensions but they are for more experimental features. Regarding to what functionalities to support, they both follow the same standard and thats great.

But when it comes to WebGL, although they both follow the same standard, the implementation is a little bit different.

That means that the performance it is not the same between both browsers under the same circunstances, and that is a problem, because there is no way I can see what is the browser doing (besides downloading the fullcode…) so if the performance is unstable I feel I reached a dead-end.

I dont mean that one browser is more optimized than the other, my issues are more about how some actions cost more to one browser than the other.

My current application runs much more smoothly in Firefox than in Chrome, but Firefox loves to purge the Garbage Collector every 10 seconds freezing the application for several seconds, which makes it totally unfriendly. Chrome on the other hand is more stable but the frame-rate drops sometimes just by adding a tiny mesh to the rendering process.

Chrome also do not like negative values for the viewport (I can understand that) and show some weird results when stretching a texture too much (¿?), looks like an undocumented bug with the magnification filter.

It makes me reconsider if WebGL is the perfect platform for 3D applications and games.

VRorschach is a silly HTML5 Canvas experiment I did a year ago. You can try it clicking the image.
It generates procedural symmetrical shapes and allow you to name them and share them.

The algorithm to create the shapes is very random, it creates closed splines with random x,y values around an area, and keeps shrinking the area with every polygon. I use a seeded random function so people can see the same results using the same seed.

It was fun to see what people saw.

I should try to find a better algorithm, I’m pretty sure I can make better looking shapes using something less random.