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:
"reverseOrder"
: shuffle the currently selected objects,
so that the first will be the last and the last will be the first
and so on"el"
: (eazy light) create a distant lightsource situated
at (10,10,10) and pointing to (0,0,0)"deColorTree"
: descend into the selected objects and
change all their red color attributes to "-1" so that the objects
are in fact without color"squashNCXY"
: squash all coordinates of all selected
NURB curves to the XY plane"appendNCP"
: append a point to a NURB curveFurthermore 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.
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?
"ZMin"
, "ZMax"
and
"ThetaMax"
will be ignored."ThetaMax"
will be ignored."ThetaMax"
will be ignored."ThetaMax"
will be ignored."PhiMin"
,
"PhiMax"
and "ThetaMax"
will be ignored.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.
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.
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?
"set env(SHADERS)
<newshaderpath(s)>"
in the console; then let The Mops scan for shaders using "scanAllShaders"
."load <path>/crtshdscn.tcl"
."crtshdscn"
. A lot of spheres and lights should be
created now automagically.
There are numerous ways to increase drawing speed:
"Hide"
and "Show"
in the "Tools"
menu.
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.
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.
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.