The bug affects 2.79 as well.
It seem the issue came along with Pitchipoy integration.

While this is the right place for blender bugs, we don't take any bugs on 3rd party addons, you'll have to sort this out with the baketool people.

Perhaps the best option is to write an external tool: a very simple stand alone program which can normalize all the weights and save to a clean fbx file. This way we would avoid polluting blender and we would not be limited to python. We could even use the autodesk SDK (need to check their license though).

I don’t say trying to fix those stupid weighting is bad or wrong, I say that doing so by only normalizing on a per-vertex basis is wrong. With your code, a set of weights for three vertices like that ((0.1, 0.5, 0.2), (0.2, 1.6, 0.2), (3.0, 2.4, 0.6)) would be normalized to something like that (if I followed your code correctly): ((0.1, 0.5, 0.2), (0.1, 0.8, 0.1), (0.5, 0.4, 0.1)). On set of weights remain unchanged, while the two others are scaled by different factors - you end up with vgroups totally different from input ones, not only uniformly scaled, which imho is not acceptable in general. That’s why I said 'scale them all by highest weight found', and you are done. If people want to normalize their groups afterwards, they can do it - but it should not be done silently by default, and certainly not while letting some unnormalized.

The crash comes from bpy.ops.mesh.edge_face_add('INVOKE_DEFAULT') which is an Blender's operator. The crash will happen with the regular F too.
That can be tested as by starting with loading factory settings or disabling the F2 operator and pressing F twice.

In D2713#64090, @Bastien Montagne (mont29) wrote:

Mesh seems to be valid, so looks like it's F2 which is doing something wrong here? At least would be my first bet…

More than a week passed without a reply.

In D2713#64089, @Paolo Acampora (pkrime) wrote:

Hello mont29, thanks for looking into this

In D2713#64077, @Bastien Montagne (mont29) wrote:

This won’t work that way… Main issue with this patch is that it ignores weights below 1.0 (so they won't be scaled accordingly when bigger ones are).

All weights are scaled in the latest block (line 2189). No need to store weights below 1.0 in the dictionary, as no information is lost when we assign them to the vertex group

Hello mont29, thanks for looking into this

This won’t work that way… Main issue with this patch is that it ignores weights below 1.0 (so they won't be scaled accordingly when bigger ones are). Further more, adding yet another storage here can edn up being a problem with big meshes or lots of objects (cases that are already not-so-well handled). Further more, different 'maximum weights' would lead to different normalization factor, which

hi, I believe this bug was incorrectly reported. shift/d worked fine, Alt/d however brought about an error.
This should be solved by: 7bc990e29c31
thanks

Had tabs on left mixed up.

Vuk: Yes the current netrenderer does not allow selecting GPU for cycles...

Thanks for the suggestion, but this tracker is not for feature requests, see here for other options:
https://wiki.blender.org/index.php/Dev:Doc/Contact#Requesting_Features

Can you please clarify what the issue is?

Not seeing that here on osx 06/19/17 build

hey @Brendon Murphy (meta-androcto) can you please have a look at this?

hi, I'm having trouble reproducing this, could you try with a nightly build from here: https://builder.blender.org/download/
thanks

BTW by "shifting them into one another" I mean they should intersect, but not completely overlap.

hi, unfortunately we are no longer accepting new addons, Blender 2.79 is closed to new addons & It will be some time before we add new addons to Blender 2.8.
you are of course welcome to re-submit once Blender 2.8 is stable & accepting addons again.
Please note, we have strict rules about addons accessing the internet & manipulating flies. If this addon is business related, that should be clearly started & a fee for inclusion may apply.if we were to accept.
Closing as archived

closing duplicate

hi, it's best to approach the vendor to ask why his addon is not installing

Here is the wiki for addon acceptance procedure:

I've found that it still prints out okay it is just when i view it as an stl file that it looks wrong still not sure why.

Thanks for the fix.

In fact, initial report is not solvable either, for pretty much same reasons: imagine you have two objects using same mesh, with at least one object with a modifier. Then we have to produce two different meshes in FBX, and we have to give them different names for consistency…

This is not as simple to solve as it may look, we cannot apply modifiers to original mesh, that would modify existing Blender scene itself! So we have to make a temp copy of the mesh, and apply modifiers on it. Thing is, in Blender two datablocks of same type are not allowed to have same name. Will see if we can work around that in exporter somehow…

Note that this also happens when using linked mesh data. For example you create a sphere, add a subdivision modifier, create a bunch of (let's say 3) linked copies with Alt+D. Now when you import this into UE4 using the scene import you will end up with 3 meshes instead of one because the links were effectively broken during export.