Jump -- The final frontier.

[blueteak]

After a grand total of over 7 hours of solid work, two big things have been accomplished in the game's jump physics.

1) Jumping is now a constant height.
- This was accomplished by scrapping the PhysX bounce system and rewriting my own to suit the needs of the game, so that if you are jumping, no bounce is applied to the marble and you simply add the jump force. This is not the case with jumping up/down ramps, as there are many other factors that play into the trajectory of the marble. (You also don't jump if you hit the ground with enough force, you simply bounce to the height you would have normally)
Lines of code to achieve this: 51

2) Wall hits now work.
- This feature was a much more difficult one to implement and likely needs a bit of tweaking for MBG replication, however it works very much like you would expect. The reason this was difficult, as the effect has no basis in Physics, and is actually the opposite of what would really happen if a spinning ball hit a wall. Because the marble is rotating downward against the wall, the marble should bounce off lower than the collision normal angle. Wall hits make the marble go higher... <- Sometimes I just don't double check my facts... Don.Gato to the rescue!
The effect was achieved by calculating the surface normal of the geometry hit (to make sure it is really a wall and not just a steep ramp) and then adding y velocity relative to the impact force, resulting in a higher bounce the harder you hit the wall. There is also additional code to make sure that you aren't wall hitting if you don't have a certain threshold of y-velocity (ie, you didn't jump against the wall, you just ran into it or fell into it while going down).
Lines of Code: 36 (75% is math that looks like this...)
var baryCenter = hitpt.barycentricCoordinate;
    var interpolatedNormal = n0 * baryCenter.x + n1 * baryCenter.y + n2 * baryCenter.z;
    interpolatedNormal.Normalize();
    interpolatedNormal = hitpt.transform.TransformDirection(interpolatedNormal);

The final bug that I need to work out is loosing the ability to jump (until you leave the ground via dropping off a small ledge or using blast) if you jump while pressed against a wall. This occurs because the map is all a single piece of geometry, so while you are leaving the floor, you aren't exiting the collision (because you are still touching the wall) and jump is re-enabled when you enter collision (which you can't re-enter because you never left). Once I think of a good solution to this, I'll fix it too. Until then, see if you can do some tricks with wall hits

[Don.Gato]

Okay, some things you won't want to hear.

First up, the biggest issue. That can't jump bug has gotten WAY WAY worse. Before the only times I came across it were when repeatedly jumping into walls (to test wall hits of course). Now I seem unable to jump more often than not. Near walls, away from walls it seems totally random. It is also harder to break out of than before, simply blasting doesn't do it, I have to blast and hold jump. And a good amount of the time as soon as I stop holding jump I can't jump anymore until I do it again.


As for wall hits themselves, I finally managed to approach a wall with speed, and have my jump not bug on me at the critical moment, and the effect seems too pronounced.

