driver late update after Alt+G for leading object #88689

New Issue

Closed

opened 2021-05-30 19:50:52 +02:00 by Vyacheslav Kobozev · 6 comments

Vyacheslav Kobozev commented

2021-05-30 19:50:52 +02:00

System Information
Operating system: Windows-8.1-6.3.9600-SP0 64 Bits
Graphics card: NVIDIA GeForce GTX 660 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 466.47

Blender Version
Broken: 2.83.9 and later ( 2.93.0 Beta, branch: master, commit date: 2021-05-28 16:16, hash: c369382977)

Short description of error
when I press Alt-G drivered value updates, but actual scale don`t
Here the file and demo

2021-05-30_20-44-24.mp4

**System Information** Operating system: Windows-8.1-6.3.9600-SP0 64 Bits Graphics card: NVIDIA GeForce GTX 660 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 466.47 **Blender Version** Broken: 2.83.9 and later ( 2.93.0 Beta, branch: master, commit date: 2021-05-28 16:16, hash: `c369382977`) **Short description of error** when I press Alt-G drivered value updates, but actual scale don`t Here the file and demo [drv late.blend](https://archive.blender.org/developer/F10149442/drv_late.blend) [2021-05-30_20-44-24.mp4](https://archive.blender.org/developer/F10149441/2021-05-30_20-44-24.mp4)

Vyacheslav Kobozev commented

2021-05-30 19:50:53 +02:00

Author

Added subscriber: @Vyach

Added subscriber: @Vyach

Philipp Oeser commented

2021-05-31 11:34:35 +02:00

Member

Added subscriber: @lichtwerk

Added subscriber: @lichtwerk

Philipp Oeser commented

2021-05-31 11:34:35 +02:00

Member

Changed status from 'Needs Triage' to: 'Confirmed'

Changed status from 'Needs Triage' to: 'Confirmed'

Philipp Oeser commented

2021-05-31 11:34:35 +02:00

Member

Can confirm.

Right now, one driver is dependent on the height and sets the X-Scale, the second driver takes the computed X-Scale and sets the Y-Scale.
You can get it to update one step futher if you make both X and Y scale take the height as input for the scripted expression.

One dimension is then updated properly in the viewport and both values are updated properly in the sidebar UI.
Still, this is unexpected behavior, cancelling a transform on the other hand does a better job here.

Can confirm. Right now, one driver is dependent on the height and sets the X-Scale, the second driver takes the computed X-Scale and sets the Y-Scale. You can get it to update one step futher if you make both X and Y scale take the height as input for the scripted expression. One dimension is then updated properly in the viewport and both values are updated properly in the sidebar UI. Still, this is unexpected behavior, cancelling a transform on the other hand does a better job here.

Vyacheslav Kobozev commented

2021-05-31 12:15:35 +02:00

Author

@lichtwerk
Yep, I had made this approach too. With same result.
And it still requires double {key Alt+G} press. So something prevents proper chain reaction.

@lichtwerk Yep, I had made this approach too. With same result. And it still requires double {key Alt+G} press. So something prevents proper chain reaction.

Philipp Oeser removed the

Animation & Rigging

label 2023-02-09 14:35:35 +01:00

Nathan Vegdahl commented

2023-06-09 12:09:40 +02:00

Member

Unfortunately, this isn't a bug per se, but rather a limitation of Blender's current dependency graph:

Blender sees this as a dependency cycle. Of course, practically there is no dependency cycle, but the dependency graph doesn't have a granular enough view of transform properties to distinguish e.g. the different scale channels as unique entities.

If you start Blender from the command line and open the test file, you immediately get the following output:

Dependency cycle detected:
  OBPlane.001/DRIVER(scale) depends on
  OBPlane.001/TRANSFORM_FINAL() via 'RNA Target -> Driver'
  OBPlane.001/TRANSFORM_SIMULATION_INIT() via 'Simulation -> Final Transform'
  OBPlane.001/TRANSFORM_EVAL() via 'Transform Eval -> Simulation Init'
  OBPlane.001/TRANSFORM_LOCAL() via 'Eval'
  OBPlane.001/TRANSFORM_INIT() via 'Transform Init'
  OBPlane.001/DRIVER(scale) via 'Driver -> Driven Property'
Dependency cycle detected:
  OBPlane.001/TRANSFORM_INIT() depends on
  OBPlane.001/DRIVER(scale) via 'Driver -> Driven Property'
  OBPlane.001/TRANSFORM_FINAL() via 'RNA Target -> Driver'
  OBPlane.001/TRANSFORM_SIMULATION_INIT() via 'Simulation -> Final Transform'
  OBPlane.001/TRANSFORM_EVAL() via 'Transform Eval -> Simulation Init'
  OBPlane.001/TRANSFORM_LOCAL() via 'Eval'
  OBPlane.001/TRANSFORM_INIT() via 'Transform Init'
Detected 2 dependency cycles

Additionally, the delay is actually happening all the time. When dragging the controller interactively, the update rate makes it not obvious. But if you animate the controller moving significantly over just a couple of frames, then frame stepping also reveals the same delay. This is classic dependency cycle behavior.

So although this is certainly undesirable behavior, it's unfortunately not a bug. Just a (known) limitation of Blender at the moment.

Unfortunately, this isn't a bug per se, but rather a limitation of Blender's current dependency graph: Blender sees this as a dependency cycle. Of course, *practically* there is no dependency cycle, but the dependency graph doesn't have a granular enough view of transform properties to distinguish e.g. the different scale channels as unique entities. If you start Blender from the command line and open the test file, you immediately get the following output: ``` Dependency cycle detected: OBPlane.001/DRIVER(scale) depends on OBPlane.001/TRANSFORM_FINAL() via 'RNA Target -> Driver' OBPlane.001/TRANSFORM_SIMULATION_INIT() via 'Simulation -> Final Transform' OBPlane.001/TRANSFORM_EVAL() via 'Transform Eval -> Simulation Init' OBPlane.001/TRANSFORM_LOCAL() via 'Eval' OBPlane.001/TRANSFORM_INIT() via 'Transform Init' OBPlane.001/DRIVER(scale) via 'Driver -> Driven Property' Dependency cycle detected: OBPlane.001/TRANSFORM_INIT() depends on OBPlane.001/DRIVER(scale) via 'Driver -> Driven Property' OBPlane.001/TRANSFORM_FINAL() via 'RNA Target -> Driver' OBPlane.001/TRANSFORM_SIMULATION_INIT() via 'Simulation -> Final Transform' OBPlane.001/TRANSFORM_EVAL() via 'Transform Eval -> Simulation Init' OBPlane.001/TRANSFORM_LOCAL() via 'Eval' OBPlane.001/TRANSFORM_INIT() via 'Transform Init' Detected 2 dependency cycles ``` Additionally, the delay is actually happening all the time. When dragging the controller interactively, the update rate makes it not obvious. But if you animate the controller moving significantly over just a couple of frames, then frame stepping also reveals the same delay. This is classic dependency cycle behavior. So although this is certainly undesirable behavior, it's unfortunately not a bug. Just a (known) limitation of Blender at the moment.

Nathan Vegdahl closed this issue

2023-06-09 12:09:42 +02:00

Blender Bot added

and removed

labels 2023-06-09 12:09:44 +02:00

Nathan Vegdahl added

and removed

labels 2023-06-13 10:15:12 +02:00

Sign in to join this conversation.

No Label

Animation & Rigging

Asset Browser Project Overview

Automated Testing

Blender Asset Bundle

Dependency Graph

Development Management

EEVEE & Viewport

Images & Movies

Motion Tracking

Nodes & Physics

Pipeline, Assets & IO

Platforms, Builds & Tests

Render & Cycles

Render Pipeline

Sculpt, Paint & Texture

Video Sequencer

Virtual Reality

Blender 2.8 Project

Milestone 1: Basic, Local Asset Browser

Good First Issue

Animation & Rigging

Development Management

EEVEE & Viewport

Nodes & Physics

Pipeline, Assets & IO

Platforms, Builds & Tests

Render & Cycles

Sculpt, Paint & Texture

Needs Info from Developers

Needs Information from User

No Milestone

No project

No Assignees

3 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#88689

No description provided.