User controlled creation of Progressive Meshes - Documentation
- Introduction
- Loading the plugin
- Quick run: example data
- Creating a new ProgressiveMesh
- Changing the resolution
- Painting weights
- Attribute options
- Vertex placement policies
Introduction
This is a short summary on how to use the plugin. It mainly explains the options available.
First, here's an annotated screenshot from a typical Maya session using the ProgressiveMesh plugin.

Fighter model by Tobias Mayr - visit his site
Loading the plugin
Before you can use the plugin, you need to load it. Use the "Plug-In Manager": "Window -> Settings/Preferences -> Plug-In Manager"
You should either load "ProgressiveMesh_Release.mll" (recommended) or "ProgressiveMesh_Debug.mll". It's also recommended to auto-load the plugin.
For more information on installing and loading the plugin, please refer to the README.txt file that comes with the download.
Quick run: example data
If you want to try out the plugin quickly, simply load the included example "pm_fighter.mb"
If you don't see two fighter models, after loading, you probably haven't installed the plugin properly.
For more information on installing and loading the plugin, please refer to the README.txt file that comes with the download.
If you do see the two fighters: click on the right one, click "ProgressiveMesh1" in the Channel Box or the Attribute Editor
and start playing with the Resolution. Enjoy.
Creating a new ProgressiveMesh
After you've installed and loaded the plugin properly, you should have a new "ProgressiveMesh" menu (see image).
If this menu is not present, please refer to the README.txt file that comes with the download
for more information on installing)
Now creating a progressive mesh is simple: select a polygonal mesh (no nurbs mesh) and invoke the "Create PM" command (ProgressiveMesh -> Create PM.
This creates a new Progressive Mesh from the polygonal mesh.
Please note:
The original mesh remains unchanged
The Progressive Mesh is created as a copy
A Progressive Mesh is always triangulated
The Progressive Mesh is always created at the coordinate origin (0,0,0)
The Progressive Mesh is always created with no scaling (if the original mesh was scaled, the PM will have a different size)
If more than one polymesh is selected, a Progressive Mesh will be created from every selected polymesh (this results in multiple PM's all at the coordinate origin)
Once you've created a Progressive Mesh you can start playing with it's resolution and other options
Changing the resolution
To change the resolution (the number of faces) of a Progressive Mesh:
- Select the Progressive Mesh
- Change the 'Resolution' attribute
The Resolution is specified in percent (0..100). Usually, the plugin is fast enough, that you can change the resolution in realtime.
Painting weights
By changing the resolution of a Progressive Mesh you can control how many faces the mesh has.
But there are situations in which it is desirable to have more detailed control over the reduction
process. This is especially true for interactive applications (such as games or simulations) where
one wants to use Progressive Meshes for dynamic LOD and load balancing. For these applications,
usually one wants all intermediate representations to look as good as possible. And often, some
parts of the geometry might just be more important to you than others.
E.g. in a game, for your model of the main character, you might want to have a way to tell the reduction algorithm
to reduce the face less than the rest of the body. Another common example is skeletal animation:
You might want to reduce the deformable regions around the joints less than the rigid regions.
To address these needs, I've developed a new error metric that let's one specify the importance
of regions interactively and intutively. The user simply paints the importance onto the original model,
similar to weight painting.
For an example view the image at the top of the documentation section: the knees and the head of the
fighter model were marked as being more important than the rest of the model.
Now, as the model gets reduced the head and the knee are remains at higher resolution than the rest of
the model. The overall facecount stays the same, the faces are just distributed non uniformly.
To use this feature, select the Attribute Paint Tool on the original model (select the model, Modify -> Attribute Paint Tool)
(You might want to open the Attribute Paint Dialog to adjust the settings.)
Now you can start painting on the original model: Unmarked areas are black. Black means that these
faces are of no special importance. The more weight you paint (gets whiter and whiter) the more important
this region becomes for the reducer.
You can paint while the model is reduced (e.g. 50% of it's original resolution). In this case, the changes
become visible immediately: while you paint e.g. the face of the model, more and more polygons will pop up
in the face of the reduced model.
However, because the reducer has to re-reduce the model after each paintstroke, this is a somewhat slow process.
You might consider painting while the resolution is set to 100%.
Attribute options
The plugin doesn't only consider the original geometry of the input model, it also can consider
the original's attributes.
The plugin can consider these attributes:
UV's (texture cooridnates)
Normals
Vertex Colors
All attributes are handled similar. Because I consider the UV's being the most important attribute, I'll
explain the attribute options for the UV's in more detail than the others.
UV's (texture coordinates)
You can tell the plugin to consider UV's while reducing or not.
set "Use UVs" to on: consider UV's while reducing
set "Use UVs" to off: don't care for UV's while reducing
If "Use UVs" is set to off, the plugin only tries to minimize the geometric error while reducing.
Texture coordinates are simply ignored. If "UseUVs" is set to on, the UV error is also minimized: the
plugin creates new texture coordinates while reducing the geometry.
The texture coordinates are synthesized to create a very similar looking model.
If "Use UVs" is set to on, you can also use the "Clamp UVs" and "Lambda UVs" options. If "Use UVs" is set to off, these options are ignored.
"Clamp UVs": should the texture coordinates be clamped to 0..1?
"Lambda UVs": how important are the texture coordinates compared to the geometric error?
If you're dissatisfied with the texturing of the reduced models, set "Lambda UVs" to a higher value, maybe
1.5 or 2 or so. If you think the UV's are considered too much, lower the "Lambda UVs" value. Now the plugin
considers the UV error less than the geometric error. Usually you can set "Lambda UVs" to values below 0.1
and still get decent results. Dont set it to zero, this will remove all UV's
Normals
"Use Normals": should normals be considered while simplifying?
"Unitize Normals": should normals be kept at unit length?
"Lambda Normals": how important are normals during simplification?
Vertex Colors
"Use Vertex Colors": should vertex colors be considered while simplifying?
"Clamp Vertex Colors": should vertex colors be clamped to 0..1?
"Lambda Vertex Colors": how important are vertex colors for the simplification
Vertex placement policies
Using this option you can tell the plugin, whether it's allowed to create new vertex positions during
simplification or not.
There are three different vertex placement policies:
- optimal: produces best results, introduces new vertex positions
- end or mid: produces good results, introduces new vertex positions
- endpoint: produces ok results, leaves original vertex positions untouched
For best results, you should choose the "optimal" setting. However, there are situations,
where you might want to use the "endpoint" setting. This setting forces the reducer to only
use the original vertices for reduction. In other words, your progressive mesh always only uses
the original vertices. This is important for e.g. games, where you don't want to retransmit the
whole vertex array for each resolution of the model. Using "endpoint" you can transmit one vertex
array at the beginning. Each different resolution is just a different index list.
This page is maintained by Erik Pojar. If you have any suggestions or questions, contact me via email: "erik" "at" "pojar" "dot" "net"
Last update: 2002-05-31