Solid Modeling and AJAX3D

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.

Ajax (pronounced /ˈeɪdʒæks/; shorthand for Asynchronous JavaScript and XML) [1] is a group of interrelated web development methods used on the client-side to create interactive web applications. With Ajax, web applications can retrieve data from the server asynchronously in the background without interfering with the display and behavior of the existing page. Data is usually retrieved using the XMLHttpRequest object. Despite the name, the use of XML is not needed, and the requests need not be asynchronous. [2]

(I love Wikipedia. Cuts right to the chase. I own multiple AJAX books, not one has that clean and clear of an introduction.)

Along with the introduction from Wikipedia a little more detail is needed; the “presentation” (text, images, etc) of a typical website is provided to you by what’s called the browser’s DOM. (You’ll have to chase this link, if you want). Think of it as “a tree structure of HTML and a JavaScript interface in order to manipulate it”. AJAX works by having the browser contact the server asynchronously and the server returning information back (maybe little “updated” pieces of HTML). The browser, through the use of JavaScript, updates the DOM with this information. As the DOM is a tree structure, the browser might hack off a limb and replace it with this new bit of HTML just returned from the server. This updates the “presentation” in a dynamic way; one did not go back and reload the entire DOM when only a small part changed.

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.

Enough with the basics of AJAX, how does this contribute to a dynamic (flicker-free) graphics based web-site? The key observation here is that the DOM is a tree structure that can be updated by the browser via JavaScript. Well, the scene graph of the viewport is a tree structure as well. Instead of text, button controls and images (as for HTML) - it’s a tree of polygons, polylines, color nodes, etc. And if one has JavaScript access one should be able to update the graphics in the exact same matter as the HTML DOM. Again, in a latter blog, I’ll get into the array of technologies available in order to mechanically place the 3D graphics in the browser; but now we are starting to get an idea of some of the prerequistes.  (There are many technologies for this, but I will tell you now, the more comprehensive and powerful the scene graph and JavaScript interface, the better). I have to give credit to the paper AJAX3D - The Open Platform For Rich 3D Web Applications by Toni Parsi. He observed it. We read it and put a Solid Modeler behind 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.