@Sergey Sharybin (sergey) nope, for me as well speed are very high and similar.

More than a week without reply or activity. Due to the policy of the tracker archiving for until required info/data are provided.

This is a problem with event handling, looks like ubuntu is using a new system, or changed something one way or the other… We'll need some dev with that OS to try to reproduce.

More than a week without reply or activity. Due to the policy of the tracker archiving for until required info/data are provided.

Not sure whether that difference in speed is expected, maybe @Jeroen Bakker (jbakker) or @Clément Foucault (fclem) would know more? Or maybe @Sergey Sharybin (sergey), although I would not expect depsgraph to be a bottleneck with such a simple scene…

That *could* be some issue with your hard drive (generating some .blend file corruption)? But that’s really a wild guess, chasing that kind of weird bug that only happens on one machine can be very long and hard.

More than a week without reply or activity. Due to the policy of the tracker archiving for until required info/data are provided.

More than a week without reply or activity (missing attached file). Due to the policy of the tracker archiving for until required info/data are provided.

More than a week without reply or activity. Due to the policy of the tracker archiving for until required info/data are provided.

More than a week without reply or activity. Due to the policy of the tracker archiving for until required info/data are provided.

More than a week without reply or activity. Due to the policy of the tracker archiving for until required info/data are provided.

More than a week without reply or activity. Due to the policy of the tracker archiving for until required info/data are provided.

More than a week without reply or activity. Due to the policy of the tracker archiving for until required info/data are provided.

More than a week without reply or activity. Due to the policy of the tracker archiving for until required info/data are provided.

More than a week without reply or activity. Due to the policy of the tracker archiving for until required info/data are provided.

More than a week without reply or activity. Due to the policy of the tracker archiving for until required info/data are provided.

More than a week without reply or activity. Due to the policy of the tracker archiving for until required info/data are provided.

More than a week without reply or activity. Due to the policy of the tracker archiving for until required info/data are provided.

More than a week without reply or activity. Due to the policy of the tracker archiving for until required info/data are provided.

More than a week without reply or activity. Due to the policy of the tracker archiving for until required info/data are provided.

More than a week without reply or activity. Due to the policy of the tracker archiving for until required info/data are provided.

More than a week without reply or activity. Due to the policy of the tracker archiving for until required info/data are provided.

More than a week without reply or activity. Due to the policy of the tracker archiving for until required info/data are provided.

Well, the day VMs offers proper modern OpenGL support, Blender will run on them. ;)

More than a week without reply or activity. Assuming that was fixed already.

More than a week without reply or activity. Due to the policy of the tracker archiving for until required info/data are provided.

More than a week without reply or activity. Due to the policy of the tracker archiving for until required info/data are provided.

More than a week without reply or activity. Assuming that was indeed fixed then.

More than a week without reply or activity. Due to the policy of the tracker archiving for until required info/data are provided.

More than a week without reply or activity. Due to the policy of the tracker archiving for until required info/data are provided.

More than a week without reply or activity. Due to the policy of the tracker archiving for until required info/data are provided.

That looks like a GPU/driver issue, are you using the latest official drivers from AMD?

More than a week without reply or activity. Due to the policy of the tracker archiving for until required info/data are provided.

This is still needing feedback… You should be able to sort that at the studio directly?

More than a week without reply or activity. Due to the policy of the tracker archiving for until required info/data are provided.

Also, please always try the latest build from our buildbot before reporting a bug.

As you can easily check by re-importing back same FBX into Blender, your third object is not lost at all.

You are using the EXPERIMENTAL! apply transform feature, that one does not work very well with anything but basic model, hierarchy, animation etc. are known broken. That’s why it’s called experimental. ;)

Confirmed, overriding collection in first scene somehow loses its (linked) reference when overriding in second scene…

I was asking to open those EXRs in another application, like an image viewer, 12 at once. To check whether your computer is able to handle that many EXR reading or not (Blender does nothing more than that, but with 12 threads it might do 12 at once).

Proper diff from blender-v2.81-release branch...

Arg there was a prpblem with the rebase to 2.81 release branch it seems… sigh

auto-parsing of commits in 2.81 branches is still not fully working it seems… Changed those 'flags' in rBA2476c0b4b2789e65f1ef95989d4e42dfd784be45 (and merged it in master), so this should be testable in next daily build.

Thanks for the report, but there is no bug here, it is intended behavior. Indirectly linked collections are not 'instantiated' in the view layer anymore when linking/appending, as often 'utilities' collections are used in such indirect linking, that should not be visible in the scene. It is always possible to add them to a view layer e.g. with drag-and-drop in the relevant Outliner view…

