I’m going to follow up on my first blog, At Look At Spatial Labs, writing about the technology behind the web site, specifically how the AJAX design pattern was used to create a dynamic, 3D graphical viewport.
We knew when we first created the Spatial Labs site we wanted the graphics viewport to act and look like it would in a typical desktop application; not just in presentation (for example, a sophisticated coloring model, shadows, gridlines, view, pan, rotate, etc) but in its behavior upon user interaction with the model. We wanted to be able to select faces and edges on the model, perform modeling operations and update the viewport as smoothly and “flicker free” as possible. This, of course, meant that we needed to build an interactive (dynamic) web site as opposed to a simple site of static html pages. In the next blog I’ll discuss the array of options for the 3D graphics themselves but for now I would like to limit the discussion to the later, how can one make a graphics based website dynamic? - as if you are running a typical desktop application.
There is nothing new or Earth shocking here, dynamic web sites showed up years ago largely due to a concept called AJAX. Although this is not a blog about general web application development, a little introduction is needed (as AJAX is the key); and in order to save you from chasing the link, I’m going to shamelessly copy the first paragraph in Wikipedia which introduces AJAX.
(I love Wikipedia. Cuts right to the chase. I own multiple AJAX books, not one has that clean and clear of an introduction.)
OK, anybody spending any time on the net should recognize AJAX at work all over the place. (Think of all those blue rotating circles in the middle of pages.) You’re hard-pressed these days to find a website that does not have some AJAX in it.
As with all high level concepts; upon implementation come the details. Ohhh, the details. One has to be careful with AJAX. You can overuse it and make your site more annoying than worthwhile. You don’t have control over everybody’s network speed and people using your site will be anywhere in the broad spectrum of performance. We had to figure out when we really needed to go the server and when we didn’t. We knew that less would probably be safer and better. Of course, in our case, the 3D modeler is on the server (not in the browser) so when one fillets an edge (as in one of the examples in Spatial Labs) we have to go to the server for that. But what about other areas of interaction; rotation, pan zoom, picking etc? In our implementation these are on the client side, including picking. But in Solid Modeling apps, nothing is trivial. What if one wanted to select a FACE and get all the EDGEs belonging to that FACE? We could go back to the server and get this information … or what if we made the scene graph more intelligent and embedded this kind of information in it? Then it would all be client side and, well, one less blue rotating circle.
In the end we went through many iterations on this subject and are still refining as we go; basically adding more and more intelligence (in a very compact way) to our scene graph. We found it really key to understand what information is best on the client and what should be on the server. In the end, I don’t think the refinement will ever stop. It’s become one of the more intriguing problems of our design.
In the next blog I’ll discuss the array of technologies one can use to display the graphics in the browser and how we converged onto one solution but are keeping the doors open for others. I added an AVI so you can get a feel of the performance.