In D5675#139419, @Ivan Cappiello (icappiello) wrote:

i believe that exposing the need of using a prefix or suffix is better support for the user than answer to all fake bug reports related to a wrong usage of the add-on. If you let people understand what the add-on should work like, they usually learn how to do it. Rigify has suffered for long time of undocumented feature and obscure feature options in the ui.

In D5675#139410, @Ivan Cappiello (icappiello) wrote:

what about a naming section with "suffix" checkbox, a text field and an append/prepend option?

In D5675#139396, @Ivan Cappiello (icappiello) wrote:

i am more concerned about the naming issue:
Since the source rig is by default named metarig, when it generates use to default rig as name. Most people uses it like that.
If you do not append _rig at the end, when making a proxy it will became very difficult to get what you are looking for.
So, yes, it could be removed, but then you have to explain the users they have to put something there to find it later on.
i think this is not good so, in my opinion, _rig should stay.

This was merged in ca85dbc76c57.

Hi @Sergey Sharybin (sergey), thank you.
UVs appear fixed, but I’m not sure about the vertex colors. In the test file below, one vertex of the mesh labeled V-Cols is supposed to go from blue to white on playback.
The one labeled V-groups has one vertex shift to the right with a Displace modifier.
The lattice Points are also animated.

Some fixes for the HDRI point selector, implemented geographic coordinates parser field using a GPL module by Maximilian Högner, to allow users to paste coordinates from an online map.

All right, I’ll give it a rest for the time being, the map can be reimplemented later. The current code for it won’t work at all since it relies on the Display manager class, which I removed. But it was broken for a long time anyway, I had to use Blender 2.75 to see how it behaved.

Fix mirror ball environment formula

I opened a diff at D5825, and restored mirrorball projections for HDRI sun selections.

That’s fine with me. Some points which certainly need discussion are:

• The reimplementation of the HDR and world map modes, which were in my opinion overly complex in the previous version, but maybe they fit others’ use cases. The shader part can definitely be simplified using the new gpu and gpu_extras modules, but I’m not sure about the UI.
  • For the HDR sun selection, I don’t think the user needs to display it permanently, since the purpose is to choose a precise point on the texture and then sync it, so a one-time operation fits better.
  • For the world map, I’m not sure overlaying it on the 3D View or properties panel is right. Maybe displaying it inside an image editor would be better, but I’m not sure yet.

Rebase against @Alexander Gavrilov (angavrilov)’s generation refactor.

@Alexander Gavrilov (angavrilov) Yes, I thought so. I’ll update it as soon as possible.

Committed in rBA0f5738d9022c.

Well, if the smoke simulation is broken, there are probably other areas affected as well… For instance, I just tested with a particle system, and the particles stick to the surface instead of falling down. It is fixed by rBAc3348263dc26 as well, though.

Sorry about that, I introduced the bug. It is alleviated by rBAc3348263dc26, but it will still happen if the smoke mesh has animation data.

All right, thanks!

This happens when trying to copy bones which have python-created custom properties, but no matching ui_props. In this instance the offending properties most likely come from the blender_mmd_tools add-on.

I implemented multi-object editing in rBAfe627477c250, but this makes the logic twisted, since there are several behaviours in keyframe insertion, depending on type and whether the key is inserted on data or shape key. I will explain the current logic below:

@Brendon Murphy (meta-androcto) Thank you for the welcome, the process has been very pleasant so far. Pushing my commits was easier than I expected!
I have pushed two commits to add-ons and contrib as instructed: rBA610fb38cc215 and rBAC8b5ea4d118e5.

Well that’s bizarre, the latest Linux nightly build works for me, and the other builds are shipped with the same version of the add-on as well. Have you installed the add-on manually from the preferences, or copied the script in your addons directory? Could there be a conflict? If so, you should delete it so that Blender uses the one from the downloaded version.

Thank you for looking into it.
I forgot to mention that the same lack of update also happens with lattice points’ locations. The issue with the lattices can’t be demonstrated with a blend file though, because the workaround found by Rombout Versluijs can’t apply since even the location isn’t updated.
I don’t know if I should open a new bug report for this, as it seems related.

In D3162#126725, @Piotr Nikov (piotrnikov) wrote:

Hello!
This doesn't seem to work on curve points. Unless I'm mistaken of course!
. Add Circle (or any sort of curves), go in Edit Mode.
. Choose point, Insert Key.
. Change frame, move point, Insert Key: The point snaps back to where it was, resulting in no animation...
Am I the only one?
Piotr

I don’t think the add-on should check for the render engine. If the user imports an image while the current render engine is Cycles, and then switch to Eevee, they’d expect the image to behave the same. Besides, the material setting is ignored by other render engines, so it should be okay to set it anyway.

I don’t know what precisely changed in the way Blender handles visibility when objects are children of an object in a hidden collection, but this ought to fix it. Widgets need to belong to the Widgets collection.
@Lucio Rossi (luciorossi) @Alexander Gavrilov (angavrilov) @Ivan Cappiello (icappiello)

In T68332#753819, @Rombout Versluijs (rombout) wrote:

My workaround is, add keyframe UV and Points in object mode. Then it worked for me.

Yes, but it doesn’t apply for lattices, since they only have point locations, and no UVs.

@Rombout Versluijs (rombout) Hi, thanks for the report. Indeed, there seems to be a refresh problem with UVs. It also seems to happen with mesh vertex groups, vertex colors, and lattices’ point locations, only I couldn’t apply your workaround for the latter.

Hi, thank you very much for the detailed answer.
I have looked already at the documentation pages you linked to, subscribed to the mailing lists, and am ready to maintain the add-on. I’m familiar enough with git not to mess it up too bad!

@Brendon Murphy (meta-androcto) Thank you!
Sure, I should be able to maintain it. I don’t have commit access, though, I will have to read up on that.

@Alexander Gavrilov (angavrilov) Perfect!

In rBA011f7afde41efc6fa16084e0f406f5287dc3c481#233244, @Alexander Gavrilov (angavrilov) wrote:

@Damien Picard (pioverfour) Since feature sets is your contribution, maybe you can test if I broke something for your usage? Feature sets that only use relative import paths for their modules should work without any change, as the only difference should be the full module name.

• Replace kern with kerning
• Remove comment
• Add property description

This was introduced in rBAcadeb9991cb6.
Here’s a suggested fix.

I don’t understand what you are trying to do, Alexander's branch is for 2.8 as implied in the branch name, right?

I can’t test on Mac OS, but it works for me on Linux when applied upon the latest commit.

In T52758#621084, @Ivan Cappiello (icappiello) wrote:

I believe the correct behaviour should be a sort of install external module button (just like the install addon button) that will copy the external module in the correct syspath making the module local and available. Doing this will require also a list of installed modules and a remove module button in the preference.

I don't think it was retained as a priority but I mentioned it at the meeting we had after the conferences. Not during my talk, though.

Hi guys, happy new year.
We met during the Blender conference, I'm the cutout guy.

Thanks, my bad.