Our Technology

That said, based on the projects we've done, we've developed skills in a number of areas. When you couple good attitude with our demonstrated ability in these areas, we're unstoppable. These areas include Computer Graphics, Client/Server applications, UNIX programing, Macintosh programing, and of course, Windows programing. (and of course, we do Java, C++ and Object Oriented Programming.)

Naturally, recently that has led to a lot of web application development work. We used to do a lot of that the hard way for small customers (Perl, JavaScript, Java) and use WebObjects for large customers. Since Apple changed their licensing scheme for WebObjects to be more scalable, we've been able to do web projects in WebObjects for small customers too, especially those who hope to become large someday. Pierce has written an article that talks about how to scale a WebObjects project up from $3,200 to $250,000.

The way we do things isn't really a technology, but really just that we've learned through experience what works and what doesn't work. You can read about it in our Process page, where we also talk about our opinions of some of the technologies out there in the marketplace like Java and Design Patterns.

You can also read the technical documentation for some of our in-house libraries and tools here.

Its pretty easy to write a 3D renderer. Its a little harder to write one that's fast. Its even harder to write one that works. There are lots of details in writing a renderer, and if you don't get them all, your images don't look right.

We've written all kinds of 3D renderers: ray-tracers, phong shaders, mixed-mode, real-time, particle systems and volumetric. They were all fast, faster then many of the current commercial offerings, and they all worked flawlessly. You can see some of the results in our rendering gallery. We're also experts on technologies like GL/OpenGL, and SGI programing.

We don't just limit ourselves to renderers, but we also work on creating and animating the scenes as well. Because we've worked with so many actual end users, we've created tools that allow users to edit their scenes in real time. The two most notable of these tools allow the visual artist to instantly get feedback on the lights and surfaces used in their scene. As one of our customers commented, "Finally, I have a tool that lets me actually be an Art director. Before, the process to change something was so hard and took so long, I just had to live with whatever I got from the artist."

You can see the surface editor here: surface, and the light editor here: light.

From our rendering technologies we got into motion capture for a company called Modern Cartoons, and from that we got into real time rendering. Finally, we write plug-ins for a high-end rendering package called Houdini from Side Effects software.

We started doing client/server work because of our computer graphics work. Computer graphics takes a lot of time, so users want to be able to offload their work to other systems. Once they can do that, they want to be able to monitor that work and see how its going, and what the results are. Not too long after that, they want to be able to control and adjust that work.

And all that has to be useable by artists in the middle of a production when they're late for a deadline so it has to be easy to use, and reliable. From rendering job control, we worked on a production control module for satellite image processing, an online game, and some web to database connections. These days it seems like everything we do involves the network.

For client/server, we generally take one of three approaches depending on what is appropriate for the customers needs. The first approach is to write the standard, bare-metal, TCP/IP sockets client and server programs. We have some networking libraries developed so that we can quickly create a server and client and know that they will both communicate with each other in a safe and reliable fashion.

Lately though, we've been using a web-based approach. In this approach, we've created our own web server using our networking library that allows us to quickly create web pages on the fly. In this way, we can leverage off of the millions of dollars spent by Netscape and other browser vendors to develop the user interface. For instance, our rendering job server allows jobs to be manipulated directly through a combination of Java applets and web pages. We have our own database connectivity built in, so we can quickly build pages from any sort of database table or collection of database tables.

In a similar but related approach, we use the leading web to enterprise solution, WebObjects. WebObjects is very similar to our web-based approach, but it connects to any of a number of databases and web servers, and it has more features and supports more complicated business logic. Really, WebObjects is a development system, rather then just a technology. When you use WebObjects, you can really tell that its a mature product, unlike some of the other products I've used. Since Apple changed their pricing scheme, WebObjects has become such a bargin, that there's no reason not to use it for a web site.

What of the key features of WebObjects that no one talks about much is that WebObjects is the only web application development system that's integrated into the two major artist-level HTML tools: GoLive and DreamWeaver. That means that we can work closely and productively with artists to make their site both functional and beautiful. It also means that our customers pay us to add features, not tweak HTML.

What can I say? We've done a lot of UNIX and IRIX programing. We're experts in both IRIX (SGI Unix) and Solaris. Motif, ViewKit, Builder Xcessory, we've been there, we've done that.

We've been programming on the Macintosh since 1985. We've done everything from device-drivers, to Quicktime, to applications. We've used the Think Class Library, PowerPlant, MacApp, TransSkel.

Its everywhere. We've done a lot of it, along with everything else. We haven't spent as many years writing Windows code as everything else because frankly, prior to Windows 95, Windows didn't meet the needs of any of our clients. That's changed now that you can write 32-bit apps and many of our projects are now on multiple platforms at once, with one of the platforms being Windows NT or 95.

It can be quite a challenge to do something outstanding within the limits of the Java API, but we think some of our work speaks for itself. You can see an example here.