Formula for bouncing off of slopes?

[Major Cooke]

I have a projectile that I want to bounce off of slopes, but unfortunately, GZDoom just makes them explode on impact. Does anyone know of a formula for bouncing off slopes in particular?

I already know how to get the slope, as it's found in a sector's floor/ceiling SecPlane. In the case of my mod, I only ever need to worry about hitting the ground as there's no actual walls. What few things the grenade can hit will be determined with a trace.

[Rachael]

If you discover this, it probably should be made an actor flag in the engine, in my opinion.

[Major Cooke]

Yeah that'd be for the best. I did some digging around and I think I found something of a clue.

[Major Cooke]

Okay, so big thanks to KeksDose we managed to figure something out.

Code: Select all

if (!Stopped && !bKILLED && Vel != (0, 0, 0))
{
	if (!Trc)	Trc = new('GrenadeTracer');
	if (Trc)
	{
		Vector3 tpos = pos + (0, 0, height * 0.5);
		Vector3 dir = vel.Unit();
		double dist = max(Radius, Height) + vel.Length();
		
		if (Trc.Trace(tpos, CurSector, dir, dist, 0))
		{
			if (Trc.Results.HitType == TRACE_HitFloor && Trc.Results.HitSector)
			{
				Vector3 Normal = Trc.Results.HitSector.floorplane.Normal;
				Vector3 HitPos = Trc.Results.HitPos;
				vel -= 2 * vel dot normal * normal;
				vel *= BounceFactor;
				if (vel.Length() < 3.0)
				{
					A_Stop();
					Stopped = true;
				}
			}
		}
		else if (Pos.Z <= FloorZ)
		{
			SetZ(FloorZ + Abs(Max(0, Vel.Z - 1)));
		}
		if (!bNOGRAVITY && !Stopped)	Vel.Z -= Gravity;
	}
}
else Vel = (0, 0, 0);

A bit slapdash and I haven't gotten it to take into account actors just yet but that'll come soon.

However, I'm not entirely certain if there's a good way to really replicate this in the source itself.

[Rachael]

If it can be ZScripted, it can be rewritten in C++. Though that might take a little extra effort. Luckily though, you have the VM exports already to use as a reference.

If I have some time later, I can try and help you out with this, I imagine it's mostly going to be mostly plugging formulae in place of symbols anyhow.

[Major Cooke]

Right, but that's just a tiny portion of it. Furthermore, this doesn't take into account if there's intersecting lines in the way which may clip it.

It's more of a fundamental issue on making sure everything's taken into account.Which means projectiles that have this could very easily move directly parallel with a line and it'd never be picked up for collision, unless additional traces are involved going from one corner of the cube to another opposite.

But... I may not need to if I work on this to help with things.

[Rachael]

Lines should not be intersecting in Doom. This isn't Build where every map object is isolated into its own little world - if a line is intersecting a sector then the sector, and by proxy the map itself is inherently broken. I don't think we should have to account for such cases, here.

Unless I am mistaken by what you mean here?

[Major Cooke]

Oh, no I was talking about a LineTracer's Trace function potentially missing lines. Sorry, was rambling.

As for impacting, yeah I can work with this and add a BOUNCEONSLOPES flag, but first I have to make sure it's not outright broken in the engine. If that's the problem going on with it, this may prove to be more difficult.

[Rachael]

If it's broken in the engine then it's one of those things that obviously will have to wait for a fix before something like this will be feasible.

[Major Cooke]

I'd love for it to work so I'll be willing to tackle it. Now that I know how to make it bounce on slopes, that's half the battle at least.

[Apeirogon]

You do it wrong. Well, math not wrong, but approach is not.

Since bouncing is a rotation of a velocity vector on some angle, its better to implement rotation of a vector on some angle in general, than one specific cases.

So firstly you need find angle between vector_1 (velocity) and vector_2 (normal)

Code: Select all

double, double, double angle_between_vectors(vector2/3 v1, vector2/3 v2)
{
    calculate and return angle/pitch/roll aka angles around X/Y/Z axes
}

and then actually rotate vector

Code: Select all

vector3 rotate_vector(vector2/3 v, double x_angle, double y_angle, double z_angle)
{
    sined cosined magic here
}

For bouncing case just reflect vector, since after rotation velocity vector would have correct orientation but reflected direction.

[KeksDose]

In the end, your idea will do the same thing, using 10 times the work, so I'm not convinced. edit: What do you think is worth modelling, that the formula above can't without large modifications?

[Apeirogon]

Because this is more generic formula, not specific case which have "short" solution.
Unless you know how rotate, say vector (3.8, -7.64, 7.8) 12 degree counterclockwise around x axis using dot product.

[kodi]

Code: Select all

vel -= 2 * vel dot normal * normal;

Is as generic as it gets
Projectiles don't face their movement direction by default, so there's no reason at all to mess with angle and pitch.

[KeksDose]

The new idea doesn't create reasonable doubt it's worth pursuing to model bounces better.

The oneliner above can, with few modifications, allow you to separately set how much reflected velocity and how much not-reflected velocity is conserved. I don't think it gets much bouncier than that, but this is also the bit where I can be proven wrong...