Mon, Jun 19
@LazyDodo (LazyDodo) done.
Can we then disable this test until the legacy despgraph is no longer the default?
I can confirm this bug. The root cause is that the Mesh Sequence Cache modifier adjusts the vertices of the mesh directly. You can see this when you view the mesh in Edit Mode; the mesh will be deformed, instead of in the rest position as expected by the Armature modifier.
I tested the export in Linux with 3.19 Kernel wich is recommented by the OS developer. Also tested with Kernel 4.0 and 4.4. The result is the same. I am working on 4.4.79 in general cause of hardware requirements.
So i tested alot at the weekend and i found out that the problem only occur with high amounts of polygones.
Since I don't have Houdini, it'll be hard to test this out. I can try and investigate with some other software, though (abcview).
Please attach a simple example file that shows this issue.
Turns out this does happen on Linux too, but only if you enable the legacy depsgraph. I tested only with WITH_LEGACY_DEPSGRAPH:BOOL=OFF.
@Sergey Sharybin (sergey) and I agree that it's not worth it fixing this test for the old depsgraph.
Sun, Jun 18
Fri, Jun 16
Please always attach files here, other places are not guaranteed to keep file around…
Thu, Jun 15
Sat, Jun 10
Fri, Jun 9
Sat, Jun 3
Unfortunately, v. 2.78.0-git.020bbbb-windows64 behaves the same.
Fri, Jun 2
As you can see in the 2.79 release logs, a lot of Alembic improvements have been made since 2.78c. Can you try with a recent daily build from https://builder.blender.org/download/?
Thu, Jun 1
Tue, May 30
May 24 2017
@Sergey Sharybin (sergey) this wasn't necessary -- I just had to remove a check here and add a check there and now it's all fine.
Sybren, i have tested it with 2.78c official and since there was another bug in that release i reported, it's unable to export whole animation of the abc file with vertex colors checked. Blender exports only two frames of animation in that case. But even then those two frames have no vertex color animation. That two frames export bug is now solved in the trunk.
Anyway, it's not a regression. It's a lack of feature, i believe.
May 23 2017
@Yegor (Yegor) can you test with 2.78c to see if this was ever supported? Then we know if it's a regression (i.e. a bug) or a new feature.
May 22 2017
@Sybren A. Stüvel (sybren), render pipeline will call the frame change post/pre callbacks (this is likely happening via the depsgraph update). So seems reasonable thing to do for alembic export as well?
At least with the current Buildbot builds Alembic export always crashes as soon as I use "Simple" or "Interpolated" children no matter what I set the "Display" amount to.
May 21 2017
The "object path" is not a filesystem path, so it isn't affected by OS related restrictions. This is something we should address at some point, even though in practice I have yet to see Alembic files with such long "object paths" in them.
May 20 2017
I agree such hardcoded limits are not helpful, just saying that this might not actually affect anyone in practice. Mainly it's a waste of memory usage.
it's an internal path inside an alembic file, we should not impose any OS related restrictions to that in the first place?
Doesn't belong in the bug tracker I think, so changed type. Not sure paths longer than 4096 are supported by any commonly used OS even.
May 18 2017
+1 on the motionblur! Also an option to scale the velocity would be nice, and maybe an option to choose the channelname that provides the velocity as it might be different depending on the app that creates the alembic. Thanks!
May 17 2017
@Sybren A. Stüvel (sybren), mind having a look here?
May 16 2017
Just tried the approach with the custom property on the mesh. It did not seem to work.
@Jacques Lucke (JacquesLucke) I didn't try this, but you could add a custom property to the mesh, and animate that. That way the mesh has animation data; this might be enough for the exporter to consider it "animated" and export it on every frame. Can you give that a try and let us know if it works?