Reverse engineering of Wipeout

[aybe]

Okay it's behaving properly now ! I was subtracting while you were multiplying the fluid mass density

For the time being I'm using the coefficient of the Pac-car II that is in https://en.wikipedia.org/wiki/Drag_coefficient ... unless I properly understand these 2 pages you've sent (hopefully soon). I understand the 'reference area' concept but I still need to compute it for my ship model.

The ship handling is effectively different now !

And what about angular drag, should the same formula be applied to it as well ? (I've left mine to 5.0f otherwise it never stops turning)

Also, regarding the soft constraint you were talking about, there is a spring joint which I've tried in Unity and while it roughly does the same task I couldn't find a way to move the anchor point in the track. So I had some 'free movement' but I was stuck to a certain position in the track. There is also a configurable joint that might do the job but it's way more complex so not for today ...

thanks

[aybe]

Can you confirm that this is (one of) the correct way to do it ?

Basically I get the percentage of white pixels for each side, then multiply according real mesh size, finally I scale down according my transform which is 1/1000th.

Top
2.png

Front
1.png

Side
3.png

Top (X/Z)
image size	: 396 * 903 (357588 pixels)
ship size	: 169681 pixels
percentage	: 0.47451536405024777117800373614327
			
Front (X/Y)
398 * 182 (72436)
12919
0.17835054392843337566955657407919

Side (Z/Y)
906 * 180 (163080)
65725 pixels
0.40302305616875153298994358597008
			
Mesh size (original units)
366, 166, 832			

Results (original units)
Top	= 144,495.62253766904929695627370046 = (366 * 832) * (169681 / 357588)
Front	= 10,835.865646915898172179579214755
Side	= 55,662.3203335786117243070885455

Results (my simulation is scaled to 1/1000th)
Reference Area:
144.49562253766904929695627370046
10.835865646915898172179579214755
55.6623203335786117243070885455

Note: for people interested in reusing this, all ships have the exact same mesh in WO1.

The feeling is as follows now, I can overcome some turns whereas previously I could not and I clearly gained some control for the torque. I guess this is the desired effect, right ?

thanks !!!

[Xpand]

Also for added control you could multiply each of the areas by the cosine of the angle between their normals and the ship's velocity vector (Check vector dot product to find the angle). That way you'll take into account how much of the ship is facing the wind at any given angle.

[BeRo]

And what about angular drag, should the same formula be applied to it as well ? (I've left mine to 5.0f otherwise it never stops turning)

This is my current research area

Because in the real world and in a perfect/better simulation the same drag equation applies indirectly also to the angular drag by AddForceAtPosition in the widest sense of the word, but to these force offset positions to calculate it in a reasonably correct way, there must first be an appropriate equation formula found, which at least I do not know (yet).

[aybe]

@Xpand

It took me nearly 2 hours to figure out that the vector had to be normalized

Yet I'm not entirely sure,

Is it correct that components in 'reference area' should represent 'top', 'front' and 'side' ?
And that your formula should use 'right', 'up' and 'forward' like below ?

            referenceArea = Vector3.Scale(referenceArea,
                new Vector3(
                    Mathf.Cos(Vector3.Dot(localVelocity.normalized, Vector3.right)),
                    Mathf.Cos(Vector3.Dot(localVelocity.normalized, Vector3.up)),
                    Mathf.Cos(Vector3.Dot(localVelocity.normalized, Vector3.forward)))
                    );

I guess I implemented it properly because it's not going berserk as in my first trial, but honestly I can't really feel the difference. In what this formula is supposed to help in, get more control ?

EDIT: I do see some changes actually, previously I did lose some max. velocity and now it is back as usual !

thanks !

@BeRo

I can only wish you good luck, my searches on the topic haven't really brought anything that might be of interest to you

thank you !

[aybe]

Hi guys !

I would like to thank you for those 2 great tips,
few days have passed and it is clear that simulation just got better

I have a few questions if you could give me some hints :

Do you have some pseudo-code about soft-constraints for keeping ship on track ?

or did I miss something in your sayings ?

How do you detect the closest section to ship at any time ?

I used a naive method for finding it, it works most of the time. But when jumping, section below is seen as the next one while I'm expecting the one facing the ship.

I crafted 3 fixes which work well individually, I yet have to combine them to see whether it'll do:
- increase resolution sections' curve with more points and evenly spaced, everywhere
- detect next by accounting whether they are facing the ship, as the user naturally tries to face it
- do the detection again using the above 2 helpers

Picture of the problem:

snap0924.png

- magenta lines/spheres : original data
- yellow lines/cubes : refined data

But you might wonder why I'm doing this ? I do this mainly for knowing how to align my ship (cyan line)

How do you handle collisions with walls/ground ?

Current I use a wall normal rotated at 45 degrees (green line) to know the bump direction. It works really well though the impulse is a bit too intense.

snap0925.png

For the ground I do calculate the ship Y velocity, negate it and multiply it by 2.33, it works moderately well.

But is there a more appropriate way to handle them ?

How do you commonly apply acceleration/deceleration to a ship ?

Previously I tried method in AGR2280 but did not like it much in the sense that it 'removes' force when at max speed.

So I decided to sketch my own which doesn't do that, it works quite well but I was wondering whether there's a proper way in the same vein than your 2 former tips

Also, do you know what 'value' is the red meter in the original game, is it RPM of the ship and would this need to be modeled as well ?

Here's a video below showing the meter in question (at 49 seconds):




thank you very much for your time

[BeRo]

Do you have some pseudo-code about soft-constraints for keeping ship on track ?

The used physics engine (PhysX in your case with Unity) must either support these already itself or have a "low-level" generic constraint type, where you can implement also the solver code parts of it yourself. But if you are interested in it anyway, how it looks as code, look into the Box2D source code, since the most of the Box2D joints/constraints are implemented as soft constraints, but there just in the 2D case.

How do you detect the closest section to ship at any time ?

I'm doing closest-line-segment-to-a-point-search (line segments from previous to next section points, also to next junction section points, and also from these back to the main route path section points) and closest-point-on-line-segment-to-point-calculation, so as a hint: avoid closest-point-to-point searching.

How do you handle collisions with walls/ground ?

I let it currently simply the (my own) physics engine itself do it, without any manual on-collision-event-hooks. But i'm adding, while loading, new invisible upright wall collision geometry with the ground track faces and the section points as reference input data (with best-boundary-edge-raytracing/raycasting) for the invisible upright walls.

How do you commonly apply acceleration/deceleration to a ship ?

I do:

At acceleration:

PhysicsRigidBody.AddForce(PhysicsRigidBody.ForwardVector * EngineAccelerationForce);

At brake:

PhysicsRigidBody.AddForce(PhysicsRigidBody.ForwardVector * (dot(PhysicsRigidBody.Velocity, PhysicsRigidBody.ForwardVector) > 0.0) ? EngineBrakeForce : 0.0));

without any maximal speed limiting, since the drag equation done the physically correct and natural maximal speed limiting already, when it is implemented correctly.

And deceleration do the drag equation already as free bonus, so don't write extra deceleration code for it.

My game physics code at rewipeout and Supraleiter is so far mostly completely free from hacks including hardcoded limits etc. I just implemented so far everything much as physically correctly as possible. At least for me, it has been easier than to use more hacky solutions, but that does not have apply to everyone, so try for yourself what is the best for themselves, is the best way anyway.

Also, do you know what 'value' is the red meter in the original game, is it RPM of the ship and would this need to be modeled as well ?

Nope, but it is on my long to-do list by dumping the RAM content from a modified PSX emulator from two frames for to calculating

FrameVelocity = NewShipPosition - LastShipPosition

but so far I had no time for to do it.

[aybe]

you rock

going to code and post back my results ...

thanks !!!

EDIT:

about that red meter, I thought about RPM/acceleration because while testing AGR2280, their 'accel' var effectively does that, it raises quicker than velocity.

about the PSX emulator, I guess you already know psxjin ? @tigrou suggested it earlier but unfortunately it's quite unstable and couldn't replicate his auto-pilot experiment using TRS for WOXL.

[aybe]

Hi guys !!!

Quick update + a video,



@BeRo

Closest section algorithm: works really well, current section on the video is green, next is red. The magenta line is the closest point in current section segment to the ship, which I use for the constraint.

Constraint: it was not easy to get the ConfigurableJoint configured for this particular scenario but it's promising as you can see on the video ! I still need to fine-tune it as well as enabling track collision but the substance is here Also it seems to cope well with that feedback-loop-feeding approach, basically the joint is on the track and attached to the ship; but the ship 'moves' the anchor in the track.

PS: I did some research on that red meter and sketched a relatively faithful one : I accelerate linearly a normalized value, then I ease it with an exponential ease with a value of 0.25, it's mostly that ...


@all

Do you guys have any extra tips regarding joints and this particular configuration ? or anything else

thanks

[aybe]

Another video, with solid hovering now !



The weird behavior has been fixed and the ship hovers properly as you'll see.

It's incredible how this constraints added realism and at the same time improved the gameplay

[tigrou]

I think we start getting something interesting I really like the way physics behaves now (while there is still room for improvement of course)

What still seems to be strange is how it handles jump, it looks like ship is attached to a spring (glued to the floor), rather than falling because of gravity.

Also : is collision against track disabled for debugging purposes only or because you totally bypass unity physics and need to implement it yourself (eg : by ray casting and such) ?

[aybe]

Yes, I still need to address that stickiness issue ! Was looking for a convincing configuration before attacking the rest and I guess it's sufficient for now.

Collisions are disabled and I'm simply passing through. I still don't know which of OnCollision or OnTrigger to use, the 1st one is safe in the sense things never pass through BUT it does apply some physics, the second is simply an event so I'm free to do anything but up to now I've been getting the issue of force being applied in the wrong direction on subsequent call, i.e. object is swallowed by the wall instead of being pushed away.

EDIT : basically ray cast now is used only when detecting the first section and I do use all the physics of Unity except for the drag equation given by @BeRo.

I guess we'll know pretty soon by now, that constraint solved a lot of issues by itself so it's definitely a plus even though that issue you mentioned needs to be addressed now.

[aybe]

I need your assistance, guys !

I've been able to give room for ship's Y-axis by lowering the joint drive spring on that axis -> the ship effectively does not stick to section when on air now ! But, now the ships go below the hover point and over some (long) period of time it will reach again the hover position.

So I decided to enable collision again to try overcome this problem. I've tried OnCollision first but it completely breaks the physics, ship is stiff, looks to the top etc ... it's totally broken. Ok ... I then decided to use OnTrigger which simply notifies me of a collision and with that poor man's rebound :

var yVelocity = Mathf.Abs(transform.InverseTransformDirection(_shipBody.velocity).y);
 _shipBody.AddRelativeForce(_shipBody.transform.up * yVelocity * 2.333f, ForceMode.Impulse);

It is as unreliable as things can be , it will work on a flat surface though I have to lower that constant but not at all on the rest of the track. The ship will still go below the hover point but as soon as the constraint levels it up to the track, it is sent into space !

To sum it up, OnCollision will detect and fix the collision but basically you have (pretty much) no control on it and it introduces undesired behavior; OnTrigger is a simple notification but I can't detect most (fast) collisions and my rebound approach is obviously flawed.

Do you know of an approach to overcome this problem ?

thank you

[miljoneir]

Semi-off topic:

Why does the original wipeout have 15 track folders? One track folder per circuit for each race class?

[aybe]

Hi !

I'm a bit lazy so I'll just post the code that infers track folders

        public static string GetTrackFolderName(TrackNameWipeout name, TrackClassWipeout @class)
        {
            if (name == TrackNameWipeout.AltimaVII && @class == TrackClassWipeout.Venom) return "TRACK02";
            if (name == TrackNameWipeout.AltimaVII && @class == TrackClassWipeout.Rapier) return "TRACK03";
            if (name == TrackNameWipeout.KarbonisV && @class == TrackClassWipeout.Venom) return "TRACK04";
            if (name == TrackNameWipeout.KarbonisV && @class == TrackClassWipeout.Rapier) return "TRACK05";
            if (name == TrackNameWipeout.Terramax && @class == TrackClassWipeout.Venom) return "TRACK01";
            if (name == TrackNameWipeout.Terramax && @class == TrackClassWipeout.Rapier) return "TRACK06";
            if (name == TrackNameWipeout.Korodera && @class == TrackClassWipeout.Venom) return "TRACK12";
            if (name == TrackNameWipeout.Korodera && @class == TrackClassWipeout.Rapier) return "TRACK07";
            if (name == TrackNameWipeout.ArridosIV && @class == TrackClassWipeout.Venom) return "TRACK08";
            if (name == TrackNameWipeout.ArridosIV && @class == TrackClassWipeout.Rapier) return "TRACK11";
            if (name == TrackNameWipeout.Silverstream && @class == TrackClassWipeout.Venom) return "TRACK09";
            if (name == TrackNameWipeout.Silverstream && @class == TrackClassWipeout.Rapier) return "TRACK13";
            if (name == TrackNameWipeout.Firestar && @class == TrackClassWipeout.Venom) return "TRACK10";
            if (name == TrackNameWipeout.Firestar && @class == TrackClassWipeout.Rapier) return "TRACK14";
            if (name == TrackNameWipeout.Track15) return "TRACK15";
            throw new ArgumentOutOfRangeException();
        }

IIRC Track15 is the beta of Arridos or Terramax ...

[aybe]

Hi guys, new video with updated physics



See the website for the changelog, basically now the ship uses a ConfigurableJoint and section tracking is much more robust (thanks @BeRo), things are much more realistic and we're getting a step closer

By the way, what do you think about the web site ? http://www.wxx-rebirth.com/

Thanks !

[Xpand]

Wow that looks pretty close to the original without the ugly (but necessary) approximations they had to use!
You just need to make the ship actually collide with the track.

[aybe]

Yes it surprisingly does,

Actually I've been trying a couple of things which didn't work until simply trying the following,

put the anchor above just like this :

Disney_Traditions_Goofy_Marionette_4023579.jpg

So basically my previous code was already good, just had to offset the thing a bit

For the collision, do you have a rough idea on what formula/concept to look at ? (main idea would be using a home version like for the drag)

Thanks !!!

[Xpand]

Just use the mesh collider in Unity. No point in complicating that one.

A more "in-house" way would be detecting which triangle of the track's mesh the ship is sitting on and then calculating the distance from the collider model vertices to the surface of that triangle.

To detect the triangle you would have to use barycentric coordinates, which are basically "where inside a triangle is a point". https://en.wikipedia.org/wiki/Baryce...rdinate_system
Look at the calculation for the lambdas in that wikipedia page. That's how you'll find out if a vertex is inside a triangle. This only works in 2D (horizontal plane in our case), so overlapping track portions (bridges, jumps, etc) would need some sort of height condition to ignore the lower track section when the ship went over it.
Here are some pics from my physics engine doing exactly that:

http://i.imgur.com/61YFREK.png
http://i.imgur.com/lML1mmv.png

A point is inside a triangle when lambda1+lambda2<1 and lambda1>=0 and lambda2>=0
You make a loop to go through all of the TRACK's surface triangles and detect the one for which the condition above is true and break out of the loop. Then you can repeat that loop every frame or you can judge how much the ship moved and then find the new triangle using the loop, though faster it is more prone to bugs since you can easily misjudge the player's motion and fail to find the triangle correctly.

To calculate the height of the collider point above the triangle you'll need to calculate the plane equation of that detected triangle. Just look at how to calculate the plane equation from 3 vertices. http://tutorial.math.lamar.edu/Class...sOfPlanes.aspx

you'll get an equation like this: A*(x)+B*(y)+C*(z)=D
To get the height of the track in a (px,py) point just solve that equation for track_z= -[D-A*(px)-B*(py)]/C, where px and py are the collision point's coordinates on the horizontal plane (considering z axis as vertical)

Then your height is (pz-track_z)

If your height is zero or below, then you have a collision. There are also methods to improve your collision detection, called a posteriori and a priori collision detection.

This is also useful to align the ship with the track since the A,B,C constants are the components for the plane's (triangle) normal, although that stuff should already be included with the mesh data.

[aybe]

Yes, I'd rather use OnCollision since it's in Unity and features continuous collision, but ... I've been developing the thing using OnTrigger and now when I go back to OnCollision the ships abruptly looks down ... The old hovering alignment works if I make it 100 times more powerful but then the ship is incredibly stiff

Anyway, it's obsolete so I must code something new. Been thinking and I guess I know the cause : joint orientation. I'll see if I can make it play nicely with user pitch up/down and the torque with .TargetRotation property. Hopefully if it works then the problem will be fixed at this point.

If not then, that was my first question regarding the formula for bouncing with OnTrigger, been using this cheap algo but it's really bad:

var yVelocity = Mathf.Abs(transform.InverseTransformDirection(_shipBody.velocity).y);
 _shipBody.AddRelativeForce(_shipBody.transform.up * yVelocity * 2.333f, ForceMode.Impulse);

Otherwise regarding your tips:
- barycenter : OK
- plane : OK
- triangle search : OK (I guess since I can track the ship's section quite well now)
- other things : I guess OK

So I'll definitely dig into this approach if all else fails.

Coming back to post my results !

Thanks