Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Bug / Crash  Strange errors after import (clear project) and questions about perfomance
#1
Hello. I'm using Unity3d 2017.3.0f3 (a9f86dcd79df)

After importing, I get such warnings and errors:
Code:
Assets/Obi/Editor/ObiParticleActorEditor.cs(161,22): warning CS0618: `UnityEditor.EditorApplication.playmodeStateChanged' is obsolete: `Use EditorApplication.playModeStateChanged and/or EditorApplication.pauseStateChanged'
Assets/Obi/Editor/ObiTetherConstraintsEditor.cs(18,23): warning CS0649: Field `Obi.ObiTetherConstraintsEditor.tetherType' is never assigned to, and will always have its default value `0'
DllNotFoundException: libOni
Obi.ObiCollisionMaterial.OnValidate () (at Assets/Obi/Scripts/Collisions/ObiCollisionMaterial.cs:44)
DllNotFoundException: libOni
Obi.ObiCollisionMaterial.OnEnable () (at Assets/Obi/Scripts/Collisions/ObiCollisionMaterial.cs:27)
DllNotFoundException: libOni
Obi.ObiMeshTopology.OnEnable () (at Assets/Obi/Scripts/DataStructures/ObiMeshTopology.cs:122)
DllNotFoundException: libOni
Obi.ObiTriangleSkinMap.OnEnable () (at Assets/Obi/Scripts/DataStructures/ObiTriangleSkinMap.cs:121)
DllNotFoundException: libOni
Obi.ObiDistanceField.OnEnable () (at Assets/Obi/Scripts/Collisions/ObiDistanceField.cs:54)
This is okay?
These "DllNotFoundException: libOni" there are 256.


Physics works but not as efficiently as we would like.
I checked on intel i3, Clothstaticmeshcollider demo gives out 400-500ms for CPU.
What processor do you use?
Is the loss of performance related to the errors above?
At the same time, the Benchmark demo gives ~12ms.
Are there any best practices for better performance?

Thanks.
Reply
#2
(12-04-2018, 04:16 PM)NightFox Wrote: Hello. I'm using Unity3d 2017.3.0f3 (a9f86dcd79df)

After importing, I get such warnings and errors:
Code:
Assets/Obi/Editor/ObiParticleActorEditor.cs(161,22): warning CS0618: `UnityEditor.EditorApplication.playmodeStateChanged' is obsolete: `Use EditorApplication.playModeStateChanged and/or EditorApplication.pauseStateChanged'
Assets/Obi/Editor/ObiTetherConstraintsEditor.cs(18,23): warning CS0649: Field `Obi.ObiTetherConstraintsEditor.tetherType' is never assigned to, and will always have its default value `0'
DllNotFoundException: libOni
Obi.ObiCollisionMaterial.OnValidate () (at Assets/Obi/Scripts/Collisions/ObiCollisionMaterial.cs:44)
DllNotFoundException: libOni
Obi.ObiCollisionMaterial.OnEnable () (at Assets/Obi/Scripts/Collisions/ObiCollisionMaterial.cs:27)
DllNotFoundException: libOni
Obi.ObiMeshTopology.OnEnable () (at Assets/Obi/Scripts/DataStructures/ObiMeshTopology.cs:122)
DllNotFoundException: libOni
Obi.ObiTriangleSkinMap.OnEnable () (at Assets/Obi/Scripts/DataStructures/ObiTriangleSkinMap.cs:121)
DllNotFoundException: libOni
Obi.ObiDistanceField.OnEnable () (at Assets/Obi/Scripts/Collisions/ObiDistanceField.cs:54)
This is okay?
These "DllNotFoundException: libOni" there are 256.


Physics works but not as efficiently as we would like.
I checked on intel i3, Clothstaticmeshcollider demo gives out 400-500ms for CPU.
What processor do you use?
Is the loss of performance related to the errors above?
Are there any best practices for better performance?

Thanks.

Hi there,

When importing a package, Unity sometimes fails to hot-load new native plugins, and that results in the error you describe. Simply restart Unity and it should be fine.

Regarding performance, this video might be of interest:
https://www.youtube.com/watch?v=sUVqa-72-Ms

Death spiralling is a very common issue when working with demanding physics. It is of critical importance for you to understand how physics work in Unity (fixed-timestep) and how to tune timestep parameters in order to work with Obi (and pretty much any other physics engine).
Reply
#3
(12-04-2018, 04:23 PM)josemendez Wrote: Hi there,

When importing a package, Unity sometimes fails to hot-load new native plugins, and that results in the error you describe. Simply restart Unity and it should be fine.

Regarding performance, this video might be of interest:
https://www.youtube.com/watch?v=sUVqa-72-Ms

Death spiralling is a very common issue when working with demanding physics. It is of critical importance for you to understand how physics work in Unity (fixed-timestep) and how to tune timestep parameters in order to work with Obi (and pretty much any other physics engine).

Thanks for the answer.

I've tried switching to late update but this leads to worse visual results. 
[Image: Cloth_Static_Mesh_Collider_late_update.png]

In the intercollisions demo at lateupdate these physics artifacts are not noticeable, but I found a problem that physics consumes CPU even when the bodies are not moving/at rest.
[Image: Intercollisions_late_update.png]

Can these problems be solved somehow? or are there workarounds?
Reply
#4
(12-04-2018, 04:48 PM)NightFox Wrote: Thanks for the answer.

I've tried switching to late update but this leads to worse visual results. 
[Image: Cloth_Static_Mesh_Collider_late_update.png]

