Bouncing of two moving objects slows down them

HunnenkoenigHunnenkoenig Member Posts: 1,173
edited November -1 in Working with GS (Mac)
I try to figure out since days, how to solve this.

I have moving objects on the screen, which collide and bounce. The problem is, they slow down in some cases.

I tried to play with linear velocity changes like in the Magnitude demo and I tried every possible settings I could think of.

Nothing works.

I even tried to make an "aura" around actor1 which is moving with it together and tell actor2, if the aura overlaps with actor2, change "movable" to false or change "density" to 0 on actor2.

That didn't work at all. When the aura overlaped, actor 2 was moving around happyly after.

I tried to set restitution to 0 or 1 on both actors in different ways. Nothing.

Anybody an advice?

Comments

  • nulonulo Member Posts: 315
    you want them to slow down or you don't want them to?
    if you WANT them to, put a value smaller then 1 on restitution on both the moving actors AND the walls/grounds they collide with. put 0 on all actors, and slowly grow this number until you find something interesting for you.
  • rebumprebump Member Posts: 1,058
    If you don't want them to, make sure you don't have any drag applied to them. I would imagine friction could come into play a bit too. Scene gravity is already off I would surmise.

    Last resort if you cannot get things working:
    Maybe constrain the velocity attributes using a "reverse" magnitude computation (i.e. solve for X and then Y) to determine the X and Y values for velocity based on the direction (line) of travel in quadrant one of the cartesian coordinate system? I think y=mx+b ("rise over run") would assist. You could probably fake it without all the math but may experience slight velocity changes the more diagonal a movement is compared to more horizontal/vertical movements.
  • HunnenkoenigHunnenkoenig Member Posts: 1,173
    Thanks for reply.

    I don't want them to slow down. Sorry for being confusing :-)

    I have a ball which collides with the walls and it works fine. But I also have moving bricks, which shouldn't slow down the ball, but they do.

    Unmovable bricks work also fine. But if the moving actor and the ball collide, they both slow down after a while. Mainly when they move toward eachother and collide so.

    Physically it is right, but for my game it is not good and It seems it can't be solved.

    I tried constraining velocity and movement and all.
    The problem is that "collide" and "bounce" are not separated things.

    If I use MGF's (or what his name) magnitude demo method, the actors will go out of the screen if they are hit 2 times very quick, like in a Z movement colliding with the wall and with another actor.

    If I make it collidable, then the magnitude method is useless, because the actors have both (collide AND magnitude) and act strange.

    If I use only collide, then they bounce, but lose velocity.

    I also have no possibility to say "keep velocity whatever your direction is". Because I never know, from which directon my ball will hit the round shaped brick, I can't say "change velocity Y"

    So for the DEVs my suggestion is to:

    - make "collide" separated, which only tells that this actor has a border and everything should stop there.
    - make "bounce" separated, which tells that the bouncing object should bounce with the same velocity for ever.
    - make everything else adjustable with "density", "friction" and "restitution"

    ---

    The other thing (I don't want to make a new thread):
    Changing density and movable doesn't work after the actor was spawned.

    If I make a rule which tells "if colliding with actor1, change attribute self.moveable to false" it doesn't work. The attribute will change, but the actor is still movable.

    I tested it with "display text". Density and movable was set to false/0 correctly, but had no effect.

    So, I hope, somebody reads this :-)
  • firemaplegamesfiremaplegames Member Posts: 3,211
    you cannot change movable or density at runtime.

    if you do not want the actors to slow down, you will need to use the math in my magnitude demo... but yes, in that demo they can bounce through the walls. you're going to need to come up with more Rules to make sure that they don't go through the walls, or if they accidentally do, figure out some way to snap them back into the scene.
  • HunnenkoenigHunnenkoenig Member Posts: 1,173
    Thanks.

    What do you think, I could do to prevent them going through the walls?

    I can't think of anything, which can do this. I already tried. :-(

    I am messing around with this since 4 days.
    I wanted to publish today :-)
    Now I don't even have levels...
  • nulonulo Member Posts: 315
    why not try this rule on the actor.
    if velocity < X
    change velocity to Y

    just like there is a "max speed" on the motion tab of the actor
    try to recreate a "min speed"
  • HunnenkoenigHunnenkoenig Member Posts: 1,173
    Nulo, the problem is not in the velocity, but in the direction.

    It is easy to determine direction, when it collides with the fixed wall, but it is not easy if it collides with a circle shaped moving object.

    I tried everything and it always look stupid/unnatural.
  • nulonulo Member Posts: 315
    sorry about that. i thought "slowing down" was the problem.
    why not create invisible actors, the same shape as your moving actors but just a little smaller, and constraining them to your moving actors. this way if the collision doesn't happen on the first actor (the visible one) it might trigger with the second, invisible and smaller one.
  • HunnenkoenigHunnenkoenig Member Posts: 1,173
    Yeah, slowing down is the main problem, but if I want to add change velocity rules, I always have to provide a direction.

    But it seems, I can manage that now. It still looks stupid sometimes, but maybe I can live with it.
  • rebumprebump Member Posts: 1,058
    Maybe leave your walls square collision areas and make all the moving parts use a circular collision area!?
Sign In or Register to comment.