There is no bug here, things are working as expected, with some limitations indeed. This is a complex mix of python and blender API, you cannot always use all the magic of pristine python with it.

Grmlll, broken auto-close with fixes in release branch it'd seem… Fixed by rB1c2a20c84d46d30b.

The broken bone is ctrl_hand_pickup.R, it has two 'insert constraint' operations without having any constraints.

Afaik, A tag means 'animated', and U means 'user-defined data' (this is just assumptions from older FBX I analyzed during main development phase of the add-on, think there are no official info about those anywhere)…

Don’t see anything wrong here, besides the interrogation about removed call to BKE_pose_channel_free_bbone_cache() noted below…

I guess that’s a valid change… Would be worth adding a comment (with report reference) about why/how that case (no rebuild required, yet NULL physics_world) can happen? This seems to be related to undo/redo, from quick skim over the report?

OK, so I will fix the crash, but imho the real bug is how that situation could happen (we have 'insert constraint' override operation on a posebone's constraint stack which have no constraint at all neither in the local override nor in the linked reference data-blocks, this is not supposed to happen).

Thanks, will check.

This has been fixed in recent commits, while not yet 100% ideally working, would consider that task as resolved.

@Demeter Dzadik (Mets) please make report(s), it’s waaaayyyyy easier to keep track of issues that way. ;)

Thanks, can confirm crash, it’s indeed from override code.

shouldn’t that had been committed to the release branch, and then merged into master?

Hrmmm, actually it’s a bit more involved, not sure why we need view3d here, still digging.

That operator is not designed to work without UI at all, it expects a valid 3DView from the context.

I don’t think we should apply scale to extrude value, for several reasons:

• Extrude value does not change when you scale the curve in Edit mode
• Applying non-uniform scale will never give you the same result anyway, this is just not possible, so trying to have a half-working situation would be worse imho than assuming plainly that we cannot support applying object scale to things like extrude parameters.

Again, confusing cursor handling in Text editor and cursor handling in edit mode of Text object in 3DView…

Those operators are two completely different things, text.move works in the Text editor, while font.move works when editing a Text object in the 3DView.

Well, that would be 12 (or 13) EXRs opened at the same time… I’d have a hard time believing that could eat all of your 16 GB of ram…

You are not addressing my points… again, new code in the FBX exporter puts pose props in the model FBX node, which afaik is the expected behavior…

I hope that this partial switch to tbb does not bite us in some unexpected ways… would have rather switched entirely…

Armature modifier is added by the parenting (to armature) operator, so imho it makes sense that the un-parenting operator removes it. This might not be the expected behavior in all cases, but looks to be a valid default behavior to me. Advanced unparenting can be done by simply removing the relevant constraint or clearing the parent field…

that’s because the operator is Multi Select Loops, with a specific setting, as you can check e.g. in the redo panel… There is no bug here, thanks for the report anyway.

Hrmmmm… A modern computer should be able to read more than two or three EXRs at a time, especially reasonably "small" ones… How many threads do you have on your CPU? and how many RAM?

Thanks for the report, but no bug here really, that’s the beauty of Euler rotations… You need to use quaternions rotation if you want to avoid that kind of brutal changes in the component values.

@Julien DUROURE (julien) yeah, if you could switch to it (and extend it maybe with extra features you may already have in glTF wrapper?), that would be ideal, since that would leave a single place to handle that conversion between nodal shader and 'old', 'fixed pipeline' shading type…

@Julien DUROURE (julien) aye, but iirc glTF uses its own 'translation' system, not the node_shader_utils.py, to get shading values out of a node shader?

Aaaaah, now I can reproduce and confirm the issue, thanks.

Did you actually checked my commit? Now we export EDIT bone props in the attribute node (as expected), and POSE bone props in the model (aka 'object') node, that’s what was missing previously. Would not see any reason to write editbone props in the model, that would be only confusing… and would make separation between edit and pose ones impossible.

There is a severe corruption of at least one mesh in the 46 file, if you append the mesh (not the object) Plane.001 from it into a default startup blender, and then run in the python console D.meshes['Plane.001'].validate(verbose=True), you'll get a lot of errors in the system console…

That’s more of a TODO than a bug really, that property did not exist I think when the node wrapper was written… Will add it to the tool and the formats that support it (iirc OBJ/MTL also has some emissive info?).