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.

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

Sounds like more or less the same issue as in T49114. In any case fixing this without proper knowledge of how other software expects curve data to be written will require a bit of trial and error, so setting priority to Low.

Should be fixed now, thanks for the report!

Thanks for the report but this should be fixed already (by rB534f11f71ee71b87a17ceddf56da0bcfa2cab352). Please download a recent build and see if it works for you.

@Bastien Montagne (mont29), since Alembic can store hundreds of objects and since BKE_mesh_validate can slow down the import process, it is not called directly, but there is an option in the import settings for it.

The issue probably comes from the fact that meshes are empty when importing Alembic objects and the data is generated by the modifier. For smooth normals to be applied through the modifier, it needs to be applied on the mesh before it gets fed through the modifier stack, but since meshes are empty before going through the modifiers, the smooth normal data can not be carried.

As noted by @Antonio Vazquez (antoniov) already, this is not a bug, but rather a todo. So archiving this report. I also added a note in the wiki todo list about this.

@Neeraj Singh (uniqueboy), could you please try a nightly build and see if your issues still persist? If you still have issues, then we would need an example Blender file that demonstrates those issues.

I still cannot reproduce the crash with the auto-smooth normals here on Linux. @LazyDodo (LazyDodo), could you try if you can get a crash/backtrace on Windows?

Will check on it a bit later.

Thanks for the suggestion, but we don't accept feature requests in our bug tracker. You can use the community run ideas site righclickselect.com, or the bf-funboard mailing list instead.