利用者:Walid shouman/GoogleSummerOfCode/2013/Proposal

Abstract

A generic system to move custom-data between different mesh objects supporting different topologies. Currently we have such a system but its limited to vertex weights.

Project Details

Support different methods to transfer mesh data.

• spacial - find close points on both meshes.
• ray-casting - do ray-trace lookups to identify similar geometry.
• topology - 2 meshes with the same or similar topology.

Support for copying vertex/face custom-data: including shape-keys, UV's, vertex-colors.

Some custom-data would need special handling.

• UV seams would need to be handled to prevent a single face getting UV's from different islands.
• Shape-Keys (may want to limit which ones are copied).

This project would involve re-factoring the existing weight copy tool into a more generic system.

Technical Details

• The shape keys are considered a good starting point to expand the data transfer as it shall behave way too similar to the weight transfer tool (some exceptions will be stated below as details).

• Expanding to the UVs will be the one that's challenging as it will need taking more care for seams and islands.

• For the system to be generic other features should be added including vertex colors and the sculpt data. However, I didn't delve too much into them yet so I'll focus mainly on both the shape keys and the UVs in the upcoming part.

• There are many options that if found will make this tool much more useful in the design workflow

Vertex Weights (the currently working system)

used Datatype: MDeformWeight.

functions interfacing with it found in:

File: blender/editors/object/object_vgroup.c

current example of using it

Transfer tool

having 2 different topologies like those:

Two different topologies

the source would be:

Source object

the destination would be:

Destination object

Essential Challenges

• dealing with multiple vertices that shall inherit the weights (solved)

by giving the opportunity for the user to select between different ways either by nearest-vertex nearest-face nearest-vertex-in-face

Extra Challenges

• making the operator non-destructive (not solved)

by giving the user the option either to overwrite the current layers with the same name or to add new ones

• making the operator interactive (not solved)

by transforming the operator into a modifier which will give the opportunity to select which method is better by changing between the methods in the vertex-weight mode

• checking what vertex groups to copy and not just the selected one (solved)

by giving either (all/active) option but yet it would be a good add to the system if particular groups could be selected

• adding a smoothing factor (not solved)

this one will be so valuable from the user perspective

• dealing with mesh borders (not solved)

in case of copying from a hand mesh to a body with hands mesh the user will transfer the weights ok but the weighting of the body won't be preserved and the user must deselect the vertices other than the hand's could be solved by adding a threshold

note: the fifth point is much more important in the UVs for which we need to know when to stop making UVs for the extra mesh otherwise the UV map will be so crowded at those boarders

Shape Keys

Datatypes: ShapeKeys and keyBlocks functions interfacing with it: File: blender\editor\object\object_shapekey.c

expected example for the transfer shape keys:

source:

Source object

destination:

Destination object

Essential Challenges

• using the same APIs with different datatypes

Extra Challenges

• the same as the first one but the most important thing would be the third one

UV's

Datatype: MLoopUV functions interfacing with it: File: blender\editor\object\uvedit_ops.c expected example for the transfer UVs:

source:

Source object

destination:

Destination object

Essential Challenges

• dealing with island borders/seams

solution: if a loop(v1->v2) was a border in the source mesh then any loop between 2 vertices in the destination mesh that are marked to be the nearest to either V1 or V2 will be a border too Except if those loops didn't form a whole face

• dealing with mesh borders (very similar to the previous one, the main difference is that those are borders found in the source mesh but not found in the target)

solution: making a threshold that if the nearest vertex was further than it, the UVs won't be transferred

• when multiple vertices inherit from a single vertex, its exact value shouldn't be transferred:

solution: making a sliding variable for the user to determine how much each vertex would slide/repulse if this case occurred

Extra Challenges

• the first 3 extra challenges in the weight vertices are considered valid also for the UVs as extra ones

Vertex Color

Datatype:MLoopCol functions interfacing with it: File: blender\editor\mesh\mesh_data.c

Essential Challenges

• expanding the system to vertex colors.

notes

• the pictures have a mesh that is a subdivision of the other one to illustrate different topologies, that was done for simplicity but the sought operators shall be valid on much more topology variations
• the main raytracing function used is BLI_bvhtree_find_nearest

good tools that may be out of scope are:

• to have a mechanism for merging different groups
• to make the transfer happens about the object center or any other specified (x,y,z) so that we can see both the source and destination while the transfer operator is in action

Scope

the scope of the supported CustomData types, which are

• 2: CD_MDEFORMVERT (vertex weights)
• 16: CD_MLOOPUV (UVs)
• 17: CD_MLOOPCOL (vertex colors)
• 28: CD_SHAPEKEY (shapekeys)

Schedule And Milestones

• phase 0) (expected 2 days)

laying down test cases and stating all the challenges to be covered in details.

done

 

• phase 1) (expected 1 week)

applying the transfer function on the shape keys.

done

 

• phase 2) (expected 2~3 weeks)

working on the UVs transfer operator.

in progress 80%

 

• phase 3) (expected 3 weeks)

working on the extras.

in progress 50%

 

debugging the output of phase 1 and 2.

in progress 80%

 

//the midterm will show up within this phase

• phase 4) (expected 2 weeks)

expanding the system for the vertex colors.

done

 

providing clear APIs for the whole system for developers (that may need adding extra functions to ease interfacing with the ones already made and may even rewriting some functions).

to do

 

• phase5) (expected 1 week)

documenting and testing

in progress 30%

 

//at the first day of each phase all the functions to be used from the API and all the functions that are to be made along the phase, will be stated (the interface)

//there's one day between every phase for reviews

//within each phase I shall explore some deep technical insights about the next phase