[RELEASED] MagicaCloth2 - Hybrid Cloth Simulation

I don't have sub-meshes. My use case is that I have a large and complex mesh, but only a small part need MagicaCloth. Since the paint vertex texture is only 128x128, it's impossible to properly paint that small part with it. The resolution is just not enough.

So I'd like to make a second UV set (TEXTCOORD1) where the small part takes the whole uv space and other vertices at (0, 0).

I actually made it work by modifying the source code. I added a uv1 field to VirtualMesh, collected uv data like you did, and an option to toggle between uv and uv1. But of course it's hacky and I will have to merge the code myself when you release a newer version of MagicaCloth...

Another potential solution to this is to allow a big paint vertex texture, not limiting it to 128x128. Since you've already planned to make the bake feature, a large texture won't be an issue once the user can just sample it in editor and bake the attributes onto vertices, without affecting runtime performance.

I don't think it's a problem that users need to use a modeling tool. The bigger potential problem is that vertex color is a "scarce resource", cause one vertex can have only one color. The end user might already been using vertex color for a completely unrelated purpose (e.g. red channel as outline width for a GGST-like anime shader), and there will be a conflict. I'm not so sure if it's a good idea to "spend" this resource on painting vertex attributes.

Maybe it should use only 1 channel. Instead of red means fixed and green means movable, make it like red channel = 0 means fixed and red channel = 1/256 means movable, to mitigate the impact.

But to be honest, what I really wish to have is the ability to control mesh reduction with texutre and/or vertex color. e.g. higher red channel value is, the less likely a vertex to be reduced, and red = 1 means it's never reduced and always present in the proxy mesh... something like that.

 

Thank you for your feedback.
I think the underlying problem is that the maximum size of the paint texture is limited to 128x128.
If this is released from 512 to 1024, various problems will be solved.
This limitation is simply due to the fact that fetching texture images is expensive and can only be done on the main thread.
However, there is also a way to get pixels on the GPU by using GPU + ComputeBuffer, so I would like to reconsider whether this problem can be solved flexibly at a later date.

 

Update:2.2.0

v2.2.0 has been released on the Asset Store!
https://u3d.as/2Zc3

Inertia can now be separated into two parts, world and local, and adjusted separately.
World inertia corresponds to the movement of the character itself, and local inertia corresponds to animation movement.
You can now configure auto-teleport detection and reset/maintain after teleporting.
https://magicasoft.jp/en/mc2_magicacloth_inertia/


Added a mode that can change the rotation center of the capsule collider to the starting point transform.
https://magicasoft.jp/en/mc2_capsulecollidercomponent/


Release Note:
Added: Added a mode to change the rotation center of the capsule collider to the starting point Transform.
Added: Added teleport behavior settings to the [Inertia] panel. You can choose to automatically detect teleports and reset the simulation or keep it as is.
Added: Added mode to keep simulation to ResetCloth() API. This is useful for teleporting while maintaining posture.
Improvement: Inertia settings separated into two parts: world inertia and local inertia. World inertia corresponds to the movement of the entire character, while local inertia corresponds to the movement of the cloth inside the character. This also makes it possible to completely eliminate the effects of character movement.
Improvement: Inertia parameter "Movement Inertia" changed to "World Inertia".
Improvement: The inertia parameter "Rotation Inertia" has been removed.
Improvement: "Movement Speed Limit" in inertia parameter changed to "World Movement Speed Limit".
Improvement: "Rotation Speed Limit" in inertia parameter changed to "World Rotation Speed Limit".
Improvement: Fixed the problem that the accuracy of the internal time drops when running for a long time.
Improvement: Readjusted UnityChanKAGURA due to inertia specification change.
Fix: Fixed a rare issue where triangles would point in the wrong direction when reflecting from a proxy mesh to a render mesh.
Fix: Fixed an issue where moving wind did not include scale effects.

How to Update
Please follow the following steps to update the software as much as possible.

(1)Backup your project
(2)Delete the MagicaCloth2 folder from the Unity editor
(3)Import the latest MagicaCloth2 from PackageManager

 

@hoshos Is there no way to get MagicaCloth2 to work on WebGL?

 

Hello.
Unfortunately it doesn't work with WebGL.
To be precise, it works without errors, but DOTS multithreading does not work.
Everything will work in single thread.
Therefore, the processing is very heavy and not practical.
In the future, when DOTS runs multi-threaded with WebGL, MagicaCloth will automatically work smoothly.
Please understand that this is a Unity engine issue, not MagicaCloth.

 

@hoshos I only need 1 simple piece of cloth to be simulated so single-threaded could still work for me. However, when I make a WebGL build, the cloth doesn’t move at all. Is there something I need to enable/disable in MagicaCloth2 to get it to run single-threaded on WebGL?

 

