Next Previous Contents

7. Miscellaneous

7.1 The Mopsrc File

To customize The Mops the mopsrc file may be used. This file is either pointed to by the environment variable MOPSRC or is determined as following, on Unix it is "~/.mopsrc" on the Win32 platforms it is "$(HOME)/mopsrc" if the environment variable HOME exists, else "$(TEMP)/mopsrc".

There is an example mopsrc file provided in the distribution (located in the src directory) that provides also some helpful little Tcl-procedures for various otherwise difficult tasks. These are in short:

Furthermore you may adapt the shortcuts used in the GUI to your special needs using the mopsrc file. Note, that if you do that the GUI (the menu entries) will adapt to your changes but certainly not this documentation and the tutorials!

Note also, that mopsrc carries also preference settings saved by the main menu entry "File/Save Prefs", in a way that the saved settings override the manually made changes in the mopsrc file.

7.2 The Mfio (3DMF Import/Export) Plugin

This plugin is based on the free 3DMF parser by Apple (Duet Development Corp.). I tried to use this code to write 3DMF's as the basic file format for The Mops, but I failed for several reasons. I abandoned the idea to have a standard file format as scene storage and recycled my code to this plugin.

Unfortunately, not every feature and every attribute The Mops supports can be expressed in standard 3DMF. This means, when exporting/importing Mops scenes to/from 3DMF you will most possibly lose information. On the other hand, the import filter does not support all possible 3DMF objects and attributes, currently. You will not be warned if the import filter encounters such objects, they will be silently ignored.

Note, that the code of the 3DMF parser is not very stable, another reason to put in in a plugin. It is for instance not possible to compile it with optimization (breaks the compiler (SGI-cc), or breaks the code (gcc)). You should try to compile it once with -Wall...

Anyway, I (hopefully) fixed reading of ASCII 3DMFs for the MIPS and SPARC platform (it did just run on Intel in the first place). But it is currently not possible to read binary 3DMFs across different byte-order platforms. If you want to change this, you could look for (and debug) the handling of the MF3DBinaryFilePosition, which seems to be broken in the swapped case.

What objects may be currently exported?

All other objects, views and lights will be ignored.

Import is currently not working very well. What objects may be currently imported?

Not all possible types of transformations are supported by the import filter, missing transforms are e.g. quaternions and rotate around point.

7.3 Limitations of The Mops

The Mops imposes some special limitations (when compared with other professional expensive modelers) that helped to keep the code a bit simpler, but limit you in a way that the number of possible different routes (modeling steps) to achieve a certain shape is smaller. This, of course, does not limit the number of shapes you can model. You just have to think a bit more before modeling, or, the number of modeling steps may be a bit higher to achieve the same results.

Now, what are these limitiations?

First, modeling is only possible in parallel views. And the input plane is always restricted to the viewing plane of the view you are modeling in.

In other words, in a view of type Front you move objects in the direction of the XY plane and rotate about Z _and nothing else_. If you want to move about Z, choose a different type of view. These limitations do not apply if you move your objects using the Transformations property, of course.

Second, certain tools to create more complex shapes, like the revolve tool, operate in a similar limited fashion. The revolve tool, for instance, does only revolve curves that lie in the XY plane about the Y axis. Note, that all limitations of this kind have been choosen to let you happily model your lower level primitives (curves) in a Front view (the extrude tool extrudes curves that lie in the XY plane along the Z axis etc. pp.). Therefore, your major view type for creation of simple objects should be Front. For a complete reference of the limitations of these tools refer to the according sections in the documentation.

7.4 Using The Mops compiled without libslcargs

If The Mops has been compiled without libslcargs certain functions of The Mops will get crippled. This section should help you to get around some limitations.

Since no library is available for parsing compiled shaders, it is not possible to assign shaders to objects using the "Set new Shader" buttons in the shader property GUI's. It is still possible to assign shaders to objects, but you have to use the property clipboard instead.

This implies that there are objects in your scene that already have shaders assigned so that you can copy the shaders from them.

There are two Mops scene files available for exactly that purpose. They contain a number of objects each with one of the most basic shaders assigned to. If you get to the point to assign shaders to your objects, insert one of the shader scenes, then copy the shader to your object.

The scene "stdshd.mop" contains all shaders from the shaders directory of BMRT, this are all shaders required by the RenderMan standard. The scene "exampleshd.mop" contains all shaders from the example directory of BMRT. This should get you going for your first steps.

You can also create your own scene files with the help of the Tcl script in the file "crtshdscn.tcl" (create shader scene).

How do you use that script?

  1. You need a Mops that has access to libslcargs.
  2. Adapt your environment variable SHADERS, to point to the shaders you want in your new scene. You do not have to leave The Mops to do this, simply type "set env(SHADERS) <newshaderpath(s)>" in the console; then let The Mops scan for shaders using "scanAllShaders".
  3. Load the file crtshdscn.tcl in the interpreter using "load <path>/crtshdscn.tcl".
  4. Create a level and enter it now.
  5. Type "crtshdscn". A lot of spheres and lights should be created now automagically.
  6. Save the scene. Thats all.

7.5 Increasing drawing speed

There are numerous ways to increase drawing speed:

7.6 How can you help?

You can do a lot of different things, that would make me really happy and help me to actually get The Mops to V0.42.

  1. Implement custom objects. This will be discussed a bit more later on.
  2. Donate source to improve several critical parts of the modeler, a better picking code or an own (better than the current Mesa-GLU) NURB tesselation would be something I'd really appreciate. More ideas: better (more exact) lighting simulation (is this possible to do with OpenGL at all?), CSG-preview with OpenGL, Import of RIB's using the Affine Toolkit, support for subdivision surfaces.
  3. Debugging the MF3D code, which is currently not working well with binary files from different byte-order platforms would help too.
  4. Donate money by registering ShellyLib. ShellyLibs source will be converted to a first high level custom object that creates objects of type seashell for The MopsV0.42. This object, however, will be Shareware!

You can help by implementing more different high level objects like Trees, Landscape, Sky, Text, whatever you can think of. Note, that the license of The Mops does not prevent you from implementing your object as Shareware, Freeware or even full Commercial ware.

But please do me a favour and do not implement objects like simple triangles or polygons. This would be something that really is not intended by me, and it would surely show the limits of the current design of all code operating on the scene structure. Mops objects should be high-level objects!

Reading the last paragraph you might think that I am a bit biased against polygonal models. I am not. Polygonal models are the only way to preview complex geometry using hardware accellerated graphics, for the moment. But even while RenderMan supports rendering of polygonal models their use as a primitive is not recommended for good reasons. In other words, use polygonal models in the modeler as quick representation of your higher level objects, but please, if you are going to actually render something, do not use that polygonal representation. If you want to go a complete polygonal way instead, voila, there are good modelers out there.

7.7 Acknowledgements

First of all, I would like to express a big "Thank you!" to Bernd (Pink) Sieker. He is the first real Mops user and beta tester, who urged me during the last year via E-Mail and on IRC to fix this particular bug, add some essential features, move the lights again etc. pp. in countless iterations. Pink, without your help I surely would not be that far, thanks!

Furthermore, I would like to thank the following people:

OpenGL (R) is a registered trademark of Silicon Graphics, Inc.

The RenderMan (R) Interface Procedures and Protocol are: Copyright 1988, 1989, Pixar All Rights Reserved

RenderMan (R) is a registered trademark of Pixar

The Affine Libraries and Tools are Copyright (c) 1995, 1996, 1997, 1998 Thomas E. Burge All rights reserved.

Affine (R) is a registered trademark of Thomas E. Burge.


Next Previous Contents