Fri, Oct 4
Just wanted to chime in as a user who animates audio all the time.
Thu, Oct 3
As I wrote in T59540#588156 doing a callback for every sound sample is way too slow. We could consider it for every buffer if it is fast enough and it is possible. The issue here is that the depsgraph would need to provide the functionality to get the value of a single property for a specific time. I'm not sure if it can easily do that?
Thanks for fix.
The animation cache stuff may explain T69167: VSE - "Render Audio" exports only one audio strip in some cases. I will look into this as well. I've got quite a few audio related bugs in tracker, so this may have to be resolved in some way.
Let me revise what I wrote in my previous comment, my bad memory caused some wrong statements:
Tue, Oct 1
The interpolation is not a bug per se. The audio animation system is evaluated once for every read, so you basically get nearest neighbor interpolation for your buffer size. The buffer size can be adjusted during audio export as you correctly noticed. When rendering a video though, the audio system is called once per (image) frame so you get this issue here. I think having a general option in the render settings would be a good idea to mitigate the issue.
I haven't looked at audio handling in the VSE, so I wouldn't know by heart what could cause this.
Perhaps I never noticed this effect, because I render 60FPS and rarely use fade-ins, but I always thought, that property animation was done in audaspace internally. @Joerg Mueller (nexyon), do you know how this was/should be implemented?
Sun, Sep 29
I am testing this now, and I can reproduce this issue in 2.79 also.
I will have to ask more devs how/if this can be mitigated.
Fri, Sep 27
Wed, Sep 25
Thank you again. I've tested and Never is working now. It's very weird if I add a scene (via python) everything speeds up again, then somehow 'always' turns itself back on and it gets super slow again... well that's just FYI in case anyone has similar issue.
Mon, Sep 23
I think this could be a great feature for animation, too, if you have a part of a rig that depends on a simulation. The cloth in a character's clothing could simulate while the animator is moving things, and stop when there's no transform going on. This would only give an idea of what the position of the cloth will be when baked, but it would be useful since you'd catch a lot of mistakes before a lengthy baking process.
Hi @todd doehring (tcdabemis) : both Never and Fast seems to be working fine here.
EDIT: I may have made an error in last post. 'Never' seems to be working but not all the time. I can't figure it out, will keep testing.
I noticed that this task is now 'closed', but the original issue with 'never' is still not working and using 'fast' makes little difference.
Fri, Sep 20
This seems to be fixed in current master.
(Have not hunted down the exact commit, but there have been many changes in this area since...)
@Sergey Sharybin (sergey) is this a limitation of the cloth simulation?
Thu, Sep 19
Did this work in older versions of Blender? I'm not entirely sure which kinds of interactions the current cloth system supports.
@Philipp Oeser (lichtwerk), looks correct. Mind adding RNA_LatticePoint to the same exceptions and commit?
updated paste with vcol fix...
This seems to do it
Hi @Sergey Sharybin (sergey), thank you.
UVs appear fixed, but I’m not sure about the vertex colors. In the test file below, one vertex of the mesh labeled V-Cols is supposed to go from blue to white on playback.
The one labeled V-groups has one vertex shift to the right with a Displace modifier.
The lattice Points are also animated.
UVs and vertex colors should now be fixed.
But in order to fix the vertex groups case I need to have a demo file.
quick note: works as soon as you insert a "regular" keyframe on the mesh datablock [e.g. a keyframe on mesh.texspace_location or something totally unrelated as mesh.use_customdata_vertex_bevel]
Wed, Sep 18
Note the crasher on delete, undo is also fixed by D5755: Fix T68645: Hair Particle Edit - Particle Mirror crash when children are visible in the viewport
Tue, Sep 17
This needs bigger design changes to the dependency graph and physics, and while it would be good if we can, it is not a requirement to be fixed for 2.81.
Sep 13 2019
Sep 12 2019
Deferring deletion of the scene is not practical, the depsgraph references the original scene. Even if it didn't then having multiple copies of the scene would use too much memory.
I am not sure what is "deferred" here means exactly. But technically there are only two things which needs locked interface:
Sep 11 2019
What happens here is that you're accessing property from an original datablock, but it's actual value is only known at the evaluated version.
Sep 9 2019
Sep 6 2019
Anything new? Maybe I'm missing another similar bug report
@Sergey Sharybin (sergey) : I have added this to 2.81 milestone (since it was set to "High"), mind checking again?
@Sergey Sharybin (sergey) : I have added this to 2.81 milestone (since it was set to "High"), mind checking?