Sapling addon leaves glitch and crashes blender (unresponsive) #38495

New Issue

Tim · 2014-02-05T06:34:00+01:00

Tim commented

2014-02-05 06:34:00 +01:00

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)

**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)

Tim commented

2014-02-05 06:34:00 +01:00

Changed status to: 'Open'

Tim commented

2014-02-05 06:34:00 +01:00

Added subscriber: @TimCrellin

blender-admin commented

2014-02-05 06:34:00 +01:00

#37507 was marked as duplicate of this issue

blender-admin commented

2014-02-05 06:34:00 +01:00

#37819 was marked as duplicate of this issue

blender-admin commented

2014-02-05 06:34:00 +01:00

#37112 was marked as duplicate of this issue

blender-admin commented

2014-02-05 06:34:00 +01:00

#39603 was marked as duplicate of this issue

Andrew Hale was assigned by Brecht Van Lommel

2014-02-05 21:45:11 +01:00

Brendon Murphy commented

2014-07-30 16:44:13 +02:00

Added subscriber: @BrendonMurphy

Brendon Murphy commented

2014-07-30 16:44:13 +02:00

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

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

Brendon Murphy commented

2014-07-30 16:52:05 +02:00

Added subscribers: @gandalf3, @brecht, @truman, @jrsmoots, @kevindietrich, @ideasman42, @mont29, @Sergey, @Traverso, @Harvester, @RobertDowling, @a.vector

Brendon Murphy commented

2014-07-30 16:52:05 +02:00

◀ Merged tasks: #37112, #39603, #37819, #37507.

Robert Forsman commented

2014-08-01 19:53:23 +02:00

Added subscriber: @mutantbob

Robert Forsman commented

2014-08-01 19:53:23 +02:00

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.

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.

Robert Forsman commented

2014-08-01 20:30:08 +02:00

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.

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.

Oren Titane commented

2014-08-02 22:16:02 +02:00

Added subscriber: @Genome36

Oren Titane commented

2014-08-02 22:16:02 +02:00

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.

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.

Brendon Murphy commented

2014-08-04 20:34:29 +02:00

initial fix by purplefrog in irc https://developer.blender.org/rBA0e536cd1b7225ef7b6c9edd982b2d9d5c527ce92
fixes for armatures are still needed.

initial fix by purplefrog in irc https://developer.blender.org/rBA0e536cd1b7225ef7b6c9edd982b2d9d5c527ce92 fixes for armatures are still needed.

Brendon Murphy commented

2014-08-04 22:25:56 +02:00

Changed status from 'Open' to: 'Resolved'

Brendon Murphy closed this issue

2014-08-04 22:25:56 +02:00

Brendon Murphy commented

2014-08-04 22:25:56 +02:00

fixed armature parent & animation.
https://developer.blender.org/rBAcc4a3674e44c18c4d7ed38033c981d949f90a0bd
closing.