In the intercollisions demo at lateupdate these physics artifacts are not noticeable, but I found a problem that physics consumes CPU even when the bodies are not moving/at rest.
[Image: Intercollisions_late_update.png]

Can these problems be solved somehow? or are there workarounds?

Hi,

Using LateUpdate is not always an ideal solution, as it causes cloth to be updated using a variable timestep. This is generally not noticeable for characters, fast moving clothing, or clothing that does not interact with other objects and can be regarded as a visual embellishment (as explained in the video). You should reduce Unity's max fixed timestep instead.

Also, please note that performance of Unity games running inside the editor is generally much worse than in a standalone build.

Solvers can stop updating the simulation when not visible. To do this, simply uncheck the "Simulate when invisible" option in ObiSolver. However, only entire solvers (not individual cloth pieces) can be culled. If you don't plan on having cloth pieces collide with each other, this is not an issue as you can use a separate solver for each cloth.

Resting cloth pieces still have to be updated. You could deactivate the cloth when its kinetic energy gets below a threshold (get particle velocities and calculate their weighted mean), then reactivate it when the user interacts with it, or when any other condition is met.
Reply
#5
(12-04-2018, 05:38 PM)josemendez Wrote: Hi,

Using LateUpdate is not always an ideal solution, as it causes cloth to be updated using a variable timestep. This is generally not noticeable for characters, fast moving clothing, or clothing that does not interact with other objects and can be regarded as a visual embellishment (as explained in the video). You should reduce Unity's max fixed timestep instead.

Also, please note that performance of Unity games running inside the editor is generally much worse than in a standalone build.

Solvers can stop updating the simulation when not visible. To do this, simply uncheck the "Simulate when invisible" option in ObiSolver. However, only entire solvers (not individual cloth pieces) can be culled. If you don't plan on having cloth pieces collide with each other, this is not an issue as you can use a separate solver for each cloth.

Resting cloth pieces still have to be updated. You could deactivate the cloth when its kinetic energy gets below a threshold (get particle velocities and calculate their weighted mean), then reactivate it when the user interacts with it, or when any other condition is met.

Okay, thanks!

I'm reduce Unity's max fixed timestep instead and get the same as LateUpdate (ClothStaticMeshCollider demo).

However, on the Intercollisions demo I noticed a difference.
With late update I get physics glitches (when "Simulate when invisible" is disabled and I turn the camera), but with FixedUpdate there is no problem (with similar performance). May be someone will be useful.

Quote:You could deactivate the cloth when its kinetic energy gets below a threshold (get particle velocities and calculate their weighted mean), then reactivate it when the user interacts with it, or when any other condition is met.
Are there any script examples? What functions/api should I call?

(12-04-2018, 06:54 PM)NightFox Wrote: I'm reduce Unity's max fixed timestep instead and get the same as LateUpdate (ClothStaticMeshCollider demo).

I was able to reduce artifacts change settings:
1. for solver: Damping 0.5, Particle Collision Iterations 9 (parallel mode) Relaxation 1
2. for cloth: Distance Constraints Slack 0.3
I think we can finding compromise without a significant loss of performance (sacrificing some plausibility).
Reply
#6
(12-04-2018, 06:54 PM)NightFox Wrote: Okay, thanks!

I'm reduce Unity's max fixed timestep instead and get the same as LateUpdate (ClothStaticMeshCollider demo).

However, on the Intercollisions demo I noticed a difference.
With late update I get physics glitches (when "Simulate when invisible" is disabled and I turn the camera), but with FixedUpdate there is no problem (with similar performance). May be someone will be useful.

Are there any script examples? What functions/api should I call?


I was able to reduce artifacts change settings:
1. for solver: Damping 0.5, Particle Collision Iterations 9 (parallel mode) Relaxation 1
2. for cloth: Distance Constraints Slack 0.3
I think we can finding compromise without a significant loss of performance (sacrificing some plausibility).

When using LateUpdate and turning the camera away then back to the cloth, the use of variable timestep causes the first timestep to be too long (since a long time has passed since the last update, when the solver was visible).

This cannot be avoided in the general case, as it is inherent to using LateUpdate to update physics, which should never be done without a good reason anyway as the results are highly unphysical (refer to the official Unity docs for more info on why physics belong in FixedUpdate). As a hack, you could clamp the timestep to a maximum value (I will post the modification if you need it). Physics should always be updated in FixedUpdate, if you do otherwise make sure you know why you're doing it. The LateUpdate mode is provided only for edge cases and special uses.

Regarding the API for getting/setting particle properties and code snippets, take a look at the docs:
http://obi.virtualmethodstudio.com/tutor...icles.html
Reply
#7
(12-04-2018, 08:20 PM)josemendez Wrote: When using LateUpdate and turning the camera away then back to the cloth, the use of variable timestep causes the first timestep to be too long (since a long time has passed since the last update, when the solver was visible).

This cannot be avoided in the general case, as it is inherent to using LateUpdate to update physics, which should never be done without a good reason anyway as the results are highly unphysical (refer to the official Unity docs for more info on why physics belong in FixedUpdate). As a hack, you could clamp the timestep to a maximum value (I will post the modification if you need it). Physics should always be updated in FixedUpdate, if you do otherwise make sure you know why you're doing it. The LateUpdate mode is provided only for edge cases and special uses.

Regarding the API for getting/setting particle properties and code snippets, take a look at the docs:
http://obi.virtualmethodstudio.com/tutor...icles.html

Thanks for supporting.
At the moment, I'm trying to understand the tool and get used to it.
I have realized that it should be use is limited and minimize the number of simultaneously working clothes.
And LateUpdate is more suitable for the character who is always in the frame or for objects that must always be simulated.
Reply