Page MenuHome

Position in Render does not match viewport. (Driver properties)
Closed, DuplicatePublic

Description

System Information
Operating system:Windows7
Graphics card: gtx1050ti

Blender Version
Bug:2.80 (release)

Short description of error
Information about the position of objects is obtained in a different way for the viewport and render when working with drivers

The position of the dummy in the viewport is taken from its past state. When rendering from the frame on which the viewport was standing.

Exact steps for others to reproduce the error
1.create a cube
2.create a dummy (or another cube)

  1. Set for dummy driver in the X position
  2. Script expression: (bX + aX) /2

Variables:
[bX is the position of the dummy on the x axis]
[aX is the position of the cube on the x axis]

  1. create an animation on x axis for target cube
  2. play in vievport
  3. play in render

p.s. Rendered animation https://youtu.be/1HdPOXR1qCs (sound driver's work's right but render isn't) planks on sides must indicate acceleration (in vievport its right) indicators on front sides must indicate drift.
p.p.s I offer 2 solutions: 1. take the position of objects for drivers from their position in the last frame. 2. add the parameters "speed"(local and world space) and "acceleration"(same) to the properties of object's in drivers tab.

Event Timeline

Tinamagomed (Chalouek) updated the task description. (Show Details)
Tinamagomed (Chalouek) renamed this task from Position in render and veivport bug. (Driver properties) to Position in Render does not match viewport. (Driver properties).Aug 24 2019, 1:24 AM
Philipp Oeser (lichtwerk) lowered the priority of this task from 90 to 30.Sep 23 2019, 12:28 PM

Since it takes time for each developer the recreate your setup, please provide your .blend file here, so we can reproduce.
Thx in advance.

Brecht Van Lommel (brecht) raised the priority of this task from 30 to 90.Oct 7 2019, 11:34 PM

Hi there (and sorry for the massive delay in the reply)!

This issue looks like a dependency cycle.
The drivers variables are set up as Transform Channel types (and thus the dependency cycles are not reported, see below)
If I set the variables up as Single Property types (no functional change), you get the dependency cycles reported:

Dependency cycle detected:
  OBV2/Parameters Component/DRIVER(location) depends on
  OBV2/Transform Component/TRANSFORM_FINAL() via 'RNA Target -> Driver'
  OBV2/Transform Component/TRANSFORM_SIMULATION_INIT() via 'Simulation -> Final Transform'
  OBV2/Transform Component/TRANSFORM_EVAL() via 'Transform Eval -> Simulation Init'
  OBV2/Transform Component/TRANSFORM_LOCAL() via 'Eval'
  OBV2/Transform Component/TRANSFORM_INIT() via 'Transform Init'
  OBV2/Parameters Component/DRIVER(location) via 'Driver -> Driven Property'
Dependency cycle detected:
  OBV1/Parameters Component/DRIVER(location) depends on
  OBV1/Transform Component/TRANSFORM_FINAL() via 'RNA Target -> Driver'
  OBV1/Transform Component/TRANSFORM_SIMULATION_INIT() via 'Simulation -> Final Transform'
  OBV1/Transform Component/TRANSFORM_EVAL() via 'Transform Eval -> Simulation Init'
  OBV1/Transform Component/TRANSFORM_LOCAL() via 'Eval'
  OBV1/Transform Component/TRANSFORM_INIT() via 'Transform Init'
  OBV1/Parameters Component/DRIVER(location) via 'Driver -> Driven Property'
Detected 2 dependency cycles

So having dependency cycles is not considered a bug.

See T72899: Animation driver takes data from previous frame on why these are not reported for Transform Channel driver vars:

The dependency cycle is not reported on purpose actually: while animated property can not currently control driver, rigs were using a lot of non-animated properties properties as a driver variable. For example, using non-animated X-value of a transform is fine to drive Y of scale.
This behavior is used a lot by rigs here and in other studios, and printing dependency cycle would spam terminal to a degree that you wouldn't be able to find real issues.
Think real solution would be to support such setups, but this is already reported as T64793.

In the end, this looks like a duplicate of T64793: Bone driver leading to cyclic dependency (used to work in 2.79) as well...