Non-uniform particle distance

[chenji]

Hi,

Is there a way to get Non-uniform particle distance for a Obi Rope? My use case is a first-person fishing game. There's a very long fishing line (300m)。Considering both performance and the reality of physics simulation, I'm going to set the distance of each particle far more smaller than those away from person. Is it possible and how to do this? For example the closet 10 particles distance is 0.5m, the next 10 particles distance is 2m and others are 20m? Something similar like LOD.
If it's possible, a more challenge question is when I use cursor to change rope length, can the non-uniform distance requirement also be supported?
If it's not possible what's the recommended way to get performance increase given I don't care much about the simulation quality of the elements of the long Obi rope that are far away from the camera but I do for those close to camera?

[josemendez]

Hi,

Is there a way to get Non-uniform particle distance for a Obi Rope? My use case is a first-person fishing game. There's a very long fishing line (300m)。Considering both performance and the reality of physics simulation, I'm going to set the distance of each particle far more smaller than those away from person. Is it possible and how to do this? For example the closet 10 particles distance is 0.5m, the next 10 particles distance is 2m and others are 20m? Something similar like LOD.
If it's possible, a more challenge question is when I use cursor to change rope length, can the non-uniform distance requirement also be supported?
If it's not possible what's the recommended way to get performance increase given I don't care much about the simulation quality of the elements of the long Obi rope that are far away from the camera but I do for those close to camera?

Hi!

LOD-ing physics (particularly if they're involved in gameplay and not just eye candy) is generally not a good idea. The reason is that the discretization of an object, that is, how it's represented as a discrete collection of smaller pieces - particles, tetrahedra, triangles, etc- has a big impact on the behavior of said object.

Altering this discretization at runtime so that objects further away from the camera have less "pieces" will cause the object to behave differently, which may affect gameplay. Having gameplay depend on something as arbitrary as distance of the object to the camera is certainly not something you want.

A rope represented with less particles/segments would be shorter than one represented with more particles. It will also be stiffer (both bend and stretch) because less particles means forces propagate faster trough the rope. This can have all sorts of side effects.

Visuals on the other hand can benefit from LOD, since an object further away is smaller due to perspective and even if it looks different, the user is not likely to notice, and gameplay will not be affected. You can drive ObiPathSmoother's decimation parameter using distance to camera to get visual LOD easily, but this only works for entire ropes - not specific areas of a rope.

kind regards,

[chenji]

You can drive ObiPathSmoother's decimation parameter using distance to camera to get visual LOD easily, but this only works for entire ropes - not specific areas of a rope.

Thanks for reply! Can this support a curve value in the future to let us has more precise control over its visual performance? 

About physics LOD I know it's usually not a good idea but considering my specific case do you think its side effect matters? Actually it's a little different: I don't need change the distance every frame. In the mean time I thought I could just do this: using 3 ropes with different resolution that are stitched one by one. So will Obi Rope consider supporting something like this out of box with a simpler API, as a performance improvement method for cases like first-person fishing game?

[josemendez]

Thanks for reply! Can this support a curve value in the future to let us has more precise control over its visual performance? 

We will consider adding a per-control point "visual importance" value that modulates the measured curvature when decimating the rope mesh - so that areas with higher "visual importance" are less decimated, as if their curvature was artificially higher.

About physics LOD I know it's usually not a good idea but considering my specific case do you think its side effect matters?

Making the rope shorter means the user will be able to reel the rope in faster, and rod behavior will be considerably different since the mass of the attached rope is different.

In the mean time I thought I could just do this using 3 ropes with different resolution that are stitched one by one. So will Obi Rope consider supporting this out of box with a simpler API?

I highly doubt we'll add a fully fledged physics LOD system, as it's not a good idea in general and may only apply to very specific use cases. However we'll develop visual LOD further.

kind regards,

[chenji]

We will consider adding a per-control point "visual importance" value that modulates the measured curvature when decimating the rope mesh - so that areas with higher "visual importance" are less decimated, as if their curvature was artificially higher.


Making the rope shorter means the user will be able to reel the rope in faster, and rod behavior will be considerably different since the mass of the attached 


I highly doubt we'll add a fully fledged physics LOD system, as it's not a good idea in general and may only apply to very specific use cases. However we'll develop visual LOD further.

kind regards,

Thanks, that's fine!

[chenji]

Actually after testing the cursor function, I found it actually implements "Non-uniform particle distance" when the particle pool exhausted and the rope is still extending its length. But it may only increase length of one element.
Now my question is, what's the benefit of setting large particle pool size? Will I get a physically more tight rope without setting large pool size since particle number is less?

[josemendez]

Actually after testing the cursor function, I found it actually implements "Non-uniform particle distance" when the particle pool exhausted and the rope is still extending its length. But it may only increase length of one element.

Hi!

This can hardly be considered "non-uniform particle distance" the way you described it in this thread: inter-particle distance doesn't depend on any useful metric like distance to camera, rope curvature, etc and the rope isn't dynamically resampled. The cursor merely extends the length of the last element as a last resort when it can't create new ones because it has completely depleted the particle pool.

Now my question is, what's the benefit of setting large particle pool size? Will I get a physically more tight rope without setting large pool size since particle number is less?

A larger particle pool will allow you to have longer ropes without running into the need to extend the length of the last segment, which almost always gives weird results (as a single element can't bend, it is just a straight line. The ability to bend comes from having multiple, equally long elements). Ideally, ropes must have equal inter-particle distance for proper simulation, so it's in your best interest to have a sufficiently large pool.

kind regards

[chenji]

Hi!

This can hardly be considered "non-uniform particle distance" the way you described it in this thread: inter-particle distance doesn't depend on any useful metric like distance to camera, rope curvature, etc and the rope isn't dynamically resampled. The cursor merely extends the length of the last element as a last resort when it can't create new ones because it has completely depleted the particle pool.



A larger particle pool will allow you to have longer ropes without running into the need to extend the length of the last segment, which almost always gives weird results (as a single element can't bend, it is just a straight line. The ability to bend comes from having multiple, equally long elements). Ideally, ropes must have equal inter-particle distance for proper simulation, so it's in your best interest to have a sufficiently large pool.

kind regards

Considering my game is a first person fishing game, I can set the cursor mu to a point far way from the player so he cannot see that long straight line segment. This is very like the "LOD" I'm looking for. Good performance as little particles used. Besides the visual bending problem, is there any known physics problem when using little pool size?

[josemendez]

Considering my game is a first person fishing game, I can set the cursor mu to a point far way from the player so he cannot see that long straight line segment. This is very like the "LOD" I'm looking for. Good performance as little particles used. Besides the visual bending problem, is there any known physics problem when using little pool size?

No, the only "problem" associated to a small pool size is that the cursor will run out of particles (and create a long straight segment) sooner. If that's what you're looking for, it's ok.

kind regards,

[chenji]

No, the only "problem" associated to a small pool size is that the cursor will run out of particles (and create a long straight segment) sooner. If that's what you're looking for, it's ok.

kind regards,

I found a problem. When this happens, the calculateLength is  not changed at all. I'm using calculateLength and rest length to determine whether the rope is streched so this is a big problem for me. Either I need to find a more robust way to determine whether rope is streched or I need to find the cause and fix it. I've sent you a repro demo.