UVProject modfier does not reflect projector position with shrinkwrap constraint #65340

New Issue

Stellarator Tokamak · 2019-05-31T08:54:31+02:00

2019-05-31 08:54:31 +02:00

When a mesh has the UVProject modifier, and the object selected to be the projector is using a "shrinkwrap" constraint targeting that mesh, any transformations performed by the constraint are not reflected by the result of the UV project modifier.

Replication steps:

Create mesh
Create any material which uses the UV coordinates to display a recognizable pattern or image, and apply to mesh object
Create empty
Add "UVProject" modifier to mesh object, using empty as projector object
Move empty about to confirm that moving the projector moves the image or pattern of the mesh's material
Add "shrink wrap" constraint to empty, using mesh object as target
Position empty such that its orientation when the constraint is enabled is very different from when the constraint is disabled
Enable and disable constraint, observing that changes to the constraint do not change the translation that the UVProject modifier is using to project UV map

Operating system: Windows 10 Home (1803(
Graphics card: NVIDIA GeForce GTX 1080
Blender version: 2.80 (sub 73), branch: blender2.7, commit date: 2019-05-30 22:47, hash: 451c533e25, type: Release
build date: 30/05/2019, 17:02

  - Further details that developers should feel free to read or ignore as they see fit: ----

This behavior does NOT happen (in other words, UVProject works as expected) when the projector is the child of the constrained object, or if the constraint target is a different mesh object.

This at least appears to be a dependency graph issue, because "meshObject depends on empty depends on meshObject etc..." looks like a dependency loop. However, only aspect of the mesh that depends on the projector is the material, not the geometry or transformations, none of which are things that the constrained projector object depends on.

I suppose this might seem esoteric, but I would expect that one of the more useful applications of the new shrinkwrap constraint is using the setup I describe to move UV coordinates while keeping the z axis perpendicular to the surface normal. For example: applying an eye texture to a non-spherical toon eye without distortion. It certainly was the first use that I personally put it to use for.

Obviously if this is an annoyingly involved bug to fix, multiple workarounds are simple enough.

[uv project issue.blend](https://archive.blender.org/developer/F7081055/uv_project_issue.blend) [system-info.txt](https://archive.blender.org/developer/F7081056/system-info.txt) When a mesh has the UVProject modifier, and the object selected to be the projector is using a "shrinkwrap" constraint targeting that mesh, any transformations performed by the constraint are not reflected by the result of the UV project modifier. Replication steps: * Create mesh * Create any material which uses the UV coordinates to display a recognizable pattern or image, and apply to mesh object * Create empty * Add "UVProject" modifier to mesh object, using empty as projector object * Move empty about to confirm that moving the projector moves the image or pattern of the mesh's material * Add "shrink wrap" constraint to empty, using mesh object as target * Position empty such that its orientation when the constraint is enabled is very different from when the constraint is disabled * Enable and disable constraint, observing that changes to the constraint do not change the translation that the UVProject modifier is using to project UV map Operating system: Windows 10 Home (1803( Graphics card: NVIDIA GeForce GTX 1080 Blender version: 2.80 (sub 73), branch: blender2.7, commit date: 2019-05-30 22:47, hash: 451c533e25dd, type: Release build date: 30/05/2019, 17:02 - Further details that developers should feel free to read or ignore as they see fit: ---- This behavior does NOT happen (in other words, UVProject works as expected) when the projector is the child of the constrained object, or if the constraint target is a different mesh object. This at least appears to be a dependency graph issue, because "meshObject depends on empty depends on meshObject etc..." looks like a dependency loop. However, only aspect of the mesh that depends on the projector is the material, not the geometry or transformations, none of which are things that the constrained projector object depends on. I suppose this might seem esoteric, but I would expect that one of the more useful applications of the new shrinkwrap constraint is using the setup I describe to move UV coordinates while keeping the z axis perpendicular to the surface normal. For example: applying an eye texture to a non-spherical toon eye without distortion. It certainly was the first use that I personally put it to use for. Obviously if this is an annoyingly involved bug to fix, multiple workarounds are simple enough.

Stellarator Tokamak commented

2019-05-31 08:54:31 +02:00

Added subscriber: @AdrianPreston

Brecht Van Lommel commented

2019-06-01 03:30:55 +02:00

Added subscriber: @brecht

Brecht Van Lommel commented

2019-06-01 03:30:55 +02:00

This file has dependency Cycles printed to the console. Unless you solve them, the setup can't be expected to work correctly.

Dependency cycle detected:
  OBuv project from constrained projector/Geometry Component/GEOMETRY_EVAL() depends on
  OBconstrained projector/Transform Component/TRANSFORM_FINAL() via 'UV Project Modifier'
  OBconstrained projector/Transform Component/TRANSFORM_CONSTRAINTS() via 'ObConstraints -> Done'
  OBuv project from constrained projector/Geometry Component/GEOMETRY_EVAL() via 'Shrinkwrap'
Dependency cycle detected:
  OBuv project from constrained projector.001/Geometry Component/GEOMETRY_EVAL() depends on
  OBchild projector/Transform Component/TRANSFORM_FINAL() via 'UV Project Modifier'
  OBchild projector/Transform Component/TRANSFORM_SIMULATION_INIT() via 'Simulation -> Final Transform'
  OBchild projector/Transform Component/TRANSFORM_EVAL() via 'Transform Eval -> Simulation Init'
  OBchild projector/Transform Component/TRANSFORM_PARENT() via 'Eval'
  OBchild projector/Transform Component/TRANSFORM_LOCAL() via 'ObLocal -> ObParent'
  OBchild projector/Transform Component/TRANSFORM_INIT() via 'Transform Init'
  OBprojector parent with constraints/Transform Component/TRANSFORM_FINAL() via 'Parent'
  OBprojector parent with constraints/Transform Component/TRANSFORM_CONSTRAINTS() via 'ObConstraints -> Done'
  OBuv project from constrained projector.001/Geometry Component/GEOMETRY_EVAL() via 'Shrinkwrap'
Detected 2 dependency cycles

This file has dependency Cycles printed to the console. Unless you solve them, the setup can't be expected to work correctly. ``` Dependency cycle detected: OBuv project from constrained projector/Geometry Component/GEOMETRY_EVAL() depends on OBconstrained projector/Transform Component/TRANSFORM_FINAL() via 'UV Project Modifier' OBconstrained projector/Transform Component/TRANSFORM_CONSTRAINTS() via 'ObConstraints -> Done' OBuv project from constrained projector/Geometry Component/GEOMETRY_EVAL() via 'Shrinkwrap' Dependency cycle detected: OBuv project from constrained projector.001/Geometry Component/GEOMETRY_EVAL() depends on OBchild projector/Transform Component/TRANSFORM_FINAL() via 'UV Project Modifier' OBchild projector/Transform Component/TRANSFORM_SIMULATION_INIT() via 'Simulation -> Final Transform' OBchild projector/Transform Component/TRANSFORM_EVAL() via 'Transform Eval -> Simulation Init' OBchild projector/Transform Component/TRANSFORM_PARENT() via 'Eval' OBchild projector/Transform Component/TRANSFORM_LOCAL() via 'ObLocal -> ObParent' OBchild projector/Transform Component/TRANSFORM_INIT() via 'Transform Init' OBprojector parent with constraints/Transform Component/TRANSFORM_FINAL() via 'Parent' OBprojector parent with constraints/Transform Component/TRANSFORM_CONSTRAINTS() via 'ObConstraints -> Done' OBuv project from constrained projector.001/Geometry Component/GEOMETRY_EVAL() via 'Shrinkwrap' Detected 2 dependency cycles ```

Stellarator Tokamak commented

2019-06-01 06:14:10 +02:00

Yes, I see the dependency cycle output. Sorry if I didn't communicate well. Ultimately the dependency graph thinking there is a cycle is the issue.

Some of the examples were meant to be just for illustrative purposes. I think that muddied the issue.
Removing everything else still yields one dependency cycle:

Dependency cycle detected:
 **OBuv project from constrained projector/Geometry Component/GEOMETRY_EVAL() depends on**
  OBconstrained projector/Transform Component/TRANSFORM_FINAL() via 'UV Project Modifier'
  OBconstrained projector/Transform Component/TRANSFORM_CONSTRAINTS() via 'ObConstraints -> Done'
  OBuv project from constrained projector/Geometry Component/GEOMETRY_EVAL() via 'Shrinkwrap'
Detected 1 dependency cycles

(emphasis mine)

But at least if I understand how the new dependency graph is supposed to work, it shouldn't register as a recursive cycle.
Unless I've totally missed something, the conceptual chain is:

data.objects.material_slots['checkerboard'].material ( which is also materials['checkerboard'] )
    depends on:    
    object[meshObject].data.uv_layers['someUVmap'] 
        depends on:        
        objects['meshObject'].modifiers['UVproject'] 
            depends on:            
            objects['meshObject'].matrix_world
            objects['meshObject'].data.vertices
            objects['projectorEmpty'].matrix_world 
                depends on:                
                objects['projectorEmpty'].matrix_basis
                objects['projectorEmpty'].constraint['shrinkwrap'] 
                    depends on:
                    objects['projectorEmpty'].matrix_basis
                    objects['meshObject'].matrix_world
                    objects['meshObject'].data.vertices

If I'm wrong and this is expected behavior, then I'm sorry for troubling you, but it does seem like it ought not to get caught in a cycle here.

uv project issue just one pair.blend

Yes, I see the dependency cycle output. Sorry if I didn't communicate well. Ultimately the dependency graph thinking there is a cycle _is_ the issue. Some of the examples were meant to be just for illustrative purposes. I think that muddied the issue. Removing everything else still yields one dependency cycle: ``` Dependency cycle detected: **OBuv project from constrained projector/Geometry Component/GEOMETRY_EVAL() depends on** OBconstrained projector/Transform Component/TRANSFORM_FINAL() via 'UV Project Modifier' OBconstrained projector/Transform Component/TRANSFORM_CONSTRAINTS() via 'ObConstraints -> Done' OBuv project from constrained projector/Geometry Component/GEOMETRY_EVAL() via 'Shrinkwrap' Detected 1 dependency cycles ``` (emphasis mine) But at least if I understand how the new dependency graph is supposed to work, it shouldn't register as a recursive cycle. Unless I've totally missed something, the conceptual chain is: ``` data.objects.material_slots['checkerboard'].material ( which is also materials['checkerboard'] ) depends on: object[meshObject].data.uv_layers['someUVmap'] depends on: objects['meshObject'].modifiers['UVproject'] depends on: objects['meshObject'].matrix_world objects['meshObject'].data.vertices objects['projectorEmpty'].matrix_world depends on: objects['projectorEmpty'].matrix_basis objects['projectorEmpty'].constraint['shrinkwrap'] depends on: objects['projectorEmpty'].matrix_basis objects['meshObject'].matrix_world objects['meshObject'].data.vertices ``` If I'm wrong and this is expected behavior, then I'm sorry for troubling you, but it does **seem** like it ought not to get caught in a cycle here. [uv project issue just one pair.blend](https://archive.blender.org/developer/F7081767/uv_project_issue_just_one_pair.blend)

Sebastian Parborg commented

2019-06-19 10:55:51 +02:00

Added subscribers: @Sergey, @ZedDB

Sebastian Parborg commented

2019-06-19 10:55:51 +02:00

The issue here is that depsgraph is not fine grained enough to be able to break the cycle/not from a circular update loop.

@Sergey it is the case here right?

The issue here is that depsgraph is not fine grained enough to be able to break the cycle/not from a circular update loop. @Sergey it is the case here right?

Sergey Sharybin commented

2019-06-19 11:06:45 +02:00

Changed status from 'Open' to: 'Archived'

Sergey Sharybin closed this issue

2019-06-19 11:06:45 +02:00

Sergey Sharybin self-assigned this 2019-06-19 11:06:45 +02:00

Sergey Sharybin commented

2019-06-19 11:06:45 +02:00

With the current design of dependency graph and modifier stack it is not possible to support such configuration: the shrikwrap constraint needs the final evaluated geometry, which is coming from the modifier stack. However, the object which is being shrinkwrapped is needed for the modifier stack.

While that object is not needed for the geometry "shape", there is no way to know this in advance, and it is not possible have any branching in the modifiers evaluation which could help solving this issue.

Would imagine that nodifying modifier stack and constraint system will help a lot making it more grained what depends on what and at which point. For until that system is implemented would not consider it a bug.

Thanks for the report anyway.

With the current design of dependency graph and modifier stack it is not possible to support such configuration: the shrikwrap constraint needs the final evaluated geometry, which is coming from the modifier stack. However, the object which is being shrinkwrapped is needed for the modifier stack. While that object is not needed for the geometry "shape", there is no way to know this in advance, and it is not possible have any branching in the modifiers evaluation which could help solving this issue. Would imagine that nodifying modifier stack and constraint system will help a lot making it more grained what depends on what and at which point. For until that system is implemented would not consider it a bug. Thanks for the report anyway.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

UVProject modfier does not reflect projector position with shrinkwrap constraint #65340