Testfile [including image sequence]:
Tue, Jun 18
Testfile [including image sequence]:
This is reproducable with any image sequence mapped to ParticleSettings influence [no update on framechange there]
Thu, Jun 13
Wed, Jun 5
Wed, May 29
As far as I can tell this is the subdivision surface modifier just being very slow. In the viewport it's disabled due to simplify settings.
May 24 2019
May 23 2019
May 10 2019
Sorry for reopening however I would like this to be reconsidered. The active camera 'should' have special privileges which evaluate it regardless of whether it is visible or not, as it causes much artist confusion to when the camera 'should' be animated but is not.
Not a bug. You have disabled evaluation of the objects in that collection. So this is the correct behavior.
May 9 2019
Mar 20 2019
Mar 14 2019
We fixed a similar bug at some point after this report, appears to be fixed now.
Mar 13 2019
Needed to apply manually, and forgot to mention the revision in the comment.
Committed as rB76437b903de.
The only alternative that comes to mind would be to improve the solve_cycles function so that the resulting graphs are ensured to perform orderly cleanup. But adding extra relations seems like a more clean/maintainable solution.
I don't have a better local solution.
For that issue, see T62094: Unable to insert a hide_viewport keyframe via the UI.
@Brecht Van Lommel (brecht), do you feel strong here? Can't think of a better solution than to introduce more relations.
@Dalai Felinto (dfelinto), this change has nothing to do with solving cycles, it just makes blender to not crash when there is a cycle.
From reading the patch it seems fine to me.
Likewise just tried object visibility keyframing in latest build as of today (Mac) and still no option to keyframe or add drivers to object viewport visibility (eye icon in outliner). This is quite a crucial feature for me to start migrating my main project to 2.80
'OBArmature.Mario.POSE_IK_SOLVER()' depends on 'OBArmature.Mario.Spine.Bendy.BONE_READY()' through 'IK Chain Parent' 'OBArmature.Mario.Spine.Bendy.BONE_READY()' depends on 'OBArmature.Mario.Spine.Bendy.BONE_CONSTRAINTS()' through 'Constraints -> Ready' 'OBArmature.Mario.Spine.Bendy.BONE_CONSTRAINTS()' depends on 'OBArmature.Mario.Spine.Tail.BONE_READY()' through 'Damped Track' 'OBArmature.Mario.Spine.Tail.BONE_READY()' depends on 'OBArmature.Mario.Spine.Tail.BONE_CONSTRAINTS()' through 'Constraints -> Ready' 'OBArmature.Mario.Spine.Tail.BONE_CONSTRAINTS()' depends on 'OBArmature.Mario.Spine.Tail.BONE_POSE_PARENT()' through 'Pose -> Constraints Stack' 'OBArmature.Mario.Spine.Tail.BONE_POSE_PARENT()' depends on 'OBArmature.Mario.Spine.Base.BONE_DONE()' through 'Parent Bone -> Child Bone' 'OBArmature.Mario.Spine.Base.BONE_DONE()' depends on 'OBArmature.Mario.POSE_IK_SOLVER()' through 'IK Chain Result'
Mar 7 2019
More than a week without reply or activity. Due to the policy of the tracker archiving for until required info/data are provided.
Mar 6 2019
Hello, I am facing the same problem.
Can someone give an example or a step by step guide of how to key visibility on instanced collection or object? (with the latest build of blender 2.80)
Mar 4 2019
This seems resolved for me.
Mar 2 2019
Currently only objects visibility is animated.
Mar 1 2019
@Sergey Sharybin (sergey) : this will make me the happiest man :)
I'll test it in the next build.
Thanks a lot.
@Sylvain (Micool), please create a new bug report about that.
Feb 28 2019
Committed quite some fixes in various related ares and this report is supposed to be fixed now! The minimal revision required is rB846d265a06e.
Feb 25 2019
Feb 18 2019
Feb 14 2019
Weird. Was looking for quite some time =\ Thanks!
There will be more optimizations.
@Sergey Sharybin (sergey): file was there in the report (made this more visible now...)
Please always attach .blend file which demonstrates the issue.
At the moment my demo scene with some modifiers is at 5 fps in version 2.8.
In v2.79 its faster and runs at about 8 fps.
Feb 13 2019
Thank you for your effort. It works now.
@Sergey Sharybin (sergey), can you review this?
This appears to be solved in the latest builds.
@Campbell Barton (campbellbarton) : is this OK to stay on your desk?
AddressSanitizer: heap-use-after-free P911
Can reproduce here
Also I don't know if I should write here or create another task, but I can't even insert keyframe on viewport visibility, while I can insert one for render visibility. It will show an error as shown in the screenshot:
If some people with earlier build can insert keyframe on viewport visibility, even if they don't update correctly, is this one more regression from earlier build or intended to prevent crash? I've tried this on few builds that I still have, with the earliest build on 552b2287db86 (01/02/2019) and the latest build blender-2.80-d3870471edd7-win64 (12/02/2019).
I've just discovered this problem. I don't really understand the script workaround, but I know it's something with the internal code not updating. Because if I move a keyframe of Disable Render channel from the object, it will be updated, but then stays like the last render until I move any keyframe of Disable Render channel again.
Feb 12 2019
There were few things wrong in dependency graph and instancing code. Should be fixed now. Thanks for the report, closing.
BLI_assert failed: /blender/blenkernel/intern/DerivedMesh.c:2181, mesh_get_eval_final(), at 'DEG_debug_is_evaluating(depsgraph) == 0'
Feb 11 2019
we do have valid final and deformed (aka cage) evaluated meshes in BMEditMesh, nowadays. So fix is actually quite simple. ;)
doh! thats a facepalm on my side... thx @Bastien Montagne (mont29)
BKE_modifier_get_evaluated_mesh_from_evaluated_object() is doing plain rubbish in EditMode case… That was probably true at the time it was written, but we do have valid final and deformed (aka cage) evaluated meshes in BMEditMesh, nowadays. So fix is actually quite simple. ;)
I've the same problem.
I believe that being able to control visibility on viewport is very important.
This was indeed working fine in 2.79.
In 2.8 it updates fine if you go back to objectmode.
Once you enter editmode on the plane, I am getting this here:
ERROR (bke.modifier): /blender/source/blender/blenkernel/intern/modifier.c:385 modifier_setError: Cage verts changed from 162 to 81
So looks like BKE_modifier_get_evaluated_mesh_from_evaluated_object doesnt really give us fully evaluated mesh (at least not for objects with generative modifiers in editmode)?
Feb 9 2019
Feb 5 2019
Feb 1 2019
Jan 31 2019
Jan 30 2019
@Sergey Sharybin (sergey): mind sharing your wisdom?
Jan 29 2019
I allready had this problem in a few projects.
Thank you @Fletcher Graham (fletchgraham) for your suggestion on forcing blender to update through python.
To get around the issues with keyframing visibility in 2.80, I used a script instead.
Jan 28 2019
Jan 25 2019
Can no longer reproduce the issue. Considering it solved by all the recent changes.
If the issue is still happening make a new report with updates file and steps to reproduce the issue.
Jan 24 2019
I agree, we need better docs for this.
Brecht, your suggestion works. Thanks for the input!
Well that's good that it's not a bug. This should be mentioned in the Python API section of the release notes. For addon devs like me there is no mention that you need to use the engine to set the frame now instead of the scene. Then I waste you guys' time posting reports on bugs that aren't bugs.
For rendering, use engine.frame_set() instead of scene.frame_set() to change the frame.
Here's a stripped down version of the render plugin. Instead of exporting items it just prints matrix_world
Jan 23 2019
Thanks Philipp. I’ll get a scene and mock-up to you later today
Just to make this a little simpler for everyone looking at this:
Jan 22 2019
note: to get it to crash easier, lower the number of particles to 100 in the file provided with this report.
Jan 21 2019
This approach includes additional relations to avoid the unorderly cleanup rather than having unkillable relations. I had to add extra relations in bones as well as in constraints.
Jan 20 2019
Yeah I was not really sure this was the right approach. I'll add relations bone-cleanup as you suggest. I guess tweaking the cycles solver wouldn't be a solution in the long term anyway as long as we allow arbitrary armature graphs.
This is effectively marking almost all of the relations as non-killable. This might be ok if those are done within a single bone channel only, but this definitely shouldn't be applied to inter-bone dependencies (i.e. from parent to solver). That will never be a reliable solution, and will fail sooner or later.
Jan 19 2019
Jan 15 2019
Seems to work as expected. Can you reproduce the bug in a newer build?