Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Defined a pooled particles from a given length
#1
Hi,

I want to increase the length of the rope until it reach a given maximal length : l_max. Is there a way to know the pooled particles size for the given l_max ?
For example I wanted a rope with l_max = 100m, but I had a pooled particles of 100 and it only reach the length of 70m... Therefore I just randomly increased the pooled particles size to make it achieve 100 m. But it's not a satisfy solution...
Reply
#2
Particles are spaced differently depending on rope resolution, so 100 particles != 100 meters. Simply divide your max distance by the rope's inter-particle distance. That will give you the pool size. like this:

Code:
int poolSize = Mathf.CeilToInt(maxDistance / rope.ropeBlueprint.interParticleDistance) + 1;
Reply
#3
(09-02-2022, 08:36 AM)josemendez Wrote: Particles are spaced differently depending on rope resolution, so 100 particles != 100 meters. Simply divide your max distance by the rope's inter-particle distance. That will give you the pool size. like this:

Code:
int poolSize = Mathf.CeilToInt(maxDistance / rope.ropeBlueprint.interParticleDistance) + 1;

But can the number of pooled particles be changed in runtime ?
Reply
#4
(09-02-2022, 10:52 AM)lufydad Wrote: But can the number of pooled particles be changed in runtime ?

No. That wouldn't be pooling, would it?

The whole point of a memory pool is to avoid runtime allocation and garbage collection. Allocating memory at runtime is costly, and sets you up for GC. That's why pooling is used as a strategy to create/destroy things at runtime: you create as many "things" (in this case, particles) as you'd possibly need, and just activate/deactivate them at runtime. Changing the size of the pool at runtime would defeat its purpose.
Reply
#5
(09-02-2022, 11:35 AM)josemendez Wrote: No. That wouldn't be pooling, would it?

The whole point of a memory pool is to avoid runtime allocation and garbage collection. Allocating memory at runtime is costly, and sets you up for GC. That's why pooling is used as a strategy to create/destroy things at runtime: you create as many "things" (in this case, particles) as you'd possibly need, and just activate/deactivate them at runtime. Changing the size of the pool at runtime would defeat its purpose.

Ok, that's what I thought. It just didn't work from script because I forget to add :
Code:
_obiBlueprint.GenerateImmediate();

However, it works now, thanks a lot Sonrisa
Reply
#6
(09-02-2022, 04:26 PM)lufydad Wrote: Ok, that's what I thought. It just didn't work from script because I forget to add :
Code:
_obiBlueprint.GenerateImmediate();

However, it works now, thanks a lot Sonrisa

Glad you got it working!

Just to clarify, when talking about "changing the pool size at runtime", I was referring to changing it after the blueprint has been instantiated and the rope is being simulated. You can of course change the pool size before generating the blueprint! Sonrisa

kind regards,
Reply