「利用者:Joeedh/GoogleSoC2007 MultiresRefactor」の版間の差分
細 (1版 をインポートしました) |
|
(相違点なし)
|
2018年6月29日 (金) 02:51時点における最新版
Note
This is just a possible idea for a SoC proposal at this point.
|
Joseph Eagar
joeedh@gmail.com
目次
Proposal to Refactor Multires in Blender
Introduction
Multiresoluion Mesh Editing (or Multires) is the technique of allowing a user to displace the subdivided surface of a smooth subdivision surface (usually using the catmull-clarke algorithm).
Blender's implementation of this currently suffers from being RAM-heavy and inflexible. Users cannot edit the topology of a mesh once multires is enabled, because there is no facility to perform destructive/constructive mesh editing operations on the multires data. Excess geometry information is stored for multires, which creates a large memory overhead.
I propose that blender's multires implementation should be rewritten to only store location, normal and texture coordinates for multires data. Rather then storing object-space locations, the displaced vector from the catmull-clarke surface would be stored, in the tangent-space of the mesh's faces. Temporary data will be stored to more easily and quickly draw the active subdivision level.
Special operations will be written, so that the geometry of a multires mesh can be changed.
User Impact
Users will benefit from the ability to edit the geometry of the base level of a multires mesh. No more will users have to deal with not being able to use edge cut, subdivide, or some other mesh tool just because multires is enabled. Also, the memory requirements of multires will be lessened considerably, as the subdivided faces will not be stored explicitly.
Details
Allowing multires to deal with constructive/destructive operations will require writing several simple "operators" that work on it. Integration work will be done with the current editmesh system so tools such as subdivide, extrude, delete/add geometry will all work. These operators will be so-called Euler compatible. Also, the entire system will be N-gon aware, to more easily interface with any future refactored editmesh systems.
The new multires structure will store only the displacement vectors, texture coordinates and normals for each multires level. However, the active subdivision level will need to store opengl vertex arrays containing data to draw the subdivided faces.
Limitations
Operators like join face, and cut face will require finding projected positions from the old multires set of vertices to a new set of multires faces. As such, tools such as subdivide or loop cut may be slower on higher-res meshes.
Deliverables/Schedule
The following items will be implemented in the order they are listed.
- Re-implement multires to only store vertex data.
- Implement DerivedMesh backend for modifiers/render conversion.
- Write version patch for handling old-style multires data.
- Write destructive/constructive mesh operators.
- Interface new multires with renderer.