Hello, I am building a dress up system with Magica cloth 2. My dress has extra "skirt" bones that the humanoid doesn't have.
I followed the example you give. In you example the humanoid skeleton contains all skirt and hair bones. So I made a little change by porting the extra "skirt" bones to the humanoid skeleton manually.
The problem is that, The magica cloth simulation vertices all become black "invalid" after cloth.BuildAndRun();
If I commented out the following lines of code from the example, the simulation will go normally.

Code (CSharp):

1.  
2.  
3.         // First stop the automatic build that is executed with Start().
4.         // And just in case, it does some initialization called Awake().
5.         foreach (var cloth in clothList)
6.         {
7.             // Normally it is called with Awake(), but if the component is disabled, it will not be executed, so call it manually.
8.             // Ignored if already run with Awake().
9.             cloth.Initialize();
10.  
11.             // Turn off auto-build on Start().
12.             //cloth.DisableAutoBuild();
13.         }
14.      
15.      
16.        // Finally let's start building the cloth component.
17.        foreach (var cloth in clothList)
18.        {
19.             // I disabled the automatic build, so I build it manually.
20.             //cloth.BuildAndRun();
21.  
22.        }

I don't know what happen and why. Why the vertices goes black after build and run? It returns true so I guess the build is sucessful.

 

I tested it with WebGL a few years ago and it worked then.
However, it seems that it stopped working with WebGL for some reason over the years.
You probably need to find out the cause and fix it.
However, there are no plans to modify MagicaCloth until Unity's DOTS officially supports WebGL.
I'm sorry, but please understand.

 

Hello.
I don't understand why commenting out DisableAutoBuild() and BuildAndRun() works fine.
Maybe it's some kind of special situation.
Can you provide a project where we can confirm this issue?
This may not be apparent without examining the source code and prefab configuration.

If possible, could you send me a DM on this forum?
You can DM me by clicking on my account and selecting "Start a Conversation".

 

2.2.0 teleport feature works very well. tysm!
Can't wait for MagicaSpringBone-
SpringBone currently in use still goes wild when teleporting

 

Hello.
I'm glad to hear that the teleport function seems to be working well.
BoneSpring/MeshSpring will start development soon.
I'm currently creating a camera culling system, so that's the next plan.
If all goes well, BoneSpring will be released in September.

 

Is there a way to disable the culling or change what it uses as a reference?

 

Hello.
I think it's probably a phenomenon that the mesh disappears when it moves a lot, so I'll explain that problem.

This is due to Unity's drawing culling system and has nothing to do with MagicaCloth.
First, the Renderer has a bounding box around its own Transform.
It's the white-lined box in the image, defined as "Bounds" in the inspector.
The Renderer stops drawing when the white box disappears from the camera.
(Actually, the effects of shadows etc. are also included)



And this bounding box is basically fixed to the body.
It does not move with the mesh.
In other words, whether or not to draw depends on whether or not the bounding box is visible to the camera, and the vertex coordinates of the current mesh are irrelevant.
Therefore, drawing stops when the bounding box of the main body disappears from the camera as in the video.

There are two ways to work around this issue.

(1) Enlarge the bounding box in advance
"Bounds" is editable, so enlarge the box in advance with the inspector.
With this, drawing will not stop unless the meshes are far apart.

(2) Update When Offscreen
Another is to enable "UpdateWhenOffscreen".
Enabling this flag causes the bounding box to be recalculated to match the shape of the mesh.
This will eliminate problems like this one.
However, recalculation is slightly more computationally expensive.

See the Unity manual for details on each.

 

I hope there is a way to store paint vertex attributes by vertex index, or automatically assign the attributes by depth at runtime. Storing them by position in 3D seems not very robust (e.g. if I adjust the bone positions later in 3D modeling tool). Bone Cloth doesn't support a paint vertex texture so it's even more troublesome.

 

