@Julian Eisel (Severin), I would be interested in reviving this, however I do not really have the time for it...

Please ignore the velocity and acceleration discussion, that was a brain fart from me. The explanation is rather simple actually: the velocity property gives us dP when we need dPdt (so the values make sense in the "point in time" in which we use them). We might still need a user setting to make sure dt is the correct value for the velocities, instead of relying on the FPS (although in practice they are the same).

In D2388#140104, @Sybren A. Stüvel (sybren) wrote:

I don't understand some of the design in the patch.

• Why is there a change in the Scene RNA required? The fps and fps_base properties are already exposed in RNA, and having two ways to reach the same properties seems unnecessary.

Looks good to me, appart from some minor style issue (no need for the protected keyword as it is a final class in the hierarchy). @Sybren A. Stüvel (sybren) do you have any objections?

This was fixed in rB9a88bd55903a5c7df0365007bef8dd182f6eb481.

This was fixed in rB9a88bd55903a5c7df0365007bef8dd182f6eb481.

I just found out about this task/idea after trying to update D2324. One thing to note about D2324 (and any other potential system) is that the properties are read from a CacheFile whose evaluation is inside the dependency graph so we have to be able to set a relationship from the object (or ID) to the CacheFile. Now, D2324 does not work anymore for this very reason: there does not seem to be a way yet to set this dependency through the F-Curve Modifier's API (unless I missed something), therefore we do not have a valid CacheFile handle to read the data from because the object might be evaluated before the one for the CacheFile, and it is simply crashing.

Here is another test with a file containing 3 different case studies (a fractured objet, a liquid sim, and a rotating object), all of which have custom velocities:

You have to apply the patch and compile Blender to test the feature, it is not in the daily builds. Also your file does not have velocity information (the array size is 0). So without the patch and without custom velocities, Cycles is just using an interpolation between the previous, current, and next frames.

For those who haven't noticed, I updated and fixed the patch D2388, please try it if you can!

This patch is nearing completion, with one remaining property to be added. Here are some examples:

• Attempt to update the code.
• Finally make motion blur work!

@Sybren A. Stüvel (sybren), sorry for the late response but I am not actively working on anything Blender related at the moment.

I am not working on this anymore, although I could resume work. This approach was suggested to me by Campbell as a general way to import custom keyframes from alembic archives. The patch was uploaded for review a few years ago: D2324.

@murat (muratz), please open a new bug report (with a problematic blend file) as your issue is unlikely to be this very same issue.

@Sybren A. Stüvel (sybren), could you look into this? I have neither the Blender sources nor my Alembic files on my computer at the moment. Overall, apart from some style issues it looks good to me.

Hey Campbell, this commit has created memory leaks in sculpt mode and texture paint mode. UndoImageTile and SculptUndoNode are not freed even when undoing.

This should be fixed now (rBe5327afcb73f), thanks for the report!

@YAFU (YAFU), this is more than ready for testing, actually it is ready to be commited to master. For the artifacts, you should try increasing the Light Paths > Transparency Max setting, I set it to 16 in my tests files.

• Handle comments from review.

• Use a byte grid for the index_map.
• Add padding when adding nodes.
• Cleanup.

Thanks for the fixes!

Update patch as checkpoint.

The missing quads issue was due to the mesh's shader array not being updated, so clearing it before creating the new mesh fixes the issue. (I guess they had an invalid shader or a transparent one?)

Update patch as a checkpoint.

I rewrote the algorithm to make use of 8x8x8 cubes since the marching cube idea with a cube size greater than one does not really work; for it to work we would need to interpolate all the voxels around the corners of the cube within a distance equivalent to the size of the cube; which is not efficient.

I cannot speak for FBX files, but in the case of Alembic files this is not a bug, but a limitation of the current implementation (however I used to work on a patch for supporting such features D2324).

In D3038#71910, @Brecht Van Lommel (brecht) wrote:

I wasn't thinking about the marching cubes algorithm actually, but rather axis aligned quads between empty and non-empty voxels. And then you'd make that smarter by considering e.g. 8x8x8 cubes instead, and merging neighbouring quads and deduplicating vertices to reduce memory usage. For OpenVDB files that would then also naturally work by building around leaf nodes, without having to read the actual voxel data.

