Page MenuHome

Array modifier is slow when "first last" is enabled
Closed, InvalidPublic

Description

System Information
Archlinux
Nvidia GTX 460

Blender Version
Broken: 2.7 RC
Worked: 2.69 Release

Short description of error
Using an array modifier with First Last enabled causes blender to lag during transforms. This does not occur in 2.69.

Exact steps for others to reproduce the error
Based on

  1. Open attached .blend
  2. Press S+Shift+Z and scale. Using the RC it will be slow, but in 2.69 it is smooth
  3. Disable First Last in the array modifier. Now it will transform smoothly in the RC.

Event Timeline

Ellwood Zwovic (gandalf3) raised the priority of this task from to 90.
Ellwood Zwovic (gandalf3) updated the task description. (Show Details)
Ellwood Zwovic (gandalf3) edited a custom field.

I couldn't reproduce this on archlinux 64bit with NVidia GTX 660. It is slightly slower with first-last enabled (which is to be expected for a high-density mesh), but not dramatically and i couldn't notice any difference to 2.69.

It's quite a bit slower in 2.7 for me.. Should I make a video or something?

Lukas Toenne (lukastoenne) lowered the priority of this task from 90 to Normal.Mar 7 2014, 11:42 AM

@Ellwood Zwovic (gandalf3), videos are useless for the bug tracking.

Can't redo the issue as well tho. Try loading factory settings in both 2.69 and 2.70 and see whether it makes things behave the same speed.

I can't seem to reproduce it anymore either..

However, both 2.69 and 2.70 are much slower with First Last enabled then with only merge enabled. Is this expected?

Well, it might to be slower (coz it requires more computation), but it's not something visually slower here. Do you use the same file for tests?

Yes, I used the same file. The slowdown is very noticeable during transforms (scale, rotate, etc.).

Hello,
I ran some tests. Taking a Suzanne with subsurf at 2, thus 7958 verts each item. Another identical Suzanne is used for caping.

Without merge option:

  • without cap start / end: Array count=9, time= 0.21s
  • without cap start / end: Array count=11, time= 0.27s, cost of 2 additionnal Suzannes: 0.06s
  • with cap start & end: Array count=9, total Suzannes= 11, time= 0.23s, cost of 2 capping Suzannes: 0.02s

Thus without merge, capping is actually less costly than array items.

With merge option:

  • without cap start & end: Array count=11, time= 0.32s
  • with cap start & end: Array count=9, time= 3.03s !!

Conclusion: there is indeed something strange with capping when merge option is set. I did not try earlier versions to compare.

My suggestion would be to switch to non-bmesh array modifier, which would be 10 to 100 times faster.

version 2.67 gives same results.

Lukas Toenne (lukastoenne) changed the task status from Unknown Status to Unknown Status.May 2 2014, 12:31 PM
Lukas Toenne (lukastoenne) claimed this task.

Closing this report due to inconclusive results and no direct approach to fixing. If D443 is merged this would solve the issue, other than that there is not much we can do about it.