Hi. I use your plugin. I copied MagicaCloth Component from your example and applied to my mesh but I have some trouble. As you can see in the video the mesh of the model is gone trought MagicaCapsuleCollider. I don`t understand what I need to do. Also I added screenshots of the settings of the components. Thank you for helping

 

Recording by vertex index is quite unstable.
The index can easily collapse if the mesh vertices are increased or decreased, or if the import settings are changed slightly.
It can also be broken just by changing the Unity version.
In fact, in Ver1.x, it is recorded by vertex index, but it was so broken that we changed it to record by coordinates this time.

The method of assigning by depth is interesting, but first the fixed attribute must be painted to determine the depth.
In other words, the depth information cannot be generated without painting.

 

Hello.
As long as you watch the video, it seems that the collider is not responding properly.
However, as far as I can see the inspector, there seems to be no problem with the settings.
First of all, if the character is moved slowly, is the collision detected correctly?
Does the problem occur only when moving at high speed like this time?

 

Hi. Yes, it does but less than a fast moving.

 

I fully understand and I agree that recording them by vertex index for Mesh Cloth is a bad idea. But I don't see why it's a problem for Bone Cloth.

- I don't think artists change the number of bones more than they change the position of bones, so it's not more unstable than the current system.
- Do Bone Cloth's depth values really need to rely on attribute painting? I think root bones = 0 is a reasonably assumption.

 

Thank you for the video.
It seems that the collider collision detection is not working.
Since the collision mode is "Edge" and the thickness is 0.02, there seems to be no problem with the settings.
Just to confirm, is the collider component disabled during execution?

 

Hello.
Ultimately, both specifications have advantages and disadvantages.
I can't say that one is definitely better than the other.
I decided to record the coordinates from my two years of development experience with Ver1.x.
This is because many end users complained about being recorded in the index.
Therefore, we have no plans to change this policy anytime soon.

However, I receive many inquiries every day.
We record the requests of those end users.
Therefore, if many end users are dissatisfied with the current storage method, I would like to consider improvements.
However, now is not the time.

 

No, isn`t. The collider is enabled

 

MagicaCloth's collider detection is not perfect, but it is somewhat reliable.
However, no system is perfect and problems such as tunneling may occur if particles move at high speed.
However, in this example, it seems that the collider does not react even if you move it slowly.
This may be missing or defective.

So I have a request.
Can you provide a project that can reproduce this issue?
If possible, please send me a DM from my account.

 

It`s my bad. I didn`t see the script MagicaSettings in a scene. I remove it and clothes works cool. Thank you for helping

 

I'm relieved that the problem seems to have been resolved.
Maybe it's because MaxSimulationCount is 1.
Default is 90-3.
However, even if it is 1, it should still function reasonably well, but it was unexpected that the collision detection would be so weak.
I'll try checking again later.

There are ways to make collision detection even more robust.
It is called a backstop and strongly prevents particles from turning to the back side.
If you are interested, please refer to the following documentation:

https://magicasoft.jp/en/mc2_backstop_setup/

 

Understood. I actually hacked the source a little bit to add an option to always use the root bones as fixed vertices.

This way there is no need to change how the painted attributes are stored (I'm not confident to make such fundamental change over the codebase anyway). Just an "auto" option that overrides "manual" paint.

It's quite limited (just a boolean option), but at least it's no longer a showstopper for me. Of course it'd be even better if it's officially support.

 

I would like to confirm one thing.
Is it the attribute paint settings when editing that you are struggling with?
Or does it mean that it is difficult to set the vertex attributes of BoneCloth when generating it at runtime?

 

My case might be rather unusual because I have a custom animation system that allows me to test character's animation/pose in editor mode (based on Animancer's SoloAnimation, a third-party package) So my character isn't always at T-pose in edit mode.

I'm not sure where exactly the problem is, but when I change the character's pose in edit mode it breaks the painted attributes, even I change it back to T-pose later. Perhaps it's my own fault or I messed up something... but make the BoneCloth's selection(attribute) be decided at runtime seems to work well for me.

 

Thank you for your quick reply.
I understand the general situation.
Changing poses frequently during editing is certainly unexpected.
This is because it is designed on the assumption that the pose will not be changed when editing.
I will record this issue as a request.

 

Hello there. So I seem to have a weird Issue that makes no sense to me at the moment.
Probably not Magicas fault but it only happens with Magica at the moment.
So inside the Editor everything works perfectly.
But in the build the components are lost.
Using the compiled asset packages in unity to start the project works. The components are there.
But the Icons are like So I am unsure what happened.

 

Hello.
First of all, I would like to hear more about this strange inspector display.
Does this inspector error display always occur in the editor environment?
Please let me know in detail under what conditions it will be displayed like this.
Also, is it only the CapculeCollider that looks strange, or all Magica components?

 

All Magica components.
In editor with the non compiled packages it all looks fine.
No issues and it works.
In editor with compiled packages from the build it looks like this. All Magica components seem to miss their Icon but are there. And Magica still works.
Inside the build. All Magica components are missing from the game objects. And no more cloth.
I am still trouble shooting this but Priorities changed so will continue this later.

 

Sorry, I don't understand the situation.
Is the build you're talking about different from a build that creates a normal exe(windows) or apk(android) file?
What does building a package mean?

 

Hey, we're getting a huge GPU performance increase with Magica enabled and can't figure out why

In the image - the first area where PostLateUpdate.UpdateAllSkinnedMeshes takes 27ms

For some reason Magica is the cause of that huge UpdateAllSkinnedMeshes update - once all Magica components are toggled off, that cost goes away (the area further right in the image where performance is 3x better)

