利用者:ReD Fox/SummerOfCode2007

Feature list

The project's expected features:

1. Bevel tool
   1. Works only on selected geometry
   2. Properly handles selection modes (vert/edge/face)
   3. Can use either per-vertex or per-edge beveling methods
   4. Bevel amount can be specified either as a radius or a distance
   5. Bevel resolution can be set to an arbitrary value
   6. Allows numeric input and CTRL/SHIFT value constraints
   7. Bevels both face and edge (wire) geometry
   8. Works with f-gons/n-gons
   9. Works intelligently with UV's, vertex groups, vertex colors, etc.
   10. A real-time, actual-data preview
   11. Will use the BMesh API
   12. Core functions will be shared with the bevel modifier
2. Bevel modifier
   1. Can use either per-vertex or per-edge beveling methods
   2. Bevel amount can be specified either as a radius or a distance
   3. Bevel resolution can be set to an arbitrary value
   4. Bevels both face and edge (wire) geometry
   5. Works with f-gons/n-gons
   6. Works intelligently with UV's, vertex groups, vertex colors, etc.
   7. Can selectively bevel based on the angle of the edge
   8. Bevel amount can be limited based on:
      1. Vertex weight values
      2. Edge crease values, or a custom flag (custom flag is still under consideration)
      3. Percentage of edge size (optional; still under consideration)
   9. Will use the BMesh API
   10. Core functions will be shared with the editmode bevel tool
3. Offset tool
   1. Keeps edges and faces of new geometry as parallel to original geometry as possible
   2. Works only on selected geometry
   3. Properly handles selection modes (vert/edge/face)
   4. Allows numeric input and CTRL/SHIFT value constraints
   5. Offsets both face and edge (wire) geometry
   6. Works with f-gons/n-gons
   7. Works intelligently with UV's, vertex groups, vertex colors, etc.
   8. A real-time, actual data preview
   9. Will use the BMesh API
   10. Core functions will be shared with the shell modifier
4. Shell modifier
   1. Creates a thickened 3D volume in the same shape as the original surface
   2. Keeps edges and faces of new geometry as parallel to original geometry as possible
   3. Works only with face (solid) geometry
   4. Works with f-gons/n-gons
   5. Works intelligently with UV's, vertex groups, vertex colors, etc.
   6. Will use the BMesh API
   7. Core functions will be shared with the editmode offset tool

Implementation details

Goals

1. Maximise code sharing and reuse.
2. Utilize the BMesh API.
3. Create tool code that is not dependent on the environment from which it was called.
4. Ensure that the editmode tools have a copy of the original mesh data easily available while the tool is in progress.

General design

Basically, two new BMesh tools will be created: a bevel tool and an offset tool. Although, for the most part, these tools will remain separate, both of these tools will share a common design. Whenever functionality is needed from one of these tools, the mesh data will be passed as a BMesh along with the appropriate parameters. The BMesh that is passed to the tools will be modified by them, and it is up to the calling function to ensure that the BMesh data is then converted to a usable form.

In order to directly take advantage of these new areas of functionality, four tools will be added to Blender: two new modifiers (bevel and shell), and two new editmode tools (bevel and offset; one of which exists already, but will be completely replaced). These tools will make use of generic conversion functions to convert their native mesh types to a BMesh that is then passed to the desired BMesh tool. Another generic conversion function will convert the modified BMesh back to the original mesh type for further use in Blender.

Tool processes

The new modifiers will be fairly straightforward to implement. They will merely copy the DerivedMesh data to a new BMesh, will call the appropriate BMesh tool function, and will copy the modified BMesh back to a new DerivedMesh.

The editmode tools will need to be a bit more complex if the user is allowed to interactively change the values. For the editmode tools, a copy of the original EditMesh data must be saved when the tool is invoked. The undo stack is a preferred candidate for its location. This copy will serve two purposes. First, it will be restored if the tool is cancelled, and second, it will serve as base data for use when the user interactively changes values. Once the editmode tool is invoked and the original EditMesh data is saved, the tool will monitor the input by the user. Whenever the user changes a value (via mouse movement, numeric input, key presses, etc.), the tool will create a new BMesh from the original data, will call the appropriate BMesh tool function, and will copy the modified BMesh back to the editmode EditMesh data structure for display to the user.

Diagram and further comments

1. Although it is not shown in the diagram, there are areas of overlap between the bevel and offset algorithms (specifically, polygon inset). In addition to sharing code between the modifiers and the editmode tools, code will also be shared between the two functionalities themselves whenever it is practical to do so.
2. Again, it is not shown in the diagram, but I may implement another level of redirection between the BMesh conversion and the core tool operations. For example, the editmode bevel tool can be limited based on selection, and the bevel modifier has an entire host of methods that can be used to limit the bevel not only to certain parts of the mesh, but to different amounts within those parts. It is my thought that compiling this data into a single, generic value, independently from the major beveling functions, will help keep the core operations maintainable, extendable, and free from context-specific dependencies.
3. When I created this diagram, I envisioned that the editmode tools would keep two copies of the original data. One EditMesh copy for easy restoration and undo, and one BMesh copy that could be quickly copied and passed to the appropriate function. The assumption was that copying an EditMesh to a BMesh would be significantly slower than simply replicating a BMesh (speed is important during a live, interactive preview). If this is the case, then the diagram accurately represents my vision for this project. However, if replicating a BMesh only offers miniscule performance gains over converting the EditMesh, then it may be more profitable, and simple, to save a bit of memory and convert the EditMesh to a BMesh directly each time, without "caching" the result.

Individual tool details

See the following pages for individual tool details:

1. Editmode Bevel Tool
2. Bevel Modifier
3. Editmode Offset Tool
4. Shell Modifier

Original Proposal

Google Summer of Code 2007 proposal - The original proposal for the bevel and offset tools and modifiers

Current progress

06/06/07 - Hooks added to the modifier stack for the bevel modifier

06/13/07 - BMesh API code added; derivedmesh-to-bmesh-and-back-again conversion functions tested