Shrinkwrap modifier of target curve is ignored when using the Curve modifier #51603

Closed
opened 2017-05-24 00:25:38 +02:00 by s12a · 11 comments

System Information
Intel i5 3550
AMD Radeon RX480 4GB (Radeon Software 17.5.2)
Windows 10 64bit

Blender Version
Broken: 2.78.5 3bf69b2, 2.78c official

Short description of error
When using the Curve modifier on a mesh, the mesh will only deform along the base geometry of the target curve and will not take into account whether the curve is being deformed with some modifier like Shrink Wrap.

Exact steps for others to reproduce the error
I have attached a .blend file where this issue can be quickly observed.

shrink-wrap-bug.blend

  1. Toggle the visibility of the Shrinkwrap modifier of the target curve on and off.
  2. The mesh deformed with the Curve modifier will not change.
**System Information** Intel i5 3550 AMD Radeon RX480 4GB (Radeon Software 17.5.2) Windows 10 64bit **Blender Version** Broken: 2.78.5 3bf69b2, 2.78c official **Short description of error** When using the Curve modifier on a mesh, the mesh will only deform along the base geometry of the target curve and will not take into account whether the curve is being deformed with some modifier like Shrink Wrap. **Exact steps for others to reproduce the error** I have attached a .blend file where this issue can be quickly observed. [shrink-wrap-bug.blend](https://archive.blender.org/developer/F607463/shrink-wrap-bug.blend) 1) Toggle the visibility of the Shrinkwrap modifier of the target curve on and off. 2) The mesh deformed with the Curve modifier will not change.
Author

Changed status to: 'Open'

Changed status to: 'Open'
Author

Added subscriber: @s12a

Added subscriber: @s12a

Added subscriber: @sindra1961

Added subscriber: @sindra1961

If you use project mode in Shrinkwrap modifier, I think that you have to appoint axis.

If you use project mode in Shrinkwrap modifier, I think that you have to appoint axis.
Author

The results are the same regardless of the Shrinkwrap modifier mode. The curve with the shrink wrap gets shrinkwrapped, but the objects that deforms along this curve doesn't follow its shrinkwrap deformation.

The results are the same regardless of the Shrinkwrap modifier mode. The curve with the shrink wrap gets shrinkwrapped, but the objects that deforms along this curve doesn't follow its shrinkwrap deformation.

Added subscriber: @bliblubli

Added subscriber: @bliblubli

I think it's more a design problem than a bug. It's one of the area in Blender that doesn't follow the philosophy of "don't think for the user". The depsgraph will decide in which order the modifiers should be applied and sometime fails at finding the right order, because in some case their are several possibilities, all valid and it's more a question of artistic decision.
The solution to it would be to have a way for the user to order modifier execution. The everything node system will solve it on the long term. In the meantime, it could be solved with a scene stack of modifiers instead of being limited to object stack.

I think it's more a design problem than a bug. It's one of the area in Blender that doesn't follow the philosophy of "don't think for the user". The depsgraph will decide in which order the modifiers should be applied and sometime fails at finding the right order, because in some case their are several possibilities, all valid and it's more a question of artistic decision. The solution to it would be to have a way for the user to order modifier execution. The everything node system will solve it on the long term. In the meantime, it could be solved with a scene stack of modifiers instead of being limited to object stack.
Author

From an end-user standpoint I would expect the object to curve along the visible (final/deformed) curve rather than its base geometry. If that was unwanted I could still duplicate the curve and remove the shrinkwrap modifier. With the current behavior I am prevented from choosing a possible option.

From an end-user standpoint I would expect the object to curve along the visible (final/deformed) curve rather than its base geometry. If that was unwanted I could still duplicate the curve and remove the shrinkwrap modifier. With the current behavior I am prevented from choosing a possible option.

Added subscriber: @Sergey

Added subscriber: @Sergey

Changed status from 'Open' to: 'Archived'

Changed status from 'Open' to: 'Archived'
Sergey Sharybin self-assigned this 2017-05-29 15:47:18 +02:00

This is not about depsgraph, it is about some internal conventions which depsgraph have nothing to do about.

Basically, curve can be deformed in two different ways: one of them is to deform control points (bezier point and handles in this case) and tessellated points. Depending on what is your intention you use one or other one.

Then, when curve is used as a target for such things as "Follow Path" constraint, curve deform and some other, the so-called "Path" of curve is used. The path is a spline which is calculated at a state of pre-tessellated curve. This is because it's not possible to calculate it reliably from post-tessellated curve.

In your case, the first ever modifier (shirkwrap) is applied on tessellated curve, which leaves Path used for curve deform unaffected by the modifier.

While it is confusing, this is just how things work and changing this is not really a subject of bug tracker.. Thanks for the report anyway!

This is not about depsgraph, it is about some internal conventions which depsgraph have nothing to do about. Basically, curve can be deformed in two different ways: one of them is to deform control points (bezier point and handles in this case) and tessellated points. Depending on what is your intention you use one or other one. Then, when curve is used as a target for such things as "Follow Path" constraint, curve deform and some other, the so-called "Path" of curve is used. The path is a spline which is calculated at a state of pre-tessellated curve. This is because it's not possible to calculate it reliably from post-tessellated curve. In your case, the first ever modifier (shirkwrap) is applied on tessellated curve, which leaves Path used for curve deform unaffected by the modifier. While it is confusing, this is just how things work and changing this is not really a subject of bug tracker.. Thanks for the report anyway!
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
4 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#51603
No description provided.