Aha, that has narrowed it down! I’m currently making a check to see if the attached object has physics enabled and skip constraint solving if it doesn’t because my initial assumption was that it’d remain still. I’ll get this fixed in the upcoming patch. Thank you, TeddyJeez!
Some initial performance metrics on the Switch from my own benchmark which tests the raw simulation performance. The Switch was running in handheld mode. This does not include the overhead of Physx Queries. Each run does 2000 frames and averages the results. All runs are done with the simulation targeting 60 fps, with 3 substeps and 8 constraint iterations every substep.
Single-threaded results:
1K Particles with 1.7K Constraints with Particle-Particle collision disabled:
Starting Simulation...
Particle Count: 1000
Simulation finished! Results in MS over the total simulated frames [Total, Avg]
Simulation: 2798.35, 1.39917
Velocity: 171.708, 0.085854
Constraints: 2370.9, 1.18545, {0.0370454 <- (this is per constraint iteration)}
Correction: 250.065, 0.125033
Collision: 0.733, 0.0003665
Particle Count: 1000
Constraint Count: 1700
1.3997ms
1K Particles with 1.7K Constraints with Particle-Particle collision enabled:
Starting Simulation...
Particle Count: 1000
Simulation finished! Results in MS over the total simulated frames [Total, Avg]
Simulation: 4864.13, 2.43207
Velocity: 175.004, 0.087502
Constraints: 2392.74, 1.19637, {0.0373865 <- (this is per constraint iteration)}
Correction: 260.138, 0.130069
Collision: 1193.01, 0.596507
BroadPhase: 1185.71, 0.592853
NarrowPhase: 5.624, 0.002812
Collision Spatial Hash Reset: 837.554, 0.418777
Particle Count: 1000
Constraint Count: 1700
2.43207ms
With this many Particles, the multi-threaded version is actually a bit slower due to the overhead outweighing the gains. So we’ll push the Particle/Constraint count up to the limit for a pure 60fps simulation. We can run 4.5K Particles with 8.7K Constraints with Collision enabled at just under 16.6ms.
4.5K Particles with 8.7K Constraints with Particle-Particle collision disabled:
Starting Simulation...
Particle Count: 4500
Simulation finished! Results in MS over the total simulated frames [Total, Avg]
Simulation: 20384.1, 10.1921
Velocity: 1124.85, 0.562426
Constraints: 17299.3, 8.64965, {0.270301}
Correction: 1951.94, 0.975971
Collision: 0.791, 0.0003955
BroadPhase: 0, 0
NarrowPhase: 0, 0
Collision Spatial Hash Reset: 0, 0
Particle Count: 4500
Constraint Count: 8700
10.1921ms
4.5K Particles with 8.7K Constraints with Particle-Particle collision enabled:
Starting Simulation...
Particle Count: 4500
Simulation finished! Results in MS over the total simulated frames [Total, Avg]
Simulation: 32506.9, 16.2535
Velocity: 1407.53, 0.703765
Constraints: 17412.9, 8.70643, {0.272076}
Correction: 2307.16, 1.15358
Collision: 7144.02, 3.57201
BroadPhase: 7084.11, 3.54206
NarrowPhase: 57.246, 0.028623
Collision Spatial Hash Reset: 4225.61, 2.1128
Particle Count: 4500
Constraint Count: 8700
16.2535ms
And now the same tests with multi-threading (3 threads):
4.5K Particles with 8.7K Constraints with Particle-Particle collision disabled:
Starting Simulation...
Particle Count: 4500
Simulation finished! Results in MS over the total simulated frames [Total, Avg]
Simulation: 16053.9, 8.02697
Velocity: 1172.67, 0.586336
Constraints: 13104.7, 6.55233, 0.20476
Correction: 1766.53, 0.883264
Collision: 1.708, 0.000854
BroadPhase: 0, 0
NarrowPhase: 0, 0
Collision Spatial Hash Reset: 0, 0
Particle Count: 4500
Constraint Count: 8700
8.02697ms
4.5K Particles with 8.7K Constraints with Particle-Particle collision enabled:
Starting Simulation...
Particle Count: 4500
Simulation finished! Results in MS over the total simulated frames [Total, Avg]
Simulation: 29782.4, 14.8912
Velocity: 1435.92, 0.717961
Constraints: 13530.6, 6.7653, 0.211416
Correction: 2052.56, 1.02628
Collision: 9747.79, 4.8739
BroadPhase: 9730.95, 4.86548
NarrowPhase: 12.78, 0.00639
Collision Spatial Hash Reset: 3005.47, 1.50273
Particle Count: 4500
Constraint Count: 8700
14.8912ms
Multi-threaded version is ~9-21% (Collision lowers the difference) faster than single-threaded which is not very much at all due to the overhead of multi-threading. The benefits are really seen once you start using tens of thousands of particles/constraints. Nevertheless, the support is in the library for the Switch 
Overall, I’m very impressed as it stands! And the next tests will be done with PhysX from within my UE4 test project, stay tuned for those!
PS: Switch support will be merged into the main branch on GitHub next week
Hey there, sorry if this has already been asked, but in consideration for purchasing this product, I’m wondering if it would be possible to use the spline path-rope function to have a pawn with a skeletal mesh move up along a rope for a climbing function?
Cheers!
Absolutely! That is the way I recommend to setup any sort of climbing or traversing of Ropes/Cables. You can even ‘fake’ weight transfer, if traversing, by changing the Particle mass as the pawn goes across them giving the feel of a heavy object moving along the rope/cable.
Thank you so much for your answer, that’s absolutely wonderful. I’ll be making the purchase next week, I look forward to utilizing this awesome plugin.
Cheers!
Hey. Can I use your program for this purpose? You have to grasp from the bobbin the edge of the fabric(cloth or tape) with the mouse (about a meter width) and unwind the part (about 4 meters).Than you have to catch wrapped part of the mouse by the edge and drag through the sticks (with sticks there must be a collision, the sticks are perpendicular to the direction of dragging the fabric, the fabric lies on the sticks) and attach the edge to anything. And all this must be in the game mode(realtime).
Good work !
Hello! I have a question, how to make a rope not stretchable?
I have to think of a reason to use this, it’s too awesome.
edit: I have one. If I make a naval mine and have it bob around in the water, can the chain attached (to the bottom of the ocean) react accordingly with this plugin?
Hello , I replied to your question in the Marketplace page a little while ago, did you not see it? I’ll post it here as well, just in case:
Hi , the biggest issue with this use-case is the wound up cloth and the rollers holding the cloth.
This is a very complex collision interaction and I do not believe you'll get decent enough results with VICO Dynamics.
But the other use-cases you listed should work pretty well, I think.
Hope that helps.
Hi TeddyJeez,
Short answer is, no. The long answer is, sort-of. The system is elastic at its core, hence being a soft-body system. There is no way, currently, to make a fully rigid rope/cloth. But you can reduce the stretchiness at the cost of performance. Go into Project Settings -> VICO Dynamics and change the Simulation Iterations to a higher number, try 5 or 8 or higher if your performance allows. This will tighten up the solver results a good bit.
Hi duke22,
Thank you for the kind words!
The problem with chains is that they are not elastic and, as I mentioned above to TeddyJeez, the core solver in my plugin is built around elasticity. But you can get results that are closer to being rigid by increasing the Simulation Iterations setting at the cost of performance.
Hope that helps.
Thanks, I’ll try)
A quick update on the Switch testing in UE4: finally had a little bit of time to setup and start testing, first test was a simple 20 particle rope with 38 constraints, particle collision **and ** PhysX collision enabled:
Total per-frame was .35ms with PhysX collision taking over half that time at .2ms
Particle collision took .12ms
And the actual solver took ~.025ms
More soon with screenshots!
A screenshot straight off the Switch! This is with the same settings as above, but with 111 Particles and 359 Constraints with 3 sub-steps and 8 Constraint Iterations per sub-step.
The stats on the left are:
Sim - Total simulation time
Vel - Velocity solver time
Con - Constraint solver time
PCol - Particle collision resolution time
RCol - PhysX Rigid Body collision resolution time
As you can see, the bottleneck is, unfortunately, the PhysX Scene Query interface…
Would this work with instanced static mesh? I want to be able to do this:
As far as having the Instanced static meshes attached to the rope? That is a great question! I’ll have to test and see if it’s as simple as attaching each instance to a socket on a rope or if manual location updating will be required.
No I mean can an instanced static mesh BE a rope? Or does it have to be a skeletal mesh with bones?
Oh, I see. Currently, there isn’t a way to use instanced meshes as the rope. But I’ll certainly look into that!
The mesh can either be generated, if you are fine with using a cylindrical mesh. Or a skeletal mesh with bones, if you’d like to use a custom mesh
Ok great, thanks for the info!