Michael Frank Deering: Software: TBAG
Company: Sun Microsystems, Inc.
Timeframe: Early 1990′s.
This was a research scene graph language at Sun in the early nineteen nineties. I was involved with the initial concept of the system, and managed the TBAG research group for a time, but when the group was re-orged out from under me it continued under other managers. The main people involved on the project are those listed on as coauthors on the SIGGRAPH paper below, additional people are mentioned on the web site linked to below.
Most graphics packages are interpreters, and as such generally have had ad-hoc ill-defined semantics. The Computer Science programming language community went through a similar period in the early seventies: for several years it was an open question as to if interpreted languages like Lisp or APL were compilable. The answer was eventually a qualified yes; the qualification was that the languages had to be modified slightly, in order to have a consistent formal semantics. The original concept for TBAG was to do the same thing for graphics packages/languages: by having a formal semantics of the system, many optimizations could be performed at “compile” time: strength reduction, partial evaluation, re-ordering; other optimizations could be performed at run time. Thus the goal of the project was to come up with such a semantics, and then an implementation of the optimizations.
It turned out that everyone on the initial project was a closet Scheme (an neo-ultra-orthodox variant of Lisp) fanatic, and so we decided to implement the first version in Scheme. This allowed us to treat and intermix graphics data as a language construct; 3D vertices were just another S-expression. (This completely bypassed a lot of the syntax wars that were later to plague VRML.) We were also influenced by functional (side effect free) programming languages, like ML. While I personally thought that ML was a little to strict of model for general purpose programming languages, it was a fairly good fit for how 3D graphics data is actually used and behaves. A number of the the straight forward things were quickly implemented from this start.
The Company Catches On
After TBAG was re-orged out from under me, management started to be interested in productized it, but was not amused by the use of Scheme. Real customers program in C++, if not C. So the TBAG team made a go at defining the package via C++ interfaces, but the project was canceled before it was productized.
The Concept Lives On
After losing one high level 3D graphics software group to a different part of Sun (SunSoft), I eventually started a new one within the hardware group when I created Java 3D. While Java 3D is not an implementation of TBAG, it shares the philosophy that graphics scene graphs should have formal semantics (including the ability for portions to be marked as read-only), and that optimizations may be done both before and at run-time based on these semantics.
After the end of the project many of the people on the TBAG team moved to Microsoft, and have used their TBAG experiences to leverage their own next efforts, but I have no connection to that.
There was a SIGGRAPH paper on TBAG, and having had only early connections to the project, I was not a coauthor.
TBAG: A High Level Framework for Interactive, Animated 3D Graphics Applications. Conal Elliott, Greg Schechter, Ricky Yeung, and Salim Abi-Ezzi. Proceedings of ACM SIGGRAPH 1994.
(A copy of the paper is available off the web site listed below.)
Conal Elliott (the main TBAG architect) has put up a TBAG web page with quite a bit of TBAG info, including copies of two published papers, and information about what he has personally done since along similar lines.