If you have any questions, reports, suggestions, or requests about Live2D, please send them to this forum.
※We cannot guarantee statements or answers from Live2D staff. Thank you for your understanding in advance.
Live2D Cubism
Cubism Products and Downloads
Cubism product manuals and tutorials
Cubism Editor Manual Cubism Editor Tutorial Cubism SDK Manual Cubism SDK Tutorial
※We cannot guarantee statements or answers from Live2D staff. Thank you for your understanding in advance.
Live2D Cubism
Cubism Products and Downloads
Cubism product manuals and tutorials
Cubism Editor Manual Cubism Editor Tutorial Cubism SDK Manual Cubism SDK Tutorial
Best Of
Feature Request: Improved Automatic Layout in "Edit Texture Atlas"
Hello! I'd like to suggest an improvement to the Automatic Layout feature in the "Edit Texture Atlas" menu.
Current Behavior:
The current auto layout often leaves a lot of loose/empty space between assets.
As a result, fewer assets fit on a single texture.
Proposed Improvement:
More tight & aggressive optimization option for automatic layout.
The goal is to minimize space between parts and maximize texture usage efficiency.
This would be a huge time saver, reducing the need to manually place assets tightly.
I hope this can be considered in the future updates! Thank you very much!
Image for comparison attached
Current Behavior:
The current auto layout often leaves a lot of loose/empty space between assets.
As a result, fewer assets fit on a single texture.
Proposed Improvement:
More tight & aggressive optimization option for automatic layout.
The goal is to minimize space between parts and maximize texture usage efficiency.
This would be a huge time saver, reducing the need to manually place assets tightly.
I hope this can be considered in the future updates! Thank you very much!
Image for comparison attached
CubsimSDKForNative-5-r.4 OpenGL Sample Linux Memory Leak
Hello,
I was looking at the CubsimSDKForNative-5-r.4 OpenGL Sample and I noticed a potential memory leak in one of the files.
In the LAppView::InitializeSprite(), and the LAppView::Initialize(int width, int height) function, there are calls to make new LAppSprite objects without a delete. This causes a problem because those functions are called when resizing the window.
When running valgrind on the generated Demo executable this is what I found:
==12995==
==12995== HEAP SUMMARY:
==12995== in use at exit: 94,272 bytes in 1,113 blocks
==12995== total heap usage: 107,625 allocs, 106,512 frees, 1,082,851,897 bytes allocated
==12995==
==12995== 4 bytes in 1 blocks are definitely lost in loss record 1 of 175
==12995== at 0x483BE63: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==12995== by 0x13AF59: LAppView::Initialize(int, int) (in /home/Live2D/CubismSdkForNative-5-r.4/Samples/OpenGL/Demo/proj.linux.cmake/build/make_gcc/bin/Demo/Demo)
==12995== by 0x124736: LAppDelegate::Initialize() (in /home/Live2D/CubismSdkForNative-5-r.4/Samples/OpenGL/Demo/proj.linux.cmake/build/make_gcc/bin/Demo/Demo)
==12995== by 0x121C34: main (in /home/Live2D/CubismSdkForNative-5-r.4/Samples/OpenGL/Demo/proj.linux.cmake/build/make_gcc/bin/Demo/Demo)
==12995==
==12995== 408 bytes in 1 blocks are definitely lost in loss record 147 of 175
==12995== at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==12995== by 0x4FB5D1F: _XimOpenIM (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==12995== by 0x4FB595D: _XimRegisterIMInstantiateCallback (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==12995== by 0x4F9C94C: XRegisterIMInstantiateCallback (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==12995== by 0x16DBA1: _glfwInitX11 (in /home/Live2D/CubismSdkForNative-5-r.4/Samples/OpenGL/Demo/proj.linux.cmake/build/make_gcc/bin/Demo/Demo)
==12995== by 0x162B9F: glfwInit (in /home/Live2D/CubismSdkForNative-5-r.4/Samples/OpenGL/Demo/proj.linux.cmake/build/make_gcc/bin/Demo/Demo)
==12995== by 0x1245B0: LAppDelegate::Initialize() (in /home/Live2D/CubismSdkForNative-5-r.4/Samples/OpenGL/Demo/proj.linux.cmake/build/make_gcc/bin/Demo/Demo)
==12995== by 0x121C34: main (in /home/Live2D/CubismSdkForNative-5-r.4/Samples/OpenGL/Demo/proj.linux.cmake/build/make_gcc/bin/Demo/Demo)
==12995==
==12995== 480 bytes in 120 blocks are definitely lost in loss record 151 of 175
==12995== at 0x483BE63: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==12995== by 0x13AF59: LAppView::Initialize(int, int) (in /home/Live2D/CubismSdkForNative-5-r.4/Samples/OpenGL/Demo/proj.linux.cmake/build/make_gcc/bin/Demo/Demo)
==12995== by 0x124112: LAppDelegate::Run() (in /home/Live2D/CubismSdkForNative-5-r.4/Samples/OpenGL/Demo/proj.linux.cmake/build/make_gcc/bin/Demo/Demo)
==12995== by 0x121C4E: main (in /home/Live2D/CubismSdkForNative-5-r.4/Samples/OpenGL/Demo/proj.linux.cmake/build/make_gcc/bin/Demo/Demo)
==12995==
==12995== LEAK SUMMARY:
==12995== definitely lost: 892 bytes in 122 blocks
==12995== indirectly lost: 0 bytes in 0 blocks
==12995== possibly lost: 0 bytes in 0 blocks
==12995== still reachable: 93,380 bytes in 991 blocks
==12995== suppressed: 0 bytes in 0 blocks
==12995== Reachable blocks (those to which a pointer was found) are not shown.
==12995== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==12995==
==12995== For lists of detected and suppressed errors, rerun with: -s
==12995== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0)
There are two mentions in the log with operator new being the last function in the call stack. So, I think my suspicion is right.
After I naively put a delete call right before every new in the LAppView::InitializeSprite(), and the LAppView::Initialize(int width, int height) functions, this is the valgrind output:
==16614==
==16614== HEAP SUMMARY:
==16614== in use at exit: 93,800 bytes in 992 blocks
==16614== total heap usage: 125,355 allocs, 124,363 frees, 1,109,057,836 bytes allocated
==16614==
==16614== 408 bytes in 1 blocks are definitely lost in loss record 146 of 173
==16614== at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==16614== by 0x4FB5D1F: _XimOpenIM (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==16614== by 0x4FB595D: _XimRegisterIMInstantiateCallback (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==16614== by 0x4F9C94C: XRegisterIMInstantiateCallback (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==16614== by 0x16DBF1: _glfwInitX11 (in /home/Live2D/CubismSdkForNative-5-r.4/Samples/OpenGL/Demo/proj.linux.cmake/build/make_gcc/bin/Demo/Demo)
==16614== by 0x162BEF: glfwInit (in /home/Live2D/CubismSdkForNative-5-r.4/Samples/OpenGL/Demo/proj.linux.cmake/build/make_gcc/bin/Demo/Demo)
==16614== by 0x1245B0: LAppDelegate::Initialize() (in /home/Live2D/CubismSdkForNative-5-r.4/Samples/OpenGL/Demo/proj.linux.cmake/build/make_gcc/bin/Demo/Demo)
==16614== by 0x121C34: main (in /home/Live2D/CubismSdkForNative-5-r.4/Samples/OpenGL/Demo/proj.linux.cmake/build/make_gcc/bin/Demo/Demo)
==16614==
==16614== LEAK SUMMARY:
==16614== definitely lost: 408 bytes in 1 blocks
==16614== indirectly lost: 0 bytes in 0 blocks
==16614== possibly lost: 0 bytes in 0 blocks
==16614== still reachable: 93,392 bytes in 991 blocks
==16614== suppressed: 0 bytes in 0 blocks
==16614== Reachable blocks (those to which a pointer was found) are not shown.
==16614== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==16614==
==16614== Use --track-origins=yes to see where uninitialised values come from
==16614== For lists of detected and suppressed errors, rerun with: -s
==16614== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
Now, the two mentions of operator new is gone. There is still one more leak, but I think this one is normal and can be ignored. So, I think the solution "worked", but this is a quick and dirty fix and I don't know the codebase well enough to offer a real fix.
Steps to reproduce:
1. Get a version of CubsimSDKForNative-5-r.4
2. Compile the OpenGL Sample for Linux
3. Choose the Full option when running the build script (never tested on minimum)
4. Run valgrind as follows: valgrind --leak-check=full /Demo
5. Resize the window.
6. Close the window when desired.
7. You should see output similar to first valgrind output.
Is this the right forum to post this question on? I would make a pull request, but I was unsure if there was a standard procedure to follow.
I was looking at the CubsimSDKForNative-5-r.4 OpenGL Sample and I noticed a potential memory leak in one of the files.
In the LAppView::InitializeSprite(), and the LAppView::Initialize(int width, int height) function, there are calls to make new LAppSprite objects without a delete. This causes a problem because those functions are called when resizing the window.
When running valgrind on the generated Demo executable this is what I found:
==12995==
==12995== HEAP SUMMARY:
==12995== in use at exit: 94,272 bytes in 1,113 blocks
==12995== total heap usage: 107,625 allocs, 106,512 frees, 1,082,851,897 bytes allocated
==12995==
==12995== 4 bytes in 1 blocks are definitely lost in loss record 1 of 175
==12995== at 0x483BE63: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==12995== by 0x13AF59: LAppView::Initialize(int, int) (in /home/Live2D/CubismSdkForNative-5-r.4/Samples/OpenGL/Demo/proj.linux.cmake/build/make_gcc/bin/Demo/Demo)
==12995== by 0x124736: LAppDelegate::Initialize() (in /home/Live2D/CubismSdkForNative-5-r.4/Samples/OpenGL/Demo/proj.linux.cmake/build/make_gcc/bin/Demo/Demo)
==12995== by 0x121C34: main (in /home/Live2D/CubismSdkForNative-5-r.4/Samples/OpenGL/Demo/proj.linux.cmake/build/make_gcc/bin/Demo/Demo)
==12995==
==12995== 408 bytes in 1 blocks are definitely lost in loss record 147 of 175
==12995== at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==12995== by 0x4FB5D1F: _XimOpenIM (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==12995== by 0x4FB595D: _XimRegisterIMInstantiateCallback (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==12995== by 0x4F9C94C: XRegisterIMInstantiateCallback (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==12995== by 0x16DBA1: _glfwInitX11 (in /home/Live2D/CubismSdkForNative-5-r.4/Samples/OpenGL/Demo/proj.linux.cmake/build/make_gcc/bin/Demo/Demo)
==12995== by 0x162B9F: glfwInit (in /home/Live2D/CubismSdkForNative-5-r.4/Samples/OpenGL/Demo/proj.linux.cmake/build/make_gcc/bin/Demo/Demo)
==12995== by 0x1245B0: LAppDelegate::Initialize() (in /home/Live2D/CubismSdkForNative-5-r.4/Samples/OpenGL/Demo/proj.linux.cmake/build/make_gcc/bin/Demo/Demo)
==12995== by 0x121C34: main (in /home/Live2D/CubismSdkForNative-5-r.4/Samples/OpenGL/Demo/proj.linux.cmake/build/make_gcc/bin/Demo/Demo)
==12995==
==12995== 480 bytes in 120 blocks are definitely lost in loss record 151 of 175
==12995== at 0x483BE63: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==12995== by 0x13AF59: LAppView::Initialize(int, int) (in /home/Live2D/CubismSdkForNative-5-r.4/Samples/OpenGL/Demo/proj.linux.cmake/build/make_gcc/bin/Demo/Demo)
==12995== by 0x124112: LAppDelegate::Run() (in /home/Live2D/CubismSdkForNative-5-r.4/Samples/OpenGL/Demo/proj.linux.cmake/build/make_gcc/bin/Demo/Demo)
==12995== by 0x121C4E: main (in /home/Live2D/CubismSdkForNative-5-r.4/Samples/OpenGL/Demo/proj.linux.cmake/build/make_gcc/bin/Demo/Demo)
==12995==
==12995== LEAK SUMMARY:
==12995== definitely lost: 892 bytes in 122 blocks
==12995== indirectly lost: 0 bytes in 0 blocks
==12995== possibly lost: 0 bytes in 0 blocks
==12995== still reachable: 93,380 bytes in 991 blocks
==12995== suppressed: 0 bytes in 0 blocks
==12995== Reachable blocks (those to which a pointer was found) are not shown.
==12995== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==12995==
==12995== For lists of detected and suppressed errors, rerun with: -s
==12995== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0)
There are two mentions in the log with operator new being the last function in the call stack. So, I think my suspicion is right.
After I naively put a delete call right before every new in the LAppView::InitializeSprite(), and the LAppView::Initialize(int width, int height) functions, this is the valgrind output:
==16614==
==16614== HEAP SUMMARY:
==16614== in use at exit: 93,800 bytes in 992 blocks
==16614== total heap usage: 125,355 allocs, 124,363 frees, 1,109,057,836 bytes allocated
==16614==
==16614== 408 bytes in 1 blocks are definitely lost in loss record 146 of 173
==16614== at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==16614== by 0x4FB5D1F: _XimOpenIM (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==16614== by 0x4FB595D: _XimRegisterIMInstantiateCallback (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==16614== by 0x4F9C94C: XRegisterIMInstantiateCallback (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==16614== by 0x16DBF1: _glfwInitX11 (in /home/Live2D/CubismSdkForNative-5-r.4/Samples/OpenGL/Demo/proj.linux.cmake/build/make_gcc/bin/Demo/Demo)
==16614== by 0x162BEF: glfwInit (in /home/Live2D/CubismSdkForNative-5-r.4/Samples/OpenGL/Demo/proj.linux.cmake/build/make_gcc/bin/Demo/Demo)
==16614== by 0x1245B0: LAppDelegate::Initialize() (in /home/Live2D/CubismSdkForNative-5-r.4/Samples/OpenGL/Demo/proj.linux.cmake/build/make_gcc/bin/Demo/Demo)
==16614== by 0x121C34: main (in /home/Live2D/CubismSdkForNative-5-r.4/Samples/OpenGL/Demo/proj.linux.cmake/build/make_gcc/bin/Demo/Demo)
==16614==
==16614== LEAK SUMMARY:
==16614== definitely lost: 408 bytes in 1 blocks
==16614== indirectly lost: 0 bytes in 0 blocks
==16614== possibly lost: 0 bytes in 0 blocks
==16614== still reachable: 93,392 bytes in 991 blocks
==16614== suppressed: 0 bytes in 0 blocks
==16614== Reachable blocks (those to which a pointer was found) are not shown.
==16614== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==16614==
==16614== Use --track-origins=yes to see where uninitialised values come from
==16614== For lists of detected and suppressed errors, rerun with: -s
==16614== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
Now, the two mentions of operator new is gone. There is still one more leak, but I think this one is normal and can be ignored. So, I think the solution "worked", but this is a quick and dirty fix and I don't know the codebase well enough to offer a real fix.
Steps to reproduce:
1. Get a version of CubsimSDKForNative-5-r.4
2. Compile the OpenGL Sample for Linux
3. Choose the Full option when running the build script (never tested on minimum)
4. Run valgrind as follows: valgrind --leak-check=full /Demo
5. Resize the window.
6. Close the window when desired.
7. You should see output similar to first valgrind output.
Is this the right forum to post this question on? I would make a pull request, but I was unsure if there was a standard procedure to follow.
Re: How to stop Cubism Harmonic Motion Controller
Hello @jeetmeister ,Hello again. Thank you for taking your time answering my question. As I don't really want to modify anything from the Live2D framework(to avoid risks), I found an alternate solution that I can use during runtime.
Thanks for using our products.
If you want to disable a feature of CubismHarmonicMotionController, uncheck the component of the feature in question from Inspector.
However, simply unchecking the checkbox will result in a sudden change in value.
How about multiplying the value applied by Harmonic Motion by Weight and smoothly switching the influence of CubismHarmonicMotionController by manipulating the value of Weight between 0.0f and 1.0f?
Below is a snippet with Weight added to CubismHarmonicMotionController:public float Weight = 1.0f; public void OnLateUpdate() { ... for (var i = 0; i < Sources.Length; ++i) { ... Destinations[i].BlendToValue(BlendMode, Sources[i].Evaluate() * Weight); } }Best regards.
I can simply modify the Channel Timescales of the Cubism Harmonic Motion Controller like this:
//assign value in inspector
public CubismHarmonicMotionController cubismHarmonicMotionController;
//index 0 contains Angle X and Angle Z
cubismHarmonicMotionController.ChannelTimescales[0] = 0f;
My Harmonic Motion Controller has three parameters(Angle X, Angle Z, Breath) and if I separate the breath parameter in a different channel it wouldn't be affected.
Thank you again and I hope this helps others in the future.
Re: Support loading remote ArtMesh files and parameters
@JekSun97
Thank you very much for your continued support and patronage of our products.
We have shared your request with our development team regarding the ability to save individual ArtMesh components along with their parameters, as well as the functionality to load them separately.
Thank you very much for your valuable feedback.
We look forward to your continued support.
Thank you very much for your continued support and patronage of our products.
We have shared your request with our development team regarding the ability to save individual ArtMesh components along with their parameters, as well as the functionality to load them separately.
Thank you very much for your valuable feedback.
We look forward to your continued support.
Re: Feature Request: Improved Automatic Layout in "Edit Texture Atlas"
Would very much like this improved as well - though the feature has been improved, it's still in a state where I often need to spend hours more carefully placing textures to maximize the available space.
Re: Feature Request: Make Parameter Settings Checkmarks Draggable
Hi @Tea_con
Thanks for using our products.
Your request has been shared with our development team.
Best regards.
Thanks for using our products.
Your request has been shared with our development team.
Best regards.
Re: Feature Request: Improved Automatic Layout in "Edit Texture Atlas"
Hi @Tea_con
Thanks for using our products.
Your request has been shared with our development team.
Best regards.
Thanks for using our products.
Your request has been shared with our development team.
Best regards.
Re: Modifying Physics output scale in unity
Hello @jeetmeister ,
Thank you for always using our products.
How about switching the physics settings using one of the following methods?
- Prepare each .physics3.json file and pass the necessary one to CubismPhysicsController.Initialize().
- Make CubismPhysicsController.Rig access modifiers public and manipulate the Rig values directly.
Best regards.
Thank you for always using our products.
How about switching the physics settings using one of the following methods?
- Prepare each .physics3.json file and pass the necessary one to CubismPhysicsController.Initialize().
- Make CubismPhysicsController.Rig access modifiers public and manipulate the Rig values directly.
Best regards.
Re: Needing help at increasing the RAM limit of Live2d.
@Katomon
Oh, thanks for pointing that out.
Oh, thanks for pointing that out.
Re: Needing help at increasing the RAM limit of Live2d.
Obsidian: on taht same page it says "Note: The following settings are no longer required due to the new “Optimize Java memory allocation for editors” feature implemented in Cubism Editor 3.1.
However, if you wish to control memory usage yourself, please configure the following settings."
Yolk, that amount is the one in use and allocated, it grows by itself depending on the model, and the amount of art, are you sure is not laggy because you are having glue or bugged artmeshes ? (On the log should show a lot of red, that lags a lot the program)
However, if you wish to control memory usage yourself, please configure the following settings."
Yolk, that amount is the one in use and allocated, it grows by itself depending on the model, and the amount of art, are you sure is not laggy because you are having glue or bugged artmeshes ? (On the log should show a lot of red, that lags a lot the program)
