Categories
- All Categories
- 1.4K Cubism Editor
- 1.2K Help
- 54 Tips and Tricks
- 200 Feature requests
- 51 Other Live2D Products and Tools
- 1 Cubism Viewer (for OW, for Unity)
- 3 Material Separation Photoshop Plug-in
- 47 Other Live2D Products and Tools (Other Photoshop Scripts, Sample Data, etc.)
- 302 Cubism SDK
- 266 Help
- 11 Tips and Tricks
- 25 Feature Requests
- 182 Community
- 40 General Discussions
- 10 Feature Requests
- 26 Projects, Showcase & Critiques
Complex Warp Deformer Performance Issue (and a tip to avoid it)
Steps to reproduce in Live 2D Cubism Editor 5.3.04:
1) Create a complex Warp Deformer (eg; 10x10 or more Divisions, Angle X + Angle Y with 5 keys each at -30, 15, 0, 15 30, and Extended Interpolation)
2) Create a very simple Warp Deformer* (eg; 2x2 Divisions, no keys)
3) Attempt to deform the simple Warp Deformer
This will incur the same deformation penalty as the complex deformer! However...
4) Put the complex deformer into its own Part (folder)
5) The performance is back!
* The performance hit affects other other types (like ArtMesh) and actions (like selection or movement) too
P.S. For the development team: surely this is a cache issue? The complex warp deformer is a sibling of the other parts in the root / parent part, but if it's not selected and not part of the hierarchy, any calculations on it can surely be skipped since it can't be affected? Unless siblings can affect warp deformers in ways i'm not familiar with. At the very least, moving a sibling part surely should not invalidate this cache? If it's a bounds recalculation then bounds of warp deformers should be cached instead of recalculated.
1) Create a complex Warp Deformer (eg; 10x10 or more Divisions, Angle X + Angle Y with 5 keys each at -30, 15, 0, 15 30, and Extended Interpolation)
2) Create a very simple Warp Deformer* (eg; 2x2 Divisions, no keys)
3) Attempt to deform the simple Warp Deformer
This will incur the same deformation penalty as the complex deformer! However...
4) Put the complex deformer into its own Part (folder)
5) The performance is back!
* The performance hit affects other other types (like ArtMesh) and actions (like selection or movement) too
P.S. For the development team: surely this is a cache issue? The complex warp deformer is a sibling of the other parts in the root / parent part, but if it's not selected and not part of the hierarchy, any calculations on it can surely be skipped since it can't be affected? Unless siblings can affect warp deformers in ways i'm not familiar with. At the very least, moving a sibling part surely should not invalidate this cache? If it's a bounds recalculation then bounds of warp deformers should be cached instead of recalculated.
Comments
Thank you very much for using our product.
First, please tell us about your PC environment.
- OS & Version: (e.g., Windows 10, macOS High Sierra)
- PC Model: (e.g., MacBook Pro 2017)
- Graphics Specifications: (e.g., GeForce GTX 950M)
- CPU: (e.g., Intel Core i7-7700)
- Memory: (e.g., 8GB)
- Illustration Software used: (e.g., Photoshop, Clip Studio, SAI)
Next, if possible, please store the model file experiencing the problem and the log file in the following data box.
https://biz.datadeliver.net/posts/WWvyD1kv4dMy
Please note that this data box is only accessible to the development team.
For instructions on how to obtain the log, please see here:
https://help.live2d.com/en/other/other_22/
Thank you for your cooperation.
- PC Model: N/A
- Graphics Specifications: NVIDIA GeForce RTX 3060
- CPU: Intel Core i7 10700K
- Memory: 32GB DDR4
- Illustration Software used: N/A
I have uploaded the problematic file and the relevant log file.
Unfortunately it's just showing the name of the method that is taking a long time. The problem is that it's being called even when other deformers that can't affect it are being changed.
Thank you for your response.
We have shared this issue with the development team.
Thank you for your understanding.