A Look at Spatial Labs

Its blog time and I can’t stop myself from writing about the work Spatial engineers have been doing on Spatial Labs. We’ve presented some of the technology this year at Spatial’s 3D Insiders' Summit here in Colorado and at our European Forum in Frankfurt. Nonetheless, this seems like a good place to discuss our thoughts on where the technology might be going, what we’re looking at next and some of the industry feedback. I actually hope to write several blogs on this topic so let’s start with an introduction here.

As you might know Spatial Labs is our effort to explore the different technologies available to bring classical Solid Modeling technology to a zero deployment (browser based) architecture. This necessitates a definitive client / server architecture where we run the modeling kernel (and we’ve coded against both ACIS and CGM) on the server and the graphical interface (both the GUI and viewport) on a thin client. I can cut to the chase and tell you that Spatial Labs is actually a web site developed and hosted by Spatial (http://web3d.spatial.com). No login is necessary but it does require a plug-in for the graphics (small download / 4.5 m) so we’re not quite zero deployment at this time. (Look for future discussions on html 5 for our attempts to go completely zero deployment). Oh, and you currently need MS I.E. running on version 7. (You wouldn’t believe the work you need to get cross browser compatibility even on simple websites!)

Once you hit the site you’ll see pretty simplistic applications to execute basic Solid Modeling functionality. We have an ACIS application where you can work with three ACIS operators; Remove Face, Blend Edge and Offset Faces. In addition we have the same operators for CGM in an application dedicated to that kernel and two more applications showing Hidden Line Removal and other Spatial R&D work on multi-processing Solid Modeling operations. All applications should be accessible from the main page. I’ll go into more detail in a future blog about some of these apps, especially the multi-processing app.

But, to get into some technical detail in this first blog, we should discuss the graphics. Almost all the first inquires we have on the technical side are in regards to the mechanics of placing the graphics in the browser. Today I realize its only one of several compelling questions. There is so much more to the server side then we initially expected; but it’s a good one to start with.

At a high level we saw two definitive approaches. With the kernel being on the server we had two options; send polygonal/polyline viewing data to the client or stream simple images; almost like video, to the client. The latter goes by the term “screen scraping” although what I have read on the net it might not be precisely the correct use. (You can see AutoDesk Labs; Project Twitch . . . a screen scraping version of Inventor.) Undaunted by the path of AutoDesk; we went with the polygonal approach.

There is a lot to consider when contrasting the two. The polygonal approach struck us as being more open. At the core of the technology is a web service and the interface of the web service is the interface to the Solid Modeling kernel . So one can make very typical functional calls such as loading a model and performing, say a filleting operation. Although right now, just our web pages have access to the web service, the design supports the ability for anybody to interact with the web service; hence writing their own application in some form of a web mashup. The core on the client side is a Javascript library that supports the graphical viewport and accesses the web service. We can easily distribute the Javascript libraries allowing anybody to write their own web pages, basically calling our web service as a utility in an application that they create.

The screen scraping route seems more rigid. Effectively you take an already existing application and stream it, video-wise, over the net; essentially just turning your browser into a T.V. Now, it might be quixotic on my part, but there just doesn’t seem to be anything technically noble about screen scraping. It’s nice if you just want people to use your application as is. But something tells me that there is a grander destiny here, especially when considering how the internet will evolve as web services and mashups continue to become much more ubiquitous.

So, we’re forging ahead waiting to see how the industry breaks. In the next blog I’ll discuss how we use an AJAX pattern for the polyhedral approach and the different technologies we’ve explored in this area.