Further Performance improvements

[VincentKueszter]

Hello,

I sat down and tried to get a bit more performance out of the script.
Baseline, vertex colors only: 23,8 fps
I made the following changes, one per commit:

• min/max clamping of weights per lambda: 24,08 fps (It's really hard to read imo, if this can be formatted in a better way, I'd be glad to improve it!)
• vertex_color as 2D data structure -> easier to read and 25,21 fps (with only this change)
• added global object for original edge length -> 25,8 fps (with only this change)
• added index mapping: from the loop-based index to a vertex-based index, this also simplifies the setting of the vertex colors -> 28,37fps (with only this change)

I now get 31,32fps with all those changes together.

I'll mark this as draft for now, since I want to look into it a bit more, but your input would be appreciated!

[ScottishCyclops]

Thank you !
I'm about to read your code. That sounds promising.

[ScottishCyclops]

It's really hard to read imo, if this can be formatted in a better way, I'd be glad to improve it!

I've always found the python way of writing inline ifs (ternary) very readable, as in you can read the line of code in English and it makes sense.

No problem with readability in my opinion.

I'm glad to hear this increases performance, because it clearly increases the overall readability too 👍

[ScottishCyclops]

Very nice, and a lot more readable again ! Good job.

[VincentKueszter]

It's really hard to read imo, if this can be formatted in a better way, I'd be glad to improve it!

I've always found the python way of writing inline ifs (ternary) very readable, as in you can read the line of code in English and it makes sense.

No problem with readability in my opinion.

I'm glad to hear this increases performance, because it clearly increases the overall readability too 👍

If I could, I would format it like this. It's a bit easier to see what happens in each case at a glance, in my opinion.

lower if value < lower else 
upper if value > upper else 
value

[ScottishCyclops]

I don't really like using a class for a single, may I say constant, variable.
I think the function (as it was in your previous commit) is better.

I'm the kind of dev that likes to use OOP only when it really makes sense, and keep to functions and data structures for the rest.

I don't think it resolves the problem of "If the object's geometry changes, you have to refresh manually", right ?

Here is what I propose:
This is an extra boost of real-time performance, for the ones that really need it. So why not use the same principle as the "cache" functionality found in many places in Blender ?
You would manually choose to "cache" a mesh for TensionMap, enabling this performance gain.
But since you manually chose to enable cache, then it's okay to have you update the cache when you change the mesh.

That way, most users have the current behaviour of auto updating every frame, but don't have the hassle of updating the mesh in TensionMap manually everytime.
And the hardcode real-time users can choose the functionality, knowing they will need to manually update.

If you don't want to work on the UI part of this, let me know, I'll gladly do it.
I'll take your current work here, turn it into a function, and link it to the UI.

[ScottishCyclops]

Ok I like this.

But it would be under the same optional "cache" behaviour, because again, when you change your mesh, you would need to manually update the TensionMap. See my other comments.

[ScottishCyclops]

It's really hard to read imo, if this can be formatted in a better way, I'd be glad to improve it!

I've always found the python way of writing inline ifs (ternary) very readable, as in you can read the line of code in English and it makes sense.
No problem with readability in my opinion.
I'm glad to hear this increases performance, because it clearly increases the overall readability too +1

If I could, I would format it like this. It's a bit easier to see what happens in each case at a glance, in my opinion.

lower if value < lower else 
upper if value > upper else 
value

One line is fine by me. It starts to take more room than it really should otherwise.

[VincentKueszter]

Here is what I propose:
This is an extra boost of real-time performance, for the ones that really need it. So why not use the same principle as the "cache" functionality found in many places in Blender ?
You would manually choose to "cache" a mesh for TensionMap, enabling this performance gain.
But since you manually chose to enable cache, then it's okay to have you update the cache when you change the mesh.
That way, most users have the current behaviour of auto updating every frame, but don't have the hassle of updating the mesh in TensionMap manually everytime.
And the hardcode real-time users can choose the functionality, knowing they will need to manually update.

Caching is a really fitting name for it! Sounds good.

If you don't want to work on the UI part of this, let me know, I'll gladly do it.
I'll take your current work here, turn it into a function, and link it to the UI.

I'll try it myself next week, the UI part didn't seem too complicated.

[ScottishCyclops]

I'll try it myself next week, the UI part didn't seem too complicated.

Alright.
I'm picturing a button that says "Cache Geometry Data" with a hover text of something like "Improve realtime performance by pre-calculating some geometry data. An update to the mesh will require a manual cache update".

When the cache is enabled, the button is replaced by two buttons (in the same line maybe) that say "Disable cache" and "Update Cache".

The update of the Cache would need to stop being linked with tm_update, because it would have it's own operator.

Have fun coding :)

[VincentKueszter]

Okay, I re-implemented it as a cache.
I used dataclass instead of named tuple because it was a tiny bit faster.
I also updated the GUI and GUI code a bit, the row/col variable names were swapped and I removed some duplicated strings.
There should be no further performance improvements, even though I added a few more variables to avoid dot-chains.
Hope I didn't miss anything!

[VincentKueszter]

I added some more performance improvements by using bMesh:
7,9% more fps with vertex colors only and 10,2% with vertex groups only.

[ScottishCyclops]

Hey, Haven't had much time recently. I'll be sure to test & merge your changes as soon as I can. Thanks for the contributions !

[VincentKueszter]

Hey, did you have time to look over it yet?

[ScottishCyclops]

Hey,
No sorry. Back to school and haven't had time.
This has gotten down in my priority list.

[VincentKueszter]

Alright! I'll wait for a notification then.