Currently all curves are treated as outer boundaries of solids, rather than as holes.
I could maybe add in an option in a future release to have some curves be containers instead.
For now though, one way of solving this is to draw your containing curves like this, so the ‘exterior’ curve still contains a finite region:
In what positions are your curves starting before applying the collision?
If they are too far overlapping to begin with, they can get pushed in the wrong direction.
It might also help to increase the outer boundary of your container shape, so the contained objects get pulled towards the inner wall:
Do you mean they start out all with their centroids at the world origin, so they are all overlapping? Can you show this or post the file.
If so I can see how that would cause problems, since such a big overlap at the start would make them fly apart so fast they get stuck in the container walls.
If the aim is to produce a non overlapping arrangement, it would be better to start with them at least somewhat distributed.
yes they created at Pointr3d(0,0,0)
and transform.translate(new vector3(-width/2,-height/2,0))
to make all of object at center
yes
no this is a rhino plugin i didn’t make an installer at this time for the plugin ( it need to install many library and etc for running out of my computer )
thanks it is good logical answer i have many experience in physics fly
my aim is your said i try to change start location
thanx
is there any way to change the kangarooPhysicsEngine refresh time or in Kangaroo Step works like refresh time
i write it for who newbie users read this post
^^^^^^^^
in popular gaming PhysicsEngine we have phyisic refresh time to find best option beween CPU usage and Collision detection
for example if you set time smaller the CPU usage grow up but can detect most of collisitons
The Step method performs 10 iterations, then another 10, and so on, until either reaching the stopping threshold, or exceeding 15ms. This is because for most of the intended applications in Grasshopper, the aim is to reach equilibrium quickly, with a reasonable frame-rate for on screen updates to allow interactivity, but not requiring a perfectly fixed frame-rate, as you might want in a game. This means the frame rate will vary according to the complexity of the simulation, and also during simulation may vary slightly due to the varying workload on the CPU.
There is also another method available called SimpleStep, which performs exactly 1 iteration. I guess if you use a script with its own timer you could use this to maintain a steady frame rate (provided that 1 iteration always takes less than the duration of a frame).
It would help me to help you better if you can give some sort of overview of how you want to use Kangaroo. It differs in several ways from a typical game physics engine, because the priorities are different. I’m still confused about whether you are trying to make a game that actually runs in Rhino, or just use Rhino for the level design.
this post is awesome
after reading this post i understand better the Kangaroo physics engine
and be sure to use kangaroo more to end of my project
at this part i use rhino for something like game level designing ( for packing level assets )