by Martin van Velsen
Minds Eye Rendering/Modeling Package
For about 2 years now there is a project going on called
MindsEye. This project aims to create a
Modeling/Rendering/Animation package for Linux/Unix that is
equivalent with the big programs like 3D Studio Max or
LightWave. So far, the development has been going very well
after a rough start. Some of the implementation designs and
engineering is rather unique for modeling programs.
MindsEye is currently in it's early stages. Most work is done underneath the interface. So this means that if you try it out the actual functional parts may differ on a dayly basis. We believe in a good design foundation before giving users cool toys to play with.
Right now the modeling and rendering market is dominated by expensive commercial software packages. MindsEye is ( or will be ) the freeware (gpl) answer to a package that can compete with these commercial versions. Taking the best of both worlds and some innovative new techiniques MindsEye tries to be an overall platform for all 3d graphics purposes.
About 2 years ago, when linux was still very much a hackers operating system, the idea popped up to start work on a renderer/modeler/animation program for Linux. Inspired by what was done by the Gimp people we set to work to see if it was possible to actually write such a beast. For about a year we played with some design ideas. At the beginning it started out completely wrong. Posts were made in newsgroups to see if people were interested to join. We got a lot of replies and it seemed that there would be no problem starting this project. The name then was Free-D. A name that was later changed to MindsEye because it would have caused confusion with the Free3D library project. Very very slowly the project grew. Along the way were traps and pitfalls that had nothing to do with the project. For example people have a specific idea of what they would like to see implemented. So on our mailing list we would frequently see arguments going back an forth on design specs. It took more than a year to actually produce some code.
The most interesting part about MindsEye is it's design. All parts are modular from the smallest element to the biggest parts like the modeler. At the hart of the program is what we call the MindsEye kernel. This is piece of software that is by itself incapable of doing any graphics work. Instead it manages all the modules and plugins. you could call it a big resource manager. It is also the place where the entire datastructure is kept. There is a distinct difference between a module and a plugin in MindsEye. A module is some dynamic code that the kernel is aware of. A module will be loaded and unloaded by the kernel. When we say "aware", it means that the kernel knows something about the modules. For example the network module is a gateway that connects several kernels. The network module could be viewed as a dummy module that replaces one of the other modules. Right now we have defined a set of basic modules, these are:
MindsEye aims at a program that is very solid from a
software architecture point of view. A lot of new technologies
will be implemented and the program might very well function as
a test bed for new rendering and modeling techniques. Some of
the features that we are planning to integrate are:
RCS for worlds
Chances are that in the near future scenes will get bigger and more complex. Managing these large worlds is a task by itself. MindsEye wants to facilitate an easy way to work on one scene with more than one modeler at the same time. Being able to do that saves integration time and cuts down on total modeling time. One way to do that is to implement a kind of RCS ( Revision Control System ) for scenes/worlds. For example a modeler might be working on a small set of data in a large scene. This data will be locked for that modeler. Other people can work on other parts of the data without disturbing models that are locked by other modelers.
Programming the LEGO® way
Each MindsEye kernel is nothing more than a task and resource manager. If you want to run any of the modules you will need the kernel. One advantage of having a kernel based system is, that it makes the whole package work more or less like LEGO ©. How does this concept work in real life ? Well suppose you have an animation company called Paxir. You are working on a new movie and you decided to use MindsEye as your main development platform. The company is used to working with clusters of modelers and has one main rendering farm. Setting such a system up with MindsEye would be relatively easy to do. On each machine, no matter what kind of platform or purpose, a bare MindsEye system is installed. Depending on what the role of that machine is, modules are added. So one cluster of modelers would have the kernel and modeling module together with a rendering module and a preview plugin. The rendering farm on the other hand would have the kernel and the network module together with the favorite rendering plugin. Each kernel would understand it's role and act accordingly.
Transparent Network Rendering
As explained in the last section, network rendering should be a lot more flexible with MindsEye. What it comes down to is daisy chaining a set of MindsEye kernels and let each one of them render part of the animation. In effect each kernel is responsible for it's task even though the render-module and rendering-plugin does the actual work. Through the entire design and engeneering work of the program a modular setup is kept in mind. A lot of ideas and concepts are kept in mind when programming for this project. Network support is only a small part but as you can see it is at the very hart of what MindsEye stands for.
At the moment MindsEye is a program that is very interesting from a developers point of view. For general users it's not that usefull. We are working hard to get the core of the program done very well. When that is done, chances are that functionality will come in accelerated rate. You can see a screenshot of the current modeler setup below. This is a view of MindsEye-0.5.19 on an Enlightment desktop. In the modeler you can see that a scene is loaded called: rings5.nff. MindsEye has the capability to load multiple scenes. Although not a lot of file formats are supported yet, the code that drives the loading and saving is very flexible. Protocols are being build and designed to dynamically add file-types. Each type is loaded by it's appropriate plugin. MindsEye will be able to do active plugin scanning. This means that components can be added and removed on the fly.
Webpages maintained by the LinuxFocus Editor team
© Martin van Velsen, FDL
2002-11-02, generated by lfparser version 2.34