Now I don't know what you mean when you say it has no basis in physics. It absolutely does, and is exactly what would happen if a ball with topspin hit a wall. In fact before this update Wall Hitting already worked. It wasn't nearly as strong as it is in MB (but now it's stronger ) but it did the same thing. When the edge of the ball hits the wall, it is rotating down against it, thus pushing the ball slightly up. How much depends on how much friction is present between the wall and ball, among other things. One of the best examples I can think of off the top of my head is table tennis. Players impart topspin on their shots for 2 main reasons. The first is that the ball has a much lower, faster trajectory after bouncing, for the same reason that wall hits work. The spin of the ball is pushing it forward upon bouncing. (MB has the same behavior BTW, and that is probably why jumping speeds you up. Also releasing forward before bouncing results in a higher, but shorter bounce, because it has less spin). The second big reason for top spin in ping pong is that when the opposing player hits the ball it will go high off their paddle (essentially wall hit off of it), assuming of course that they don't counter that effect with the angle or motion of the paddle itself.

I have to say I don't like your approach to wall hits as you described it. The effect is just as viable if a wall is not exactly 90°, and even if the marble has no y velocity. Rolling into a wall at high speed should produce a little jump. Try rolling a super ball, or even a coin or marble at a wall and that is what will happen. Assuming it hits hard enough to overcome its weight of course.

[blueteak]

I just spend 10 minutes in the lobby jumping everywhere and never got my jump disabled. There may be something else going on that is computer/browser dependent (possibly frame-rate dependent?)

I measured the wall hit strength against a MBU video for the initial tweaking, though I agree mine is a bit stronger, I'll try to tweak it to MBG levels just to make sure they are equivalent.

After reviewing your point, I agree you are completely correct and I am not sure why I had the idea that this was not the case. Struck through in OP. The approach I took for wall hits may not have been described well enough. I don't reset y velocity, I just add a multiplier to it (and now I realize that it is a redundant check to see if there is y velocity to multiply by) so there would be no addition to zero y velocity anyway.

However now that I realize that it is physics based I'll have to come up with a better solution anyway so that It acts realistically in all situations.

[Don.Gato]

Aug 7, 2013 22:10:53 GMT blueteak said:

I just spend 10 minutes in the lobby jumping everywhere and never got my jump disabled. There may be something else going on that is computer/browser dependent (possibly frame-rate dependent?)

That is what I though too, so I bumped the quality down a notch, same issue. I will try bumping t down once more to minimum, but my FPS were (was?) pretty good and it was still happening....

[ProMarbler]

I second this. I was running on a lemon of a potato which amazingly got 10--15FPS on lowest quality settings possible, after a load wait of about 5-10 minutes, and I could jump about every once in 98 tries, it seems. Also, make MINIMUM graphics settings the default, please. My CPU just melted for the 857th time in it's history, because it takes the load because this JOKE of a GPU can probably only count to two.

That beside, it's neat so far! Shame that it won't work install 3.5+ on my potato Mac.

[blueteak]

Ok, the reason that there was a big problem with the no jump bug was because of the graphics being used. My webplayer uses Direct3D whereas people without Direct3D enabled graphics cards (and macs) use OpenGL, and apparently there is a different process order for the two. This has now been fixed (after forcing OpenGL in the editor) so this shouldn't be a big problem anymore (still occurs when jumping while wall-hugging)

Edit: I've also lowered wall-hit power by 15%

[Don.Gato]

Aug 8, 2013 0:07:17 GMT blueteak said:

Ok, the reason that there was a big problem with the no jump bug was because of the graphics being used. My webplayer uses Direct3D whereas people without Direct3D enabled graphics cards (and macs) use OpenGL, and apparently there is a different process order for the two. This has now been fixed (after forcing OpenGL in the editor) so this shouldn't be a big problem anymore (still occurs when jumping while wall-hugging)

Edit: I've also lowered wall-hit power by 15%

Ah. I am on a mac.

[ProMarbler]

I was using an old PC, but still had that issue, Perhaps it is because of Chrome? I'll check again later.

[blueteak]

Decreased wall hit power again, this time I think you will find it more "familiar" in terms of power. Still not physics based (well.. it IS physics based, just hacked physics instead of actual physical properties) so I'll continue to work on it. Any better luck with jumping?

[Don.Gato]

Yes.

Sorry for not making that clear before.

[blueteak]

Awesome, those little system dependent discrepancies are the worst part of this. Glad this one was relatively easy to fix, I'm sure later I'll come across one that isn't so simple.

[Perishingflames]

1) Jumping is now a constant height.
- This was accomplished by scrapping the PhysX bounce system and rewriting my own to suit the needs of the game, so that if you are jumping, no bounce is applied to the marble and you simply add the jump force. This is not the case with jumping up/down ramps, as there are many other factors that play into the trajectory of the marble. (You also don't jump if you hit the ground with enough force, you simply bounce to the height you would have normally)
Lines of code to achieve this: 51

I'm not sure if the following situation is what you just addressed, but this remains a problem: You get less height off your jump when rolling (and it seems the faster, the less height you get) than when stationary. This makes 0 intuitive sense and MB does not work that way. This is the biggest problem with jumping for me right now (besides the new wall bug).

[blueteak]

I do know that height changes on ramps (need to address this differently than I anticipated, because MB doesn't just use the normal angle). However, I haven't experienced a change in height dependent on movement speed on a flat surface.

Edit: Just checked using the editor console, when standing still, y velocity went to 2.4, while rolling on flat surface pretty fast, it was 2.39999999 +- .0000001. So this may also be a system dependent bug?

[IsraeliRD]

A quick hack for wall bugs if your marble gets stuck, in MBG you can edit the init.cs to give it a force of 0.001 for all surfaces and that means it won't stick. 0.002 might be more noticeable though. However if you're standing on the ground you might not even notice that the marble constantly jumps up

[blueteak]

Awesome idea! I wasn't able to just add force because you could tell it was jittering up until collision stopped being exited. However, I used the principal to create another function that was dependent on staying inside collision, which worked like a charm. Thanks Matan!

Edit: Works perfectly in web player for me, so "can't jump bug" should be a thing of the past. Let me know if it works for everyone else.

[Don.Gato]

Hey Blue

I was thinking about the Wall Jump thing (In fact I couldn't stop thinking about it), and I think I came up with a good solution.

So if you integrate something like the following into your bounce code (Not just for walls, for any and all collisions with the level) I think it will work well.


spinFactor = magnitude * ((revsPerSec * circumference) - speed) * collisionForce


So what we have is first a magnitude variable (probably a low decimal), to control how profound the effect is. Then we calculate how fast the marble would be going were it spinning at the speed it is on the ground, and subtract the marbles actual speed from that. (Note, not the marbles overall speed, but only the speed tangent to the surface you are bouncing on, and in the direction of spin within that tangent plane). This is done so that the effect is stronger if the marble is spinning faster relative to its direction and speed of movement. Mostly applies on horizontals.

Then we multiply that by the force of the collision. The harder you hit a surface, the more the spin should effect it. (true IRL because the harder they hit the more surface area comes in contact.)


Finally we get to the tricky part. spinFactor should be added to the bounce force tangent to the surface, and in the direction of spin. And subtracted from the bounce force along the normal of the surface.


My guess is that the native physX bounce system contains something much like this (Though more complete I am sure, taking more into account) and that if you could access that, increasing the magnitude would do just what we want. But alas.

[blueteak]

Already added something very similar to that in game. On the road today so I can't give you details, but I guess I forgot to mention that I had made it physics based. Also fixed a lot of the jump problems with physics solutions instead of hacks.

[Don.Gato]

Ah.

good to hear .

[Jeff]

real solutions aren't fun. Hax are. ITS THE HAX MAN.

[blueteak]

Now that I'm back I'll give a bit more info on my solution.

The code that I use for all collisions is:
rigidbody.AddForce(1.5*(Quaternion.AngleAxis(-90, interpolatedNormal)*(rigidbody.angularVelocity-interpolatedNormal)));

The way this works is that

1.5 is that magnitude for tweaking what "feels good" for additive frictional force.

Quaternion.AngleAxis() re-aligns the direction after finding what I would compare to a Vector Cross multiplication (so the pre-multiplied vector is 90 degrees to the left of where it needs to be to add force in the correct direction.)

rigidbody.angularVelocity is a 3D vector that defines direction and magnitude of the marbles rotational velocity.

interpolatedNormal is a calculated 3D vector (normalized to numbers between 0-1) that defines the direction of the surface normal of the geometry face the marble hits.

Subtracting the angular velocity from the surface normal gives me a direction (after multiplication with the angle) consistent with how the friction would be pushing the marble, and a magnitude linearly proportional to the angular velocity.

The hardest part was getting the surface normal of the geometry, which is determined by this code:

     var collider:MeshCollider = hitpt.collider;
    var mesh = collider.sharedMesh;
    var normals:Vector3[] = mesh.normals;
    var triangles:int[] = mesh.triangles;

    var n0 = normals[triangles[hitpt.triangleIndex * 3 + 0]];
    var n1 = normals[triangles[hitpt.triangleIndex * 3 + 1]];
    var n2 = normals[triangles[hitpt.triangleIndex * 3 + 2]];

    var baryCenter = hitpt.barycentricCoordinate;
    interpolatedNormal = n0 * baryCenter.x + n1 * baryCenter.y + n2 * baryCenter.z;
    interpolatedNormal.Normalize();
    interpolatedNormal = hitpt.transform.TransformDirection(interpolatedNormal);

[Sporlo]

2 things I noticed from a day or two ago (so you may have looked into them by now):
1) The A direction applies force different from the WSD directions. A was weaker than WSD.
2) I was able to super jump by pressing the space bar an instant after touching the ground. Ridiculously hard to do, but it exists.

[Jeff]

Once in a blue moon Uil and myself had ended up not getting the same jump force whenever re repeatedly jumped on ice. Might wanna check your jumping code again

[Don.Gato]

Aug 12, 2013 17:00:22 GMT Jeff said:

Once in a blue moon Uil and myself had ended up not getting the same jump force whenever re repeatedly jumped on ice. Might wanna check your jumping code again

I find ice to be very bouncy.

[blueteak]

HD crashed, trying to restore it, it had only copy of game files on it.... Hindsight 20/20 on backups... but in any event it may be a while to do an update.

[Don.Gato]

Question, does HDD failure ever happen to people who do have backups, or to people who are not working on something stored on said HDD?

Cause it doesn't seem like it.

[blueteak]

lol. Ya, it's ridiculous. The game was like the ONLY thing on the partition that failed.

[Jeff]

Its terrible, always the important stuff is what gets lost or damaged