LGTM too, but am not really familiar with this code tbh...

That this is not a bug in fact, just a TODO.

Note: this is safe enough, and important enough, to go to the 2.81 release branch.

Indeed need to increment user count here.

Arf... OK, so TL;DR: This is not supported auto;atically currently, you have to do some manual work to get it running.

• Merge branch 'master' into tmp-task-foreach-pool
• Pool range iter: compute 'static' scheduler chunk size from smallest range.

@Sergey Sharybin (sergey) Checked this morning, and your use-case is actually the worst, useless one ever to check that feature, since you have few very heavy tasks (not even 10K in total, taking over 1.5sec on a single thread...). Current code is fairly non-optimal here btw, should use dynamic scheduling, not static one.

I would be very careful with that kind of changes (talking on usability level here, not code-wise)… I happen to have had to use LibreOffice in French locale, and guess what? By default, you cannot enter a number using the dot . char (which is on our numpad keyboard), you have to switch from the numpad to the main keyboard all the time, this is incredibly frustrating when working in a spreadsheet. Because french locale specifies comma , as numeric decimal separator.

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

@Germano Cavalcante (mano-wii) that add-on is not officially maintained anymore by blender…

This is indeed working as expected in the code (see call to BKE_animdata_free() in make_object_duplilist_real(), so not a bug. Whether we want a different behavior here is design task, which I'll let to the anim team for handling.

the assert/crash in debug builds is a corruption in the .blend file (there are two brushes called Eraser Point there for some reason, opening and saving that file will fix it).

The crash should be fixed now (was same issue as T70875, fixed by rB74af6987699a.

In T71393#807551, @Philipp Oeser (lichtwerk) wrote:

One more thing though:

• if you open T71393_main.blendand do Object > Relations > Make Library Override > Empty, both hook empties are free to move (that might be expected?), however only the one you have chosen to be overridden displays it transform channels in the turquoise color?

Patch LGTM, and seems like the best approach, considering newly added springs during a step are not used until next step anyway.

Am almost certain that this is same issue as T71055 (and has nothing to do with lib overrides): several Curve objects sharing a same curve data-block but having different modifiers… Most likely a drawing issue.

LGTM now.

@Robert Juricek (rooobertek) please do not re-open closed revisions! If you want to propose a patch, create a new revision.

Am a bit off of undo code since some time now, so not 100% sure i fully got the logic, but from what I understand this change looks good and sane.

Don’t have anything against that feature, so LGTM.

install_deps.sh part looks good to me.

Can confirm the fix for me as well, thanks.

No answer so far, will just assume this factor is not needed anymore and remove it from the importer.

this is not really my area, from quick look in code I have the impression that data onto which the modifier is applied is properly de-duplicated during eval, so I'd first suspect some issue in drawing code itself (also because outline does not follow shown geometry...). it also reminds me of some similar issue we had with meshes at some points, because drawing cache was per obdata and not per object or something like that... that was fixed for meshes, not sure if it was for other geometry types? We need @Clément Foucault (fclem) or @Jeroen Bakker (jbakker) to have a look at that first imho.

Updated against latest master.

Yes, makes sense to me too.

We could for sure enhance handling of what to export in the exporters in general (not only FBX), but that is really not a bug, more like a TODO/nice feature to add…

Note: set priority to 'high' in hope this can be easily fixed quickly (cannot render the last video for the bconf otherwise), feel free to lower prio if this issue is not easily fixable. ;)

Just found out that this commit is breaking my release build (which uses WITH_GHOST_SDL build option, if I disable that one it builds fine):

@Pinus that kind of random assignment is very close to spamming. That’s just a warning, for now. CC @Dalai Felinto (dfelinto) & @Nathan Letwory (jesterking)

Reading vnors into custom lnors is about as expensive as reading real lnors.

Blender has no concept of custom vertex normals, only loops (aka face corners) ones. Checking for 'equal to auto normals' might be possible, but won't be a cheap process, and not so sure it would be worth is… If you export your normals, even as vnors, then one can expect them to have some importance?

I would change that point on new import behavior: