@Karlis Stigis (karlisstigis) Thanks for the example. I suspect you're looking at the effects of T65816: Exporting procedural mesh animation with Alembic results in a static mesh which is waiting for T60094: Render crash when using Python API to modify object data in frame_change_pre handler to be fixed first.
@Sybren A. Stüvel (sybren) Here is a simple example file where multiple meshes get combined in one. Of course in cases where geometry is generated completely from scratch, exporting to Alembic makes more sense, but combining many objects in one is still useful, because then you can reimport those as 1 alembic file and not mess around with hundreds of objects + retime animation.
Tue, Aug 20
Ok, seems the desired effect of variable speed control can be already achieved by animating the override frame and / or the frame offset. Furthermore it would have introduced hassles with the previous frame state being potentially inconsistent. Closing.
Modifier evaluation should be stateless (except for physics sims with caching). Behavior can't change depending on what the previous frame was, that breaks scrubbing and render farms. I don't think integrating animation curves is going to be practical either.
@Kévin Dietrich (kevindietrich) I suspected as much. Thanks for confirming ;-)
I don't think that a simple "don't move back" rule is going to be very useful. The problem is that when the frame_scale lowers, the Alembic timekey is computed in a way that assumes that frame_scale has always been that low. To get this working properly, I think you'll have to integrate the curve.
- changed the RNA wording
- exposed a readonly timecode to the UI
- attempted to get rid of backward moving of objects when reducing the frame scale interactively or via keyframe, but objects seem to be temporarily stuck, any ideas for this ? Probably not properly solveable... hmm
@Sybren A. Stüvel (sybren), sorry for the late response but I am not actively working on anything Blender related at the moment.
LGTM. Can you also add a unit test that uses both the frame scale and offset?
Mon, Aug 19
@Philip Luk (PixelTrader) that's good news! If you want you can upload it as a diff to Differential; that way I can take a look at the approach you're taking and give some feedback before you spend too much time polishing things ;-)
@Karlis Stigis (karlisstigis) Please make it possible for us to verify this, by providing us with an example blend file and clear steps on how to reproduce. Also, 'b2.8' is not really a clear indication of which exact version of Blender you tested with; please test with the latest daily build from https://builder.blender.org/download/.
Sat, Aug 17
It seems this is still a problem in b2.8
Fri, Aug 16
@Christophe Leyder (shotalot) It's not a trivial thing to solve. It'll take more time, can't make any promises as to when there is enough time to implement it. It's still on the TODO list, though.
Since last asking for information it has been 7 or more days, due to the policy of our bug tracker we will have to archive the report until the requested information is given.
I've done some digging, and it seems to be an issue with the reading applications. Both Gaffer and USDView show the wobbling scale issue. Exporting @colin (col-one)'s file with 24 FPS and then importing into Gaffer or USDView works fine. It's when there is a different frame rate that these programs fail.
Tue, Aug 13
With mdd cache there is an original mesh with fixed coordinates that are being deformed, with Alembic there are only the deformed coordinates.
I don't think we can use the same approach as @Bastien Montagne (mont29) did in b890f0d7e8a6 for Alembic. The FBX addon loads the entire animation into a Blender F-Curve at import time. This contrasts the streaming approach we use when reading Alembic, where modifiers and constraints are used to read the Alembic file at a certain timecode and apply that to Blender. @Kévin Dietrich (kevindietrich) 's approach in D2324 looks good, but is almost 3 years old already.
It's not just a change in tessellation, changing vertex position and face areas can lead to a different child particle distribution even if the tessellation is the same.
I discussed this with Brecht, and it's probably due to the way hair is distributed over the mesh. This is done using the tesselated faces (which are tris or quads), which in turn are based on the original mesh coordinates. Blender loads deforming meshes from Alembic into its own memory, so the current frame is always seen as "the original". This means a potential change in tesselation, which means a potential change in hair positions.
This is probably the same issue as T63534.
Fri, Aug 9
@Libor Batek (lbatek) please provide us with a valid example file. The ABC file from the attached zip seems to be corrupt:
@Kévin Dietrich (kevindietrich) Are you still working on this?
Fri, Aug 2
Thanks for testing. This seems to be a Maya issue, and not a Blender issue, so I'll close this task.
Thu, Aug 1
vertexColor_blender_colorSet1.abc is also working fine in Houdini 17.5:
I remember that I tried that as well. Anyway, it still does not show up in Maya 2017 and 2018. Funny enough, I tried it in 3ds max 2019 and there they are.
Blender's hair system is very picky when it comes to the mesh it's attached to. Especially when grooming, it is vital that the face & vertex indices remain the same. Are you sure that the mesh in Alembic didn't change between grooming the hair in Blender and getting these errors?
The structure in Alembic seems to be the same in both files. Both use a subproperty of .arbGeomParams, and both use indexed colours (thanks to D3704). Maybe Maya is very particular about the name of the vertex colour map? That's the only real difference I see; the Blender-produced file has Col whereas the Maya-produced file has colorSet1.
Tue, Jul 30
Thanks for confirming :)
Tue, Jul 23
More than a week without reply or activity. Due to the policy of the tracker archiving for until required info/data are provided.
Jul 18 2019
Thanks, Sybren! Do you have an idea when we can expect 2.81 to be open so we can test it?
@Philipp Oeser (lichtwerk) I can't see that BLI_assert failure here, maybe it's been fixed already.