Real-time computer simulation and rendering is a hugely complicated field. This complexity is in turn mostly owed to the complexity of the real world itself, some abstraction of which we're trying to model. Its quantitative and qualitative modeling spans fields of study such as physics, mathematics or chemistry but added to these are subjects such as programming, algorithm design or getting acquainted with the design and quirks of a large set of libraries. So there are two vantage points from which a computer simulation of a given real physical system can be seen. First there is the point of view of the engineer who is mostly concerned about the mechanical and physical aspects of the studied system and how these can be best modeled, what simplifications can be made, etc. Then there is the programmer's view. He is worried about how the needed physical models can be calculated by a computer, how to display the results on-screen, how to manage the interaction between the user and the computer and other similar details.
Now there are some interesting observations to be made on this dichotomy between engineer and programmer. For starters the programmer's work tends to be more involved in most cases. If we consider the example of a billiards simulation the physical system is relatively simple involving mostly rigid body mechanics, collisions and friction. Since the calculation of the equations involved is carried out by Techne the engineer only needs to bother himself with the qualitative aspects of the physical laws in most cases and the same holds for the visual models employed when rendering the scene on-screen.
The programmer on the other hand needs to worry about both the qualitative and quantitative sides of the physical models needed for simulation and rendering. In addition to that the models have to be adapted for calculation by a computer (with ever-changing architectural design) and suitable algorithms have to be derived which only adds to the mathematical complexity. And then there is the matter of implementing these algorithms in some programming language, dealing with the interfaces and bindings necessary for input and output and other low-level tasks etc. On the other hand the programmer can avoid concerning himself with the specifics of how the implemented model can be applied to the problem at hand (say a billiards simulation), what physical details need to be taken into account and how the user can interact with the specific simulation.
There are a couple of points that are of particular interest: First the two roles are more or less disjoint. The engineer doesn't need to concern himself with how the models he uses are implemented and the programmer doesn't need to know the specific details of the system on which the models will be applied. Second and most important, the programmer's work is generic while the engineer's work is specific. In order to illustrate this consider again the example of a billiards simulation. As we've seen the physical models needed cover rigid body mechanics, friction, collision and contact as far as simulation is concerned and in addition to that a set of shading models necessary for rendering glossy surfaces, cloth, wood, shadows etc. The engineer then would compose all these models into a simulation of a billiards table and provide the user with a way of controlling it. It is obvious that all this work is specific to the given application but what about the underlying models? These would probably be useful in a large number of other applications. Consider for example a racing simulation. The only additional technology needed are models for joints between rigid bodies and probably a few more shading models needed for metallic surfaces or asphalt. This means that there is a great deal of overlap in the underlying technology and this becomes all the more important if one takes into account the difficulty involved into developing and maintaining it.
It should therefore be possible, at least in theory, to separate the two tasks into a system that takes care of implementing the necessary models and allows applications (or derivatives as I like to call them for reasons unknown) to employ them. Techne is an attempt at such a system so let us have a look at some of the implications of such a separation.
Perhaps the most important result is that it allows in a sense to take the programmer out of the picture. Now it would be reasonable to assume that someone wanting to make a simulation of a field he's interested in would have some insight into this field. Again in the case of a pool simulation it would be no surprise if the person wanting to implement it on a computer, perhaps to be able to practice when a table is not available, would have considerable knowledge of the basic phenomena of pool play. He might even have some grasp of the physics involved and should be able to research into the rest with no big problem. This is certainly not the case with low level programming though. Chances are the person in question would have great difficulty in acquiring the needed knowledge and especially experience needed to understand the mathematics and algorithms behind all those physical phenomena or the details of using a low-level programming language on a modern computer and operating system. The result would probably be for him to give up when faced with all this new information he needs to absorb (and which has nothing to do with pool for the most part) or to compromise with a simpler simulation both in terms of physical accuracy and rendering quality. This is unfortunately only too evident in many of today's free software projects. Providing an implementation of the needed models and an interface capable of describing the way they're employed and interconnected might, under certain conditions, enable enthusiastic and talented people to create applications and art without having to spend a good deal of their life in getting a degree and the needed experience in computer science. The conditions involved present a big problem which will be addressed shortly.
Continuing with the implications there's another point to be made when considering the complexity involved in real-time applications. There are many ways to implement the needed technology, differing in quality and accuracy but also in the amount of required work. How realistically are the balls of our billiards example to behave? Will certain subtle effects such as cue ball squirt and swerve, throw etc. be implemented? It might not make a big difference for most casual players but, on the other hand, these are the details that make Billiards what it is, by adding to the sophistication of the skills necessary in order to play the game successfully. Put in other words, it is easy, pressed by constraints in time or cost, to dismiss certain aspects of the simulated system as trivial, but I suspect we'd all be surprised at just how much more depth these would add to the world and the possibilities in interacting with it if we were allowed to consider them. The same of course holds for visual detail, at least in the cases where this detail or sophistication is used in order to better convey the intended meaning and not just for show.
As a finishing remark let me mention the added benefit that changes to the underlying system would end up enhancing many applications at no extra cost. For example if tomorrow's graphics hardware technology allows us to implement a higher quality shadowing algorithm then all derivatives will feature better shadows at no extra cost. This, on the one hand, can lead to derivatives that stay up-to-date regarding physical and visual state-of-the-art even if their original authors have given up on their maintenance and, on the other, in minimizing the effort needed in order to do so.
Some very bold and promising statements have been made up to now so we must now turn our attention to the conditions under which these might be realizable.
The core of these conditions lies in our initial claim of separability between the roles of engineer and programmer. This is only valid when the required physical models have been implemented in a sufficiently generic manner and with the least possible assumptions. If we want to calculate shadows cast by balls on a flat pool table for instance it wight be more than enough to use a simplified technique than only works for planar shadows, but that would seriously limit it's range of potential applications. The engineer wanting to use the system in a case where the assumption of planar shadows does not hold would be forced to resort to implementing it himself.
The implementation therefore should be made as universal as current computational resources allow but what is more important is that the interface be as generic as possible. Interface here refers to the interface between the roles of programmer and engineer. When the engineer wants to employ a certain model he will have to be able to describe accurately to the underlying system all the parameters of the current situation that affect this model. Considering again the case of shadow calculation he should be able to describe the geometry and light sources present in the scene along with positions and orientation. Now consider a restriction in the implementation of the shadowing algorithm, for instance let's assume that we're using simple shadow mapping, so that shadows tend to become excessively blocky and ugly when the field of view of the light source is large. This is certainly not desirable but it will do in many cases and for the rest it is reasonable to assume that soon enough someone will be able to contribute time and code in order to replace the simple algorithm with a more sophisticated one which will resolve the issue. At this point all derivatives which up to now suffered from blocky shadows will be automatically upgraded and nothing will have to be changed. That is possible because only the implementation details changed, what a shadow, or a light source is, and how it is defined hasn't.
Another matter that merits some consideration is the interface itself. How exactly will the engineer be able to specify to the programmer how his system is set up? It must be sufficiently capable of describing a physical system with its mechanical interactions, and visual qualities and also to allow a similarly arbitrary specification of the interaction with the user. On the other hand it must be a simple as possible if we're hoping to allow persons inexperienced in the art of computer programming to make use of it.
It is customary for such production systems which are aimed at "the average user" to employ some sort of graphical design approach. That is to allow the user to describe the entities of the world and their interactions and inter-dependencies by means of graphical diagrams. In my view this approach can not possibly allow for enough expressive power and can only be successful if the range of applications is narrow enough. Anyone who has ever attempted to use most of the major easy-to-use graphical application like word processors, spreadsheets and the like in ways deviating from the way the designer meant them to work can probably testify to that.
On the other hand I find the idea of treating the user as some sort of complete imbecile counter-productive not to mention manipulative, patronizing and generally repulsive. It is usually the case that efficiency goes down as so-called `user friendliness' goes up, that is that you pay for getting away with not having to learn how to use an application by having to do more work in order to get the job done. This might be acceptable or even preferable for simple applications that are used infrequently but it is certainly not acceptable, at least in my opinion, for say a professional secretary who is forced to use today's line of office automation software eight hours a day. Widespread belief among such employees that computers exist for the sole purpose of making their life miserable seems to confirm this.
The approach Techne follows is to use a language as the interface between engineer and the system. This is different to many of today's ‘scriptable’ applications where only a subset of the system's functionality can be manipulated, again to some degree, by means of a scripting language. Instead Techne is in effect an interpreter accepting a detailed description of a scene complete with the visual and physical interaction between the entities present and producing an animated rendering of the results of the simulation. This is also different to the way in which a library works. A library might take care of implementing various algorithms for you but its scope is much broader and its interface therefore lower in level. You need to allocate and manage memory, be able to create and handle data structures and perform other similar tasks totally irrelevant to your objective goal.
The chosen language was Lua due to its simplicity, elegance and expressive power and although Lua is a full-fledged scripting language, its main purpose is to offer a formal way of describing a physical system. Most Techne code therefore simply creates objects like physical bodies and shaded surfaces and describes them by setting parameters much like HTML contains text with markup describing the way it's meant to look or the meaning it's meant to convey. When more complicated interactions need to be implemented the usual programming constructs can be used to alter these descriptions dynamically, for instance by adding forces when the user presses a key or by changing a surface when it collides with something else. So although, technically, some form of programming is still involved it is very different to low-level programming: you only need to bother with and hence to understand the workings of the particular system you're trying to simulate. This should hopefully make the production of real-time art and entertainment accessible to more people.
It still remains to be seen how successful this design will be in achieving the aforementioned goals. It has gone through many transformations in the past years but has now more or less stabilized so that very few modifications to the interface were required during the creation of Billiards, Aviation and Airrace, three of the derivatives I have started so far. The results seem to be very promising. Not only does Techne allow the creation of very different products with the same production system but it allows one person to develop and maintain three of them on the side. And there are a lot more that could be implemented with Techne, even as it is now, if only my workload would allow it.