Page MenuHome

With Cycles, Freestyle lines render one frame ahead for object with driver
Closed, ArchivedPublic


With Cycles, if an animated object has a property that is driven, Freestyle lines are drawn based on the value of that property at the next frame.

In the attached example, the z rotation of the cube is driven by its x location. At each frame, Freestyle renders the lines based on the correct location for the cube, but based on the rotation at the next frame.

Example .blend:

Output from example .blend:

Generic reproducibility steps:

  1. Switch to Cycles Render.
  2. Enable Freestyle.
  3. Add driver to object that modifies its location or rotation in time.
  4. Render Animation.

This does not happen:

  • When rendering stills.
  • When Blender Render is used.
  • For properties that are not driven.


  • Blender: 2.78a
  • OS: Ubuntu 16.04
  • CPU: Intel Core i7-2630QM
  • RAM: 12GB
  • GFX: NVIDIA GeForce GTX 560M, 1.5GB
  • Graphics driver version: 367.57
  • System info file:



Event Timeline

Thanks Bastien for the triage, and I confirmed the issue on my side. I will look into it as soon as time permits.

Sergey Sharybin (sergey) closed this task as Archived.
Sergey Sharybin (sergey) claimed this task.

This is a dependency graph issue.

What happens here is you're using own location in the driver source, but the way you're using it assume you're trying to access final object transform (after all animation, parenting and constraints applied). This will work fine to driver some, say, modifier property but using that source for rotation component causes chicken-and-egg situation: rotation driver wants final object transform to be already evaluated, but rotation is required to calculate that transformation. You can see that if you hit shift-right arrow twice.

What you can do for now is to change your x variable to use "Single Property", and use location[0] as the path. here's a file:

Surely would be nice if such situation was handled correctly, but this is not currently considered a bug. However, noted this issue here

So thanks for the report, but archiving it for now.