@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.
This issue depends on T60094 being fixed first.
will it be possible to maintain links to USD's, so that when the USD is updated, the Blender file referencing it will be too?
@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.
LGTM. Can you also add a unit test that uses both the frame scale and offset?
Mon, Aug 19
This add-on isn't developed here. If it's a problem with the original version, it should be reported on Github jasperges/pose-thumbnails. If it's a problem with our Blender Institute fork, it should be reported on Gitlab blender-institute/pose-thumbnails.
@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/.
Good point, I've updated the title.
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.
I think having a checkbox that disappears when you un-check it is a bad idea. We've had that before, and it was horribly confusing.
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.
I still can't reproduce this in Blender master (9dab57a9f829881dad1e659b53413ded15ec085e). Also with two different Alembic files imported as two different constraints on two different objects, it just works fine. The source of the Alembic file (whether it was written by Maya or Blender) really shouldn't matter in this.
@Werner Beroux (Wernight) do you have the requested information?
This means they won't be able to turn it on again.
Yes, just like it is now.
The root cause of the crash is that something is allowed via Python that we never do from C. The Mesh.materials.clear() function will remove all the material slots from the mesh, but it keeps the polygon material indices (mpoly->mat_nr) intact. The drawing code then uses mpoly->mat_nr to index into the material slots, which crashes because they aren't there.
Thu, Aug 15
I'm voting against using an enum, as having such an enum would give us three meanings of the word "All":
@Yevgeny Makarov (jenkm) Your proposal looks nice, but it's not complete. What would be shown when Auto-Save is turned off by the user? Do you show the checkbox and the save button at the same time? What if the user wants to reset to factory settings, then turn off auto-save, then save the new preferences, what would that look like?
Wed, Aug 14
Tweaks to space_text.py to minimise changes
- Final feedback tweaks
- Added missing forward declaration
Override the st->showsyntax setting when highlighting is not supported.
- Only apply is_syntax_highlight_supported() to syntax highlighting
- Addressed review comments by @Campbell Barton (campbellbarton)
- Removed unused #include
Partial implementation of the smartness @Brecht Van Lommel (brecht) suggested.
+1 to Brecht's comments, we'd need to update versioning_default.c too.
If we want to make this a bit smarter we could do the following:
- If the name has an unknown extension (not .py, .osl, ..) , don't syntax highlight and gray out the setting in the menu.
- If the name has no extension, still assume Python and syntax highlight. Numeric postfixes like Text.001 would not be considered to be an extension.
Tue, Aug 13
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.
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.
@Brecht Van Lommel (brecht) you're right. I removed the DEG_evaluate_on_refresh call, and everything still seems to be working correctly.
I can confirm the issue. Here is a modified blend file with a bit cleaner logic in the script:
Mon, Aug 12
Fri, Aug 9
Please describe how we can reproduce this issue. Does it also happen with newer files?
When opening the file on my machine things work fine. Be sure to update your graphics drivers to the latest version.
I can confirm that the look of the cryptomatte in the compositor background changes when you change the Color Space setting of the EXR image node, including seeing edges: