Page MenuHome

Proportional editing lag
Open, Confirmed, MediumPublic

Description

System Information
Win7 x64, GTX 460

Blender Version
Broken: 2.73, 2.74
Worked: 2.63

Short description of error
With proportional editing on, I get a few seconds freeze when activate translating (G); than after freeze,
everything goes ok. I thought that the problem was a large mesh, but 2.63 works great and without lags in the same file.

Exact steps for others to reproduce the error
My "bugged" file is the one, I am working with. If it is possible, can i sent it in private and not give it to the world here?

Thank you!

Details

Type
To Do

Event Timeline

Maxim Tkachenko (maleficmax) updated the task description. (Show Details)
Maxim Tkachenko (maleficmax) raised the priority of this task from to Needs Triage by Developer.

Please attach a file which shows the problem. With this kind of an issue you can probably re-create a file which has a similar issue.

Campbell Barton (campbellbarton) triaged this task as Needs Information from User priority.Mar 18 2015, 1:06 PM

Here it is


If I remove part of mesh, it lags less.
But in older versions, it worked perfectly fast in any cases.

Julian Eisel (Severin) raised the priority of this task from Needs Information from User to Confirmed, Medium.Mar 22 2015, 8:32 PM

Can confirm that. Seems to be due to the amount of polys in the .blend. The question is: Why did it work in 2.63 but doesn't after that (didn't check 2.64 though)? @Campbell Barton (campbellbarton), does that ring any bells for you? I can try to find the commit to blame if not.

checking through my old blenders....

r55260 works fine
r58134 has lag

Afraid this is working as intended.

Whats happening is:

  • PET is set to calculate connectivity info.
  • Connectivity info works differently in newer Blender versions (more correct infact since old code mixed real distance with connected distance).

The file attached in this report is a good example of worst possible case you could attempt to use connected-proportion-editing in.

I spent some time to optimize this case, and nearly got it a lot faster (nearly twice as fast). But theres still a very noticeable lag.

To support this case we would have to support re-calculating connectivity during transform, so it only calculates the data needed - then calculates more as the radius increases.

It would still be possible to take a mesh like this and shrink it down, or make the radius include the entire mesh (so its not fool-proof). But in cases like this where you edit only a portion of the mesh, it would resolve the issue.

Marking as TODO, since the code is not failing, this is just an extreme case which happens to be slow.
For now, in this case I can only suggest to workaround the issue - disable connected proportional-editing, or split out the geometry.