Sapling addon leaves glitch and crashes blender (unresponsive)
Closed, ResolvedPublic

Description

System Information
Operating system and graphics card:
windows 7 64bit
nvidia gtx 660
intel i5 3570K

Blender Version
Broken: 2.69 64bit official release (from blender.org website)
Worked: (optional)

Short description of error
when dragging back/left on the number of leaves (to set it to 0) blender becomes unresponsive for around 20-30 seconds, then a random negative value or positive value (extremely high) will pop up and the leaves, will be flattened along each branch, shortly after which blender becomes unresponsive completely and requires you to close the program.

Exact steps for others to reproduce the error
-add a sapling curve
-select bevel
-go to leaves tab
-select show leaves
-drag left on the number of leaves. (Can be hexagonal or rectangle)

Details

Type
Bug
Tim (thatimster) updated the task description. (Show Details)
Tim (thatimster) raised the priority of this task from to Needs Triage.
Tim (thatimster) added a project: Addons.
Tim (thatimster) set Type to Bug.
Tim (thatimster) added a subscriber: Tim (thatimster).
Brendon Murphy (meta-androcto) raised the priority of this task from Normal to Confirmed.Jul 30 2014, 4:44 PM

hi, confirmed this crashes blender.
I will investigate furthur.
Thanks.

While investigating this using the current git tree (git 3c9e11df37581c6faf937bbe974710a7fc95e380) I noticed that there's an error message:

Traceback (most recent call last):
  File "/home/thoth/vendor/git-blender/build_linux/bin/2.71/scripts/addons/add_curve_sapling/__init__.py", line 550, in execute
    addTree(self)
  File "/home/thoth/vendor/git-blender/build_linux/bin/2.71/scripts/addons/add_curve_sapling/utils.py", line 751, in addTree
    (vertTemp,faceTemp,oldRot) = genLeafMesh(leafScale,leafScaleX,cp.co,cp.quat,len(leafVerts),downAngle[n],downAngleV[n],rotate[n],rotateV[n],oldRot,bend,leaves, leafShape)
  File "/home/thoth/vendor/git-blender/build_linux/bin/2.71/scripts/addons/add_curve_sapling/utils.py", line 341, in genLeafMesh
    oldRot += rotate/(abs(leaves)-1)

Since this is in a branch for the condition ( leaves<0 ) I tried changing that statement to

oldRot += rotate/(abs(leaves))

and now dragging the leaves into negative territory doesn't crash blender, although its behavior is kind of weird if you don't have branch splitting levels >= 3, and even then it seems of dubious utility to my limited imagination.

Based the fact that the field permits negative values and has code to (sometimes) properly handle negative values, I'm assuming that this represents a special mode of the sapling generator which should be preserved.

A second aspect to the reported problem is how dragging can result in very large values for leaves which crash blender. This is mostly a Human Interface Design failure.

Dragging is by nature an interactive action, but in the case of leaf count it's pretty easy to increase the number to the point where it can take a second or ten to calculate the new mesh. At this point, blender is no longer interactive and it is plausible that user mouse movements could easily be interpreted to set the value even farther into crazyspace, exacerbating the problem.

When dragging, I'd say that -100 .. 100 would be a reasonable range (although people with slower computers might choose -50..50 .

However, if you were to just type in the value 1000, my computer takes 21 seconds to compute the mesh, but then the 3D viewport is plenty interactive. In this use case the 100 limit seems pretty silly. It is not unusual for parts of my workflow to take several minutes (physics baking, external simulations), so 21 seconds to generate a tree is no big deal.

I suspect that whatever limit we placed on the leaves value would become a straitjacket on somebody with a legitimate mission (although they would be outliers). If it were possible to limit the dragged values differently than the typed values, I would recommend doing that. If you can't impose separate limits, I'd recommend disabling dragging for the leaves field.

Since this could affect other values settings in the add on we should just disable the update fuction of the bpy.types.uilayout.prop() because each time the number is changed blender tries to recalculate the mesh.

I.E.: While dragging from 0 to 10, it has to go through 9 unnecessary recalculations before giving the one for the value 10.

Solution: add a recalculate button at the bottom and disable update argument.