TGB 1.7.3 Beta 1 Bug - Sticky corners

#1 Logged as TGB-80.

Would you be able to make a reproduction case project available for Melv to work with?

#2 Stephen,
Sure can do.

#3 Very odd.

Are you using a constant force, if so what is it? How is the player being moved, by altering the linear velocity only or changing its position?

As Stephen suggested, if you could send me the scripts associated with this ASAP I'd very much appreciate it.

Unfortunately the image isn't showing above for me.

Melv.

#4 Melv,
Here is my movement script

function playerMovementControlsBehavior::onUpdate(%this)
{
      
   %velX = (%this.right - %this.left) * %this.moveSpeed;  
   %velY = (%this.down - %this.up) * %this.moveSpeed;
   %this.owner.setImpulseForce(%velX, %velY);
   //%this.owner.setLinearVelocity(%velX, %velY);
      
   if (%velX == 0 && %velY == 0)
      %this.owner.setDamping(%this.owner.myDamping);
   else
      %this.owner.setDamping(0);
}

I've tried using setImpulseForce and setLinearVelocity still get the problem. However, if I comment out the damping portion, the problem goes away. I can send you the project if you'd like. Just let me know where.

#5 To save lots of emails it'd be great if you could send me your project.

Melv.

#6 Just to let you know that it's clear skies tonight (the first in over a month) so I'm outside with my telescope but i've got my iPod (how i'm typing this) so I'm keeping an eye on the forums. If you can send me the stuff soon I'll check it later.

#7 I'm back inside now ... any chance of those scripts Patrick?

Thanks!

Melv.

#8 Sorry to bug you on this but I was wondering if you could send those scripts along as I'd like to have a look/see. I'd like to have it ready for when I work on it this evening that's all!

Melv.

#9 Got your email, thanks Patrick. :)

Melv.

#10 This one seems to be fixed. The bug report reference is TGB-80.

Melv.

#11 Melv could you please post the necessary code changes? we would like to switch to 173 now as we need these physics improvements and need to start to work on performance issues now, but this sticky corners keeps us from using 173.

thanks alot!

regards
And Yet It Moves Team

#12 This bug is fixed in 1.7.3, unless you have a different reproduction case from the user above (which it sounds as if you do).

Could you be more detailed in your problem (with information on the objects and how to duplicate it)?

#13 I'm calling your bluff ... hey hey. ;)

There wasn't an internal engine bug here, it's was an issue in the scripts being used.

I've spoken to Patrick a few times since he reported an issue and he had another minor issue which we resolved together but again no internal change. He's rocking now.

It sounds like you've got a specific bug to report. If so could you do that and send along a script as well?

Thanks!

Melv.

#14 Rocking sounds perfect! :)

I have put together some simple project which reflects the very basic movement we are using. its using the original tgb source code. as this scene is very simple the stickyness only happens if you set the
ITickable::smTickShift to 3 (ginving a tick time of 8ms); in larger levels as we have in our game, the same thing happens at a tickShift of 5 (the default value).
move left and right with a and d and sometimes the player will stick to the ground, especially in the flat area.

basically i use the same method for moving (forgetting about frame- resp. tick- rate independence for now):

player.setLinearVelocityX( (right - left) * speed );

could you give me your email to send you the project files?

edit: this didnt happen up to 172...

merci

#15 ... but I presume what you're sending me isn't going to take me hours to wade through scripts? I really don't have the time to do that unfortunately.

Can you provide me without something simple that demonstrates your problem, preferably without engine modifications required although if you're only changing the tick-time I'm happy to do that.

EDIT: email.

Melv.

#16 AYIM ... email received.

#17 Hi,

I'm wondering if you're seeing a degenerate contact direction in the overlap solver. I'm suprised you get these but setting the tickShift to 3 (8ms) would definatley shake it out. You have to be careful setting this as you'll get no tick interpolation unless your frame-rate is above 125fps.

To be honest, I went back over my notes and I had ticked the degenerate contact direction problem as solved but I cannot see the code that addresses it. It looks like I may have reverted that change for some reason.

Anyway, if this is your problem then the following single-line change should completely solve it:

In the function:

void t2dPhysics::resolveOverlapPair( cCollisionStatus* pCollisionStatus, const U32 contactIndex )

... change the line ...

t2dVector overlapExtend = contactDirection;

... to ...

t2dVector overlapExtend = contactDirection.isLenZero() ? pCollisionStatus->mCollisionNormal : contactDirection;

Does this resolve the problem? If not then you're seeing something else.

Melv.

#18 This fix makes an improvement to rigid collision response, but doesnt solve the problem of the player (which has response CLAMP) moving over certain slopes.

i solved this now by giving the player a RIGID response with maxAngularVelocity of 0.

> You have to be careful setting this as you'll get no tick interpolation unless your frame-rate is above 125fps.

what is the drawback of having lower frames/second than ticks/second? if i have 60fps and the physics running at 125ticks/second, it looks approximately like this:

tick - tick - frame - tick - tick - frame ....

so i have more ticks than frames. but frames still will be interpolated between the ticks?, and the many ticks give a more exact physical simulation resulting in much better rigid body behavior.

thanks!

#19 Hi,

The first level you submitted revealed I hadn't (for some reason) committed the "degenerate contact direction" fix in the release. I received your second email (with a different setup) in which you're experiencing a similar problem.

The reason the above probably doesn't fix it is because it'll be happening for a different reason!

As I say, I'll have a look at it tonight and let you know ASAP.

I'm actually worried because I submitted a whole batch of fixes and changes and I've already seen two now that are not in the repository. A recent issue with the "t2dTrigger" was tracked down to a local subversion issue and I'm hoping this hasn't happened on some of the collision fix submissions!

Melv.

#20 Ok everything back: tried some other slopes and the stickyness is there again, no matter if using rigid or clamp collision response :(