![[LinuxFocus Image]](border-short.jpg)
![[Navegation Bar]](Navegator-bar.gif){kind=small}
| News Archives Companies Tips |
Minds Eye Rendering/Modeling Packageby Martin van Velsen |
Beforehand
What is Minds Eye
History
Design
Future Technologies
Usage
References and Related Links
BeforehandMindsEye 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. What is Minds Eye?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. HistoryAbout 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. DesignThe 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: So how does this setup look like in the actual program ? Like this:  On of our modules is the animation module. It is basically a 3d editor specializing in animation. It uses our viewport manager which in turn uses our generic viewport code. All of our code is modular and can be used in other parts of the program. So for example, in the screenshot below you see a rough version of the animator, with 4 viewports.  For our 3d output we use OpenGL. The makefiles assume you are using MesaGL if you are working under Linux. The GUI toolkit you see in action, is the QT toolkit from TrollTech ( http://www.troll.no ). We chose this toolkit because it features some elements that we needed and which no other toolkit could produce ( at least not on a GPL basis ). At the time we started Gtk was not at a point where we felt confident to use it. Also we had specific wishes for the GUI that Gtk was unable to produce and Qt was.  Just like the other commercial programs, MindsEye will feature a materials editor. Like all the other parts this module's code is based on other code. For example the viewports that display the materials will be the same for light source dialog boxes. They are derived from base code that displays an OpenGL sphere with several properties. The viewports will know how to deal with all the properties. The materials editor will then only have to deal with the managing of all the materials and data currently available. As with all parts of the program, the philosophy is: devide all the parts into it's most basic form. Basically following the path that made Unix the way it is now.  For our rendering output we use.... whatever is out there. Some engines will be used internally like the SIPP engine. Some engine will be used as external programs. It all depends on the nature and complexity of the target rendering system. If the output engine is internal, then it will basically be loaded as a plugin. The render module will know how to deal with it and will hand it a datastructure and a buffer to store the rendered image along with some parameters. Right now we are looking at SIPP, POVRay and Renderman as our renderers but developers can hook up anything they like to it. As anything else within MindsEye all interfaces will have a well defined API. Future TechnologiesMindsEye 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: 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. 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. 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. UsageAt 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.  References and Related LinksMindseye:http://mindseye.luna.net http://yukon.genie.uottawa.ca/info/soft/nurbs (Libs needed) http://www.troll.no (Libs needed) Mailing list: http://mailarchive.luna.nl/mindseye/ FileFormats: http://www.mediatel.lu/workshop/graphic/3D_fileformat/h_format.html http://www.dcs.ed.ac.uk/%7Emxr/gfx/3d-hi.html http://www.cgrg.ohio-state.edu/~smay/RManNotes/rmannotes.html http://www.europa.com/~keithr/ http://www.sdsc.edu/vrml/ http://ourworld.compuserve.com/homepages/thbaier/ Mesa(OGL): http://ssec.ssec.wisc.edu/~brianp/Mesa.html http://www.sgi.com/Technology/openGL/ ftp://iris.ssec.wisc.edu/pub/Mesa/ RayTracers: Pov: http://www.povray.org/ http://www.geocities.com/SiliconValley/Lakes/1434/ http://www.europa.com/~keithr/ BMRT: http://www.seas.gwu.edu/student/gritz/bmrt.html Other Modellers: http://www.cs.ubc.ca/nest/imager/contributions/forsey/dragon/top.html http://www.comp.lancs.ac.uk/computing/users/andy/ac3d.html http://http.cs.berkeley.edu/~schenney/sced/sced.html http://users.aimnet.com/~clifton/spatch/spatch.html (This place has a ton of good stuff) http://www.seas.gwu.edu/student/gritz/rmanlinks.html QT: http://www.troll.no Nurbs: http://yukon.genie.uottawa.ca/info/soft/nurbs http://www.cs.ubc.ca/nest/imager/contributions/forsey/dragon/top.html Similar projects: http://www.fpa-engineers.com/OD/ http://www.cybersociety.com/moonlight http://www.geocities.com/SiliconValley/Lakes/7705/Virtuoso.html Other intresting sites: http://www.ics.uci.edu/~eppstein/gina/csg.html http://www.cgrg.ohio-state.edu/~smay/AL/ http://www.XCF.Berkeley.EDU/~gimp/gimp.html http://www.cs.umn.edu/~amundson/gtk/ http://arch.hku.hk/people/matchy/Tcl.html http://metallica.prakinf.tu-ilmenau.de/Generic/Generic.html http://www.mdstud.chalmers.se/~md3msns/rayeng.html http://cg.cs.tu-berlin.de/~ki/engines.html http://www.cs.rpi.edu/~martink/ http://www.coolfun.com http://www.grimmware.com/CrystalSpace/ http://www.cs.technion.ac.il/~gershon/irit/ ftp://ftp.eecs.umich.edu/.0/people/aprakash/collaboration/papers/CSE-TR-156-14.ps.gz |
This website is maintained by Miguel A Sepulveda.