Blender stales when changing the ghosting range #49527

New Issue

Aaron Carlisle · 2016-10-01T23:36:50+02:00

Aaron Carlisle commented

2016-10-01 23:36:50 +02:00

System Information
Windows 10
Intel HD 4600

Blender Version
Broken: dd0de53
Worked: (optional)

Short description of error
Blender stales when changing the ghosting range.
I also tried testing the bug with a debug build however, it did not give any information on the source of the bug.

Exact steps for others to reproduce the error

Add an armature
Animate it (2 frames)
Ghost --> and entering a range value Range value will cause the Freeze

**System Information** Windows 10 Intel HD 4600 **Blender Version** Broken: dd0de53 Worked: (optional) **Short description of error** Blender stales when changing the ghosting range. I also tried testing the bug with a debug build however, it did not give any information on the source of the bug. **Exact steps for others to reproduce the error** - Add an armature - Animate it (2 frames) - Ghost --> and entering a range value Range value will cause the Freeze

Aaron Carlisle commented

2016-10-01 23:36:50 +02:00

Changed status to: 'Open'

Aaron Carlisle commented

2016-10-01 23:36:50 +02:00

Added subscriber: @Blendify

blender-admin commented

2016-10-01 23:36:50 +02:00

#50434 was marked as duplicate of this issue

Joshua Leung was assigned by Aaron Carlisle

2016-10-01 23:54:17 +02:00

Joshua Leung commented

2016-10-03 13:07:39 +02:00

Currently there isn't enough info to pinpoint what might be going wrong in this case. But, just to get the ball rolling, here are a number of candidates:

You're trying to show ghosts for too large a frame range. Depending on how heavy the rig/scene are, I don't recommend doing more than 10-20 in total
The rig you're using has a lot of bones (or a lot of those bones have custom shapes with high vertex counts, etc.)
Are there any dependency cycles in your rig? What about pydrivers? New or old depsgraph?
Does any part of your rig depend on "geometry" (e.g. spline ik/followpath/shrinkwrap constraints)?

Currently there isn't enough info to pinpoint what might be going wrong in this case. But, just to get the ball rolling, here are a number of candidates: 1) You're trying to show ghosts for too large a frame range. Depending on how heavy the rig/scene are, I don't recommend doing more than 10-20 in total 2) The rig you're using has a lot of bones (or a lot of those bones have custom shapes with high vertex counts, etc.) 3) Are there any dependency cycles in your rig? What about pydrivers? New or old depsgraph? 4) Does any part of your rig depend on "geometry" (e.g. spline ik/followpath/shrinkwrap constraints)?

Julian Eisel commented

2016-10-03 13:11:44 +02:00

Added subscriber: @JulianEisel

Julian Eisel commented

2016-10-03 13:11:44 +02:00

I can actually recreate easily with old DepsGraph, single bone and 2 keyframes. Agree the report could contain some more precise info (and a .blend) though.

Joshua Leung commented

2016-10-03 13:12:04 +02:00

Oh, and two other points:

I thought it might just be worth noting that the thing with armature ghosting is it currently works by evaluating the armature's pose for all bones for each ghosting step shown, and once more for good measure (to ensure that everything is restored back to the original state). There's a reason why we don't support ghosting for objects currently (e.g. imagine the lag on a deformed mesh, not to mention the complexity of updating all the objects within the old depsgraph framework!)
Did this happen in previous releases? Or is this something that only happened in the past few months?

Oh, and two other points: 1) I thought it might just be worth noting that the thing with armature ghosting is it currently works by evaluating the armature's pose for all bones for each ghosting step shown, and once more for good measure (to ensure that everything is restored back to the original state). There's a reason why we don't support ghosting for objects currently (e.g. imagine the lag on a deformed mesh, not to mention the complexity of updating all the objects within the old depsgraph framework!) 2) Did this happen in previous releases? Or is this something that only happened in the past few months?

Carlos commented

2017-01-12 22:06:57 +01:00

Added subscriber: @bizdizzle

Carlos commented

2017-01-12 22:06:57 +01:00

I've noticed this issue also.

Start with default scene and delete cube
Create Single Bone Armature
In armature settings, set ghosting to "In Range"
Set End to 50
Go into pose mode
Blender freezes at this point for me

I've tested this with the old and new depsgraph. I'm running windows 7 sp1 64 bit on an HP laptop with an i5 cpu and 8 gigs of ram.

I've noticed this issue also. - Start with default scene and delete cube - Create Single Bone Armature - In armature settings, set ghosting to "In Range" - Set End to 50 - Go into pose mode - Blender freezes at this point for me I've tested this with the old and new depsgraph. I'm running windows 7 sp1 64 bit on an HP laptop with an i5 cpu and 8 gigs of ram.

Aaron Carlisle commented

2017-01-15 19:09:13 +01:00

Added subscriber: @piotr-14

Steffen Mortensen commented

2017-01-21 12:32:20 +01:00

Added subscriber: @stifan

Steffen Mortensen commented

2017-01-21 12:32:21 +01:00

Had the same problem, and really couldn't make sense of the error. But i found the solution!

The problem is when the "Step" part of the in range is set to 0, then i guess it increments by 0 and goes into forever loop mode :)

Had the same problem, and really couldn't make sense of the error. But i found the solution! The problem is when the "Step" part of the in range is set to 0, then i guess it increments by 0 and goes into forever loop mode :)

blender-admin commented

2017-01-21 14:54:35 +01:00

This issue was referenced by d2382f782e

This issue was referenced by d2382f782e74f9e7b4df49ffc8e40dabb0b8af50

Joshua Leung commented

2017-01-21 14:57:18 +01:00

Changed status from 'Open' to: 'Resolved'

Joshua Leung closed this issue

2017-01-21 14:57:18 +01:00

Joshua Leung commented

2017-01-21 14:58:13 +01:00

@stifan: Thanks for identifying the problem! Fixes committed to master now :)