Transform generalized custom-data correction support #69707

New Issue

Campbell Barton · 2019-09-10T11:23:57+02:00

Campbell Barton commented

2019-09-10 11:23:57 +02:00

Motivation:

Having to manually adjust custom-data is tedious
while there is a UV correction option,
it's limited to vertex & slide.

This proposal is to generalize the option so it can be used for any
transform mode.

Solution:

This proposes to add two kinds of custom-data correction methods.

Correct based on surrounding geometry, this is suitable for

vertex & edge slide.

The existing logic for vertex & edge slide can be used here.

Project Custom-Data

This would project geometry onto the surfaces of the original mesh
to calculate the custom-data.
This would allow geometry.

This could be used for other transform modes besides vertex/edge slide.

Limitations:

This option works best when adjusting small regions of geometry and often won't work well moving large regions of faces.

There is a limit to how much UV's can be corrected in this case without re-unwrapping/projecting
(which is beyond the scope of this proposal).

User Interface:

These would be shown in the tool options panel, we could keep the transform option too (although this isn't essential).

There is a risk that users accidentally leave this enabled and transform their UV's when moving the geometry.

Since we have other fairly obscure options (transform origins for example), it may be best to show these are enabled while transforming (as we do for auto-keyframe).

**Motivation:** Having to manually adjust custom-data is tedious while there is a UV correction option, it's limited to vertex & slide. This proposal is to generalize the option so it can be used for any transform mode. **Solution:** This proposes to add two kinds of custom-data correction methods. - Correct based on surrounding geometry, this is suitable for ``` vertex & edge slide. ``` *The existing logic for vertex & edge slide can be used here.* - Project Custom-Data ``` This would project geometry onto the surfaces of the original mesh to calculate the custom-data. This would allow geometry. ``` ``` This could be used for other transform modes besides vertex/edge slide. ``` **Limitations:** This option works best when adjusting small regions of geometry and often won't work well moving large regions of faces. There is a limit to how much UV's can be corrected in this case without re-unwrapping/projecting *(which is beyond the scope of this proposal).* **User Interface:** These would be shown in the tool options panel, we could keep the transform option too (although this isn't essential). ---- There is a risk that users accidentally leave this enabled and transform their UV's when moving the geometry. Since we have other fairly obscure options (transform origins for example), it may be best to show these are enabled while transforming (as we do for auto-keyframe).

Germano Cavalcante was assigned by Campbell Barton

2019-09-10 11:23:57 +02:00

Campbell Barton commented

2019-09-10 11:23:57 +02:00

Added subscriber: @ideasman42

noki paike commented

2019-09-11 09:34:22 +02:00

Added subscriber: @nokipaike

noki paike commented

2019-09-11 09:34:22 +02:00

Limitations:

This option works best when adjusting small regions of geometry and often won't work well moving large regions of faces.

Out of curiosity, could this generalization also work for high density mesh?

from the way it is described it seems to me the same concept ..
"by selecting minor regions of high density mesh they could be moved smooth"

>Limitations: > >This option works best when adjusting small regions of geometry and often won't work well moving large regions of faces. Out of curiosity, could this generalization also work for high density mesh? from the way it is described it seems to me the same concept .. "by selecting minor regions of high density mesh they could be moved smooth"

Germano Cavalcante commented

2020-06-17 14:01:00 +02:00

I think this task can be closed as resolved.
In the transform code we now have this function:

void trans_mesh_customdata_correction_init(TransInfo *t, struct TransDataContainer *tc);

Perhaps the name can be improved.
Just call this function when initing the desired transform mode and the rest is automatically resolved.

I think this task can be closed as resolved. In the transform code we now have this function: ``` void trans_mesh_customdata_correction_init(TransInfo *t, struct TransDataContainer *tc); ``` Perhaps the name can be improved. Just call this function when initing the desired transform mode and the rest is automatically resolved.

Campbell Barton commented

2020-06-17 14:32:53 +02:00

@mano-wii I think this should be kept open until this is exposed to the user.

Campbell Barton commented

2020-06-19 04:19:44 +02:00

How should this option be exposed to the user?

Would having a single "UV/Custom Data Correction" tool-setting toggle in the "Options" popover be OK?

Then all tools that support UV correction would use this, either to replace the option, or to initialize the option which could still be toggled from the operator.

How should this option be exposed to the user? Would having a single "UV/Custom Data Correction" tool-setting toggle in the "Options" popover be OK? Then all tools that support UV correction would use this, either to replace the option, or to initialize the option which could still be toggled from the operator.

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Transform generalized custom-data correction support #69707