Any idea what could be happening here?

 

Solved it (maybe), not really a Magica thing but more of a profiler/GPU skinning issue. The high performance seems to happen because of having GPU skinning enabled in player settings

And that's either really increasing the performance, or maybe the profiler is inaccurate in saying it has a large impact (in the image deep profiling is turned on which exacerbates it, but even with it turned off there's a decent hit). Hoping it'll be solved/profiled more accurately in builds

 

Hello.
I too have been puzzled by this GPU profiler, but apparently these numbers are not accurate.
The actual GPUSkinning time is correct to look at the timeline of the CPU item.



Perhaps GPUSkinning is executed across frames, which may be the reason for this figure.
In other words, it's not a bug.
You may not agree with this answer, but this is my view.

I will also include a hint about skinning. Please refer to it.

• In my experience, GPU skinning improves performance when enabled.
  
• It is better to look at the CPU timeline for the exact profile values.
  
• GPU profiling itself incurs overhead.
  
• Deep profilers themselves can be overloaded, so be careful. This is not a good way to measure performance.
  
• Note that SkinnedMeshRenderer's UpdateWhenOffscreen is enabled increases the load on the skinning process.

Finally, this is a Unity skinning system issue unrelated to MagicaCloth.

 

Update:2.3.0

v2.3.0 has been released on the Asset Store!
https://u3d.as/2Zc3

Added camera culling system.
It is possible to improve performance by stopping the simulation of characters that are not visible to the camera.
This feature greatly improves performance in first-person FPS and VR.

For information on culling, please refer to the following documentation:
https://magicasoft.jp/en/mc2_magicacloth_culling/

Additionally, the number of collider that can be used in one component has been expanded from 32 to unlimited.


Release Note:
Added: Added camera culling mode. When it disappears from the camera, the simulation stops and performance improves. It can be set from the "Culling" panel.
Improvement: The number of colliders that can be used in one MagicaCloth component has been expanded from 32 to unlimited.
Improvement: Improved main thread handling. Improves performance.
Improvement: The profiler now shows the processing of the main thread.

How to Update
Please follow the following steps to update the software as much as possible.

(1)Backup your project
(2)Delete the MagicaCloth2 folder from the Unity editor
(3)Import the latest MagicaCloth2 from PackageManager

 

Hope to do Spring first, this function is very useful, will be good for sales

 

BoneSpring is scheduled to begin development this month.
Don't worry, we will definitely implement it!

 

It was a simple fix and had nothing to do with the plugin. It was stripped during the build process.
AlwaysLinkAssembly solved it. I just added it to MagicaCloth.cs and it was included in the build.

 

I understand the situation.
This means that the package was removed by the code stripping function because the MagicaCloth component was only included in the asset bundle.
This can usually be resolved by including MagicaClothV2 in link.xml.

However, I didn't know about the existence of the "AlwaysLinkAssembly" flag, and I think it's very useful.
I would like to include this flag in the next version.

 

Update:2.3.1

v2.3.1 has been released on the Asset Store!
https://u3d.as/2Zc3

This is mostly a bug-fixed version.
As an additional element, MAGICACLOTH2 definition is now automatically added to the project settings.


Release Note:
Added: MAGICACLOTH2 define definition is now automatically added to the project settings.
Improvement: Added AlwaysLinkAssembly attribute to the package. The code stripping feature will no longer exclude the MagicaCloth2 package when building.
Fix: Fixed an issue where adding a collider at runtime would cause an error in some situations.
Fix: Fixed an issue where vertex paint attributes were not reflected when manually calling BuildAndRun() on BoneCloth at runtime.

How to Update
Please follow the following steps to update the software as much as possible.
(1)Backup your project
(2)Delete the MagicaCloth2 folder from the Unity editor
(3)Import the latest MagicaCloth2 from PackageManager

 

@hoshos Hi. Latest MagicaClothV2 shows some script warnings on Unity 2023.1.13f1.

 

Hello, how can I sync wind with Unity Wind system?

 

Thank you for your advice.
I will fix it in the next version.
Please rest assured that this warning does not affect operation.

 

MagicaCloth2 does not have a function to synchronize with UnityWind.
However, you can freely change the properties of MagicaWindZone components from the script.
https://magicasoft.jp/en/mc2_api_windzone/

Therefore, you should be able to create your own converter from UnityWind.

 

Hello.
The content of the error has been analyzed.
This is probably caused by setting 16 or more Renderer to MeshCloth.
The maximum number of Renderers that can be configured is 15.
Sorry for not mentioning it in the documentation.

 

max 15? Can I modify it

 

I'll have to check, but it might be relatively easy to fix up to 31.
By the way, how many renderers do you currently have set?