@Philipp Oeser (lichtwerk) if you have trouble building OpenVDB, I can quickly make a patch for it.

@Juan Gea (juang3d) no one is working on that currently, otherwise there would be some activity here.

• Merge branch 'master' into arcpatch-D2118
• Rename parameters to id_arg.

This gives me a 2.2x speedup on this file :

• Merge branch 'master' into arcpatch-D2118
• Rename UpdateModifierCb -> FModifierUpdateData.

I don't recall whether or not the paths are written to the blender file upon saving, if yes this might need a bit of rework. At the moment I don't have a build environment for Blender set up, so I can't try the patch, or scrutinize it more deeply. I made a few comments though.

Closing this ticket since it appears the bug is solved.

To define whether or not a mesh is animated, the exporter only checks for the presence of modifiers and shapekeys. Since your script is using a scene handler and recreating the mesh every frame, it is not possible to know that this particular object is animated (unless there is some hidden black magic I am not aware of).

I have one minor comment, otherwise LGTM.

The overall approach seems fine, though this makes me even more think that a proper hierarchical data-structure should be developed to handle conversions between Alembic's tree and Blender's linked list model. I just added some comments about the code style for now. We should really work on trying to have consistent code, especially consistent with Blender's code style guidelines.

I guess the solution to have the logger work in utility functions would be to have a global variable, a singleton, for the logger. Although, I would still try to keep a separation between the user level error messaging and the developer level one.

This is not a bug since when toggling between Domain, Flow, Collision and None, resets the modifier for the active object in order to change its type for the simulation, that is the domain object becomes a flow object in your example (developer note: the settings for each category are stored in different structs).

• Merge branch 'master' into abc_logger
• Tackle review points: clarify comments and messages.

• Merge branch 'master' into abc_logger
• Document SimpleLogger class.
• Better way to tell whether or not the stream is empty.
• Correct documentation.
• Revert some changes, avoid using 'this' qualifier

Why the change from GHash to std::map? Gotta ask sergey but IIRC GHash is faster (profiling done for the dependency graph). Also I'd rather use BLI than stdlib whenever possible (less generated code).

I didn't have time to test this patch yet. @Sybren A. Stüvel (sybren), did you test it with some of the files I sent you? Technically all of the files should import fine.

In my opinion, a more proper fix would have been to explicitly include <cstdio>, which apparently seems to be indirectly included on some platform.

@Sybren A. Stüvel (sybren) just some notes if you wish to tackle this on a rainy day before I can:

Thanks for the patch! I will apply it in a minute.

Vertex colors are a mesh property in Blender, so it is not possible to import/have them on curves at the moment. Making use of polylines (or edges in Blender terms) would be possible, but then things like rendering in Cycles might not be possible or very limited. The fact that Houdini polylines/polycurves are imported as curves in Blender is because they are written as being curve objects in the Alembic archives.

I committed your change (rBa928a9c1e199923090a6ea070332fb8003646590), thanks for the patch!

The issue most likely comes from the confusing logic that is used to convert data between Blender and Alembic, especially Alembic Y-up matrices to Blender Z-up ones. In the process, to create the Blender matrices, we multiply the matrices of the Alembic object with the one from its parent recursively, so maybe in this case the object matrix is somehow multiplied twice. The relevant function is in abc_util.cc.

@Rod Tebisx (rod.vfx.td) for the motion blur case, are you referring to meshes with varying number of vertices (like fluids) or any kind of meshes? For the first case this is a known to-do with a patch in the works (D2388).

I guess we can close this since the issue appears to be resolved.

Although I'll try look into this shortly, I'm going to close this ticket so as to not have too many open tasks cluttering the bug tracker. I added a note about it in my personal to-do list anyway. (Also: not a bug :) )

No response in more than a week --> archiving.

No response in more than a week --> archiving.

No response in more than a week --> archiving.

No response in more than a week --> archiving.

No answer in more than a week --> archiving.

No answer in more than a week --> archiving.

There is no bug here, if you tick the Override Frame check box, it will use the provided frame number from the Frame field to lookup the cache. If you want to overwrite the animation over time you need to set some key frames on the Frame field.