I’d been thinking about this for a little while. A rendering engine was an enticing project and I anticipated some interesting complexities. I had decided that I would use SVG as the medium. As with 2D drawings, HTML5 Canvas seems to get all the attention for 3D drawings (WebGL) but, in both cases, there are pros and cons of each technology. Notable reasons for choosing SVG may be:
If you need to interact with the components, SVG elements natively support mouse events (like mouseover)
So, first off, here’s the result. I’ll explain how it works afterwards.
As mentioned above, there are a number of good reasons to use a vector drawing. A use case which immediately springs to mind is architectural drawings. The drawings need not be vastly complex, certainly in terms of fairly regular shapes and textures. Also, a developer could add interactive elements to an application so that hovering over a wall or joist would show you the materials, etc. That would be much more difficult with WebGL or similar as the hover events aren’t there to help.
How it works
The maths behind the engine is fairly simple but quite fun. First, a camera is created, which consists of a point in space and a rectangular plane at some point in front of it. The plane is, in effect, the lens of the camera and I refer to the point as the origin. Then, to plot a point the following algorithm is ran:
A vector is constructed from the point being plotted to the camera’s origin
The point that the vector intercepts the lens is calculated
The intercept point is converted into a 2D co-ordinate, relative to the lens
That co-ordinate is scaled up to the screen and a point is plotted there
So, to draw a plane one merely needs to convert four points in space to be four co-ordinates on screen, then an SVG path can be used to join the dots.
A bit more detail
The interesting part of this project is projecting the point to be plotted onto the lens. I had an idea of how this would work: I wanted to exploit the fact that the dot-product of two vectors at a right angle is always 0. Moreover, a decrease in the dot product implies that the angle is closer to a right angle.
So, take any two points on the lens, La and Lb, which could be corners and a second vector, v, from the camera origin to the point being plotted; then, there exists some λ which minimizes α:
Pictorially, that is:
Therefore, λ minimizes α as λ v approaches the intersect between v and the lens plane. To find the value of λ I simply implemented a “split the difference” algorithm. That is, try λ equal to 0.5; is that better than λ equal to 1? Then try 0.25 and 0.75, which is best? Ect, ect.
Once you have the vector λ v it is quite easy to map the point onto the screen using a bit of trig’ and some vector maths. Then you’re there. If you want more details, best check out the code on my Github page.
The future of the project
This was never meant to be a production library, just a proof of concept. I think that a robust SVG-based rendering engine could have a number of sound use cases but it would take a lot more time than I have available to get to the point where this could be used in production. A number of challenges, just off the top of my head, include:
textures – difficult to transform in 3D if you’re using SVG
lighting – this could be implemented using dot products between the normal of the plane and a vector from the plane’s centre to a point of light
z-index of polygons – i.e. if the example above were opaque, the closest planes should be visible above the farthest ones.
I’d love to know what other people think and if there is any work in this direction already…
I’ve been working lately on an extension to Raphael.js which lets you quickly add Filter Effects – something which I’ve wanted to see in Raphael for a long time. I’m not going to do a big write up just yet but here’s an example of what’s on offer:
You can find out about the project on it’s homepage.
For the basis of this post, I’m going to use the Constructor pattern and look at the following simple example:
If you were to look at the football object in your browser’s debugger you would see that it has a property called prototype which is a reference to its prototype chain. The chain would go:
Sphere → Object → null
Now, that code can be rewritten using the prototype property of Sphere, like so:
As you can see, the result is the same. But, if one were to compare the two version of the football object they would see a difference. In the first incarnation “pi” and the “volume” function are both own properties of football; in the second version those two properties are no longer part of football but instead are properties of its prototype, Sphere.
You can prove that by changing the value of “pi” in the prototype:
So, without changing football at all, its reference to “pi” has updated. As “pi” was not an own property the prototype chain was consulted and value found in Sphere. That has a very important implication: for any instances of Sphere there is only one object which is the prototype. That is, if we created a second Sphere, called tennisBall, it would not just have the same properties in its prototype as football, it would have a reference to exactly the same object as its prototype. So if “pi” is updated in the prototype it is updated for every instance of Sphere.
That can be a useful property in of itself but it has huge implications for application performance. Suppose we create a large number of Spheres. In the original example (without using the prototype property) there would be a property “pi” and a function “volume” created once for each instance of Sphere; when those properties are part of the prototype they will only be created once. So for a million Spheres there would either be 3 million properties (a radius, pi and volume for each) or 1 million and 2 properties (a radius for each and a pi and volume in the prototype). That makes a huge difference to performance:
Using properties of the prototype:
Using own properties:
On my laptop, the version with the properties stored in the prototype ran in 0.563 seconds, verses 1.349 without. That’s more than three times the speed!
So, it’s not just about coding style: the prototype property is very important, particularly when your code creates many instances, and needs to be understood. If a property is likely to be unique to the instance then it should be ab own property, otherwise it’s often worth moving it into the prototype.
Consider the following layout for a page with a collection of articles:
It’s a fairly common structure and really good for emphorsizing the lead story. I set about trying to create that layout as a theme for a FactMint infographic. As it was a theme, I couldn’t add any additional classes to the HTML (and would rather not anyway). I started from this criteria:
The first article must be full width and all others half width.
That can be accomplished using the CSS selector
or similarly using the :first-child pseudo class.
Although the criteria is fulfilled, there is problem. Take the case where there are two articles:
Looks a little unbalanced, at best. So, what’s the solution? Well, one could make the last article full width, too. That is accomplished using a selector like:
The issue with that approach is fairly clear, it just moves the problem onto the cases where there are an odd number of articles; the penultimate article will, then, be solitary and half-width:
Logically, the general solution is easy to describe: make the last article full width only in the cases where there are an even number of blocks. The question is, how would one accompish that?
I’ve seen this problem resolved in the past by adding conditionally adding a class (say, .full-width) to the last article, subject to there being an even number of articles. That could be implemented using a templating engine or just code. The solution has its merits – it’s pretty easy to understand, for one thing, which is a big pro. It is, however, not a semantic class; even if you were to call the class last-component, while it would be semantic, the fact that it is conditional would nullify its sentiment.
Here’s the solution I came up with. It is dependent upon the precedence of four CSS rules, implemented by their order in the stylesheet. Namely:
All articles are half width
The last article is full width
All odd articles are half width
The first article is full width
So, the first article is always full width, as it’s the last (highest precedence) rule and the last article is full width unless it is odd (as the odd rule overrides the last rule).
Here’s a jsfiddle to illustrate. Play around with the number of articles in the section.
For my company, FactMint, a big part of our software is building data visualizations automatically. One of the staple diagram types for visualization designers has always been bubble charts. They always seamed a little complex to build programatically, however, with one needing to to account for a non-overlapping, evenly distributed layout.
Anyway, I finally took the plunge and build a proof of concept in JSFiddle. I think it’s rather neat, so I thought I’d share it:
After getting a little deeper into a fairly complicated Web application, however, I frequently found myself frustrated with the framework’s complexity. In order to understand why I believe there is a place for a new data binding library I need to give a quick review of Angular:
Things I like in Angular
Two way data binding
Using templating or other data binding techniques makes your code much more accessible. Designers work on HTML and CSS and can see everything. Logic can deal purely with data and just update the model behind the UI.
Things I dislike about Angular
The idea behind Angular scopes sounded fairly simple when I first read about them – basically a scope is a model and it is bound to a part of the DOM. In simple Angular applications there is often only one scope, bound to the whole HTML document. When my application became more complex than that I continually found myself confused and wasting hours debugging my code to work out how to get two scopes to interact. Sure, you should design your scopes to be independent (that’s what a scope is!) but a couple of times I realized further down the development process that I had some unforeseen need to access two scopes; at that point my options were to redesign my application from a fairly fundamental standpoint or to deal with mounting difficulties and hacks used to get around the scope system.
One mandatory feature for Iugo was the ability to access namespaced models at any point in the DOM. Not to mension a lighter touch so objects don’t need to be treated in a special way if you are using them as a model.
Being a framework
If you need a framework then check out Angular. If you have a requirement for data binding and templating then you may want to consider your options (including Iugo). Angular includes ajax helpers, scenario testing, localization, URL management, dependency injection, event listeners, test helpers (such as angular.isArray()) and a host of other features. Those features may well be useful to you but they add up to 80k minimized – about the same as jQuery; if you already use a framework like jQuery do you really want duplicate HTTP helpers, &c? Personally, I prefer smaller, modular, libraries. Iugo is 5.8k minified, less than a tenth of the size.
Not being HTML5 complient.
For the record, I think Angular may have fixed this with some kind of compatibility mode but their website is littered with examples of non-compliant code. Take the example on the homepage. They use the “html” doctype but have an attribute called “ng-app” in the document’s html tag. That’s not allowed; try it in the W3C’s validator.
So, this those points in mind, I set about creating a simple data binding library. Iugo is:
Small, less than 2k minified and gzipped
light touch – it will complement other frameworks like jQuery
standards compliant, no namespaces or invalid attributes
modular, as it is based upon an event system for objects
I’d love any feedback anyone has, so please check out the site.
I’ve been fascinated by Conway’s Game of Life for a while now. I was reminded about it when I read Stephen Hawking’s Grand Design, last summer; which uses the game’s universe as an argument both backing Descartes’s Evil Demon concept (although I don’t think Hawking was suggesting that to be true – just an interesting thought experiment) and to show the surprising likelihood of life in a universe governed by simple rules. If you don’t believe the latter point have a look at Gemini, the first self replicating entity discovered in the Game of Life; when you consider the scale of our universe it seams less surprising that complex life could arise.
Some patterns from a Game of Life
Anyway, I’ve intended to write a Game of Life model for some time and got round to it the other day. You can have a play here: http://chrisscott.org/gol. Click randomize then start to get going – you can also click individual cells to toggle their state, while the program is stopped.
The basic premise is to repeat background stripes using em measures, to keep them inline with the text.
Contrary to the impression the huge "Chris Scott" title may have given you, I'm not an egomaniac. I just liked the font and couldn't think of anything more imaginative to say.
I am a pasionate developer and an entrepreneur. My company, FactMint, produces Semantic Web applications for researchers and data-journalists. We cover everything from triplestores up to data visualization tools.