Page 5 of 8 FirstFirst 12345678 LastLast
Results 81 to 100 of 146

Thread: Reverse engineering of Wipeout

  1. #81
    Join Date
    Apr 2015
    Location
    France, Paris
    Timezone
    GMT + 1
    Posts
    310

    Default

    thanks, in the mean time I drop 2 other questions and another video !

    what do you think emulating this bouncing ship requires, in the hover spring or the physics material ?

    the way to go seems to not use triggers as we don't get contacts and lose some freedom over collisions, or did I miss something ?



    (also, I do try to keep some sort of history of changes in the website if you'd like to know what has changed)

  2. #82
    Join Date
    Mar 2015
    Posts
    57

    Default

    @aybe : hope you are still working on the project. I took a look at your questions and to be honest I cannot answer any of them.

    Let's hope a guy with physics background and/or game dev experience in a wipeout clone will answer (like Xpand)

  3. #83
    Join Date
    Jan 2011
    Timezone
    GMT + 1
    PSN ID
    Apple-Guy-Cipher
    Posts
    1,922

    Default

    when you're nearing the bottom plane of the collision (read not side walls) you probably want to apply an upwards force relative to the distance between bottom collision plane and ship, if this is managed in the hover effect, you just want to increase the hover strength relative to the distance of the floor, that's how i see it anyway

    Airtime & hovering you probably want to have a relation between height between track and ship as well, meaning the hover effect disengages when a certain height is achieved (saves performance too ^^), gravity is too high in both your previews i think (better in the first one, but even there, probably still too high, you could fly really far without pitch on that jump after the big drop)
    Airbrakes; i think you have correctly implemented them, just need to add ship rotation to it to make it more convincible

    Cipher
    Last edited by Cipher; 17th June 2015 at 03:10 PM.

  4. #84
    Join Date
    Apr 2010
    Posts
    1,529

    Default

    I honestly don't understand your question.
    In that video it seems you already have the bounce physics working in some way. Are you using physics materials or are you using coded forces?

    The hover/spring force is a must for these times of games, however small of an effect it has, there's no real point in trying to avoid using it. Using physics materials only goes so far, and when you want to make more customizeable physics it won't work as well as having the forces coded from scratch.
    I'm stuck with final exams until july, but after that I can help you more directly if you want.

  5. #85
    Join Date
    Apr 2015
    Location
    France, Paris
    Timezone
    GMT + 1
    Posts
    310

    Default

    Yes I'm still on it ! I did quite some work lately though not on aspects I wanted to enhance : hover and bounce . I guess @Xpand was right , you have to bend that thing but that introduces something : we bypass everything so we need our own physics layer.

    The thing is that I'm pretty certain they did handle wall hits like I do now : applied force being normal of the wall, mystery being why sometimes the ship rolls instead in PSX. Anyway this is the most coherent approach I found and have no plans to improve it any further unless really necessary.

    snap0903.png

    But as @Xpand said constraints are needed, I can't get anything stable with OnCollision* methods as from what I understand, physics are applied no matter when these are called. Collisions are either occurring twice or making the ship slide downwards and hover comes in and screws everything. Also physic materials have no effect since I hover and add forces. If I let it touch of course materials are in action but in turn it's too realistic ...

    First solution is OnTrigger*, problem : no contacts and so on but no problem as I do cast rays and it works well. It does work well but now ships passes through at times and OnTrigger should be even on the ground (did not yet try). Also, while current thing works well in AltimaVII, things go insane in ArridosIV for instance ...

    I have 3 goals :
    - see if I entirely drop OnCollision* (would like to try @tigrou hint of using ALCOL.PRM as collider)
    - see if OnTrigger* and everything manually will do ... but lots of work like in AGR/BNG
    - split concerns as the thing is getting cumbersome to manage (might have to do this 1st )

    As day passes on, I do find that the original game is less and less realistic that I thought at first, to the point that it's entirely unrealistic hence bypassing Unity physics might be a good move though it will cost a lot. Finally the bouncing, I can't find any spring setting reacting like in the original game, unless physics are not realistic. I will see if I can get @Cipher and @Xpand hints to improve the current thing otherwise I'll attack the problem entirely from the roots

    I expect my next video to show way more refined physics, hope I'll get to it soon

    EDIT: @Xpand, yes help is really appreciated, take your time and good luck !

    EDIT 2: a quick video that shows these issues

    While some parts have improved, some have degraded as you will see; that gave me some hints though so I'll see if I can fix that stickiness before taking another approach.

    Last edited by aybe; 18th June 2015 at 12:06 AM.

  6. #86
    Join Date
    Apr 2010
    Posts
    1,529

    Default

    The ship rolling when it hits the wall in PSX is an animation and not a physics thing. They used center of mass physics for everything other than detecting collisions, so torque and other rigidbody rotation was impossible for them to do back then.

    Also you're using discrete logic when calculating the AG force (On collision, On trigger, etc). That can create infinite derivatives in the velocity (fig. 1), which translates directly into infinite acceleration, which is most likely why it glitches out. This has to be a continuous thing. The AG force has to constantly be calculated and active to get the best results.

    Figure 1.
    Last edited by Xpand; 18th June 2015 at 11:48 AM.

  7. #87
    Join Date
    Jan 2011
    Timezone
    GMT + 1
    PSN ID
    Apple-Guy-Cipher
    Posts
    1,922

    Default

    ^That's a pretty good representation yes! ^^

    Forces is most likely the way they went, because they probably didn't have fancy "physics materials", but also because they had to make it work on a console, which is very strict on resource management, especially back then, even if they had something like physics materials, there would be too much clutter code they don't need taking up performance, physics/ forces translated into gaming isn't so hard to grasp, should get a course on it if you're really interested, you'll learn a lot ^^

    Cipher

  8. #88
    Join Date
    Apr 2015
    Location
    France, Paris
    Timezone
    GMT + 1
    Posts
    310

    Default

    Quote Originally Posted by Xpand View Post
    The ship rolling when it hits the wall in PSX is an animation and not a physics thing. They used center of mass physics for everything other than detecting collisions, so torque and other rigidbody rotation was impossible for them to do back then.

    Also you're using discrete logic when calculating the AG force (On collision, On trigger, etc). That can create infinite derivatives in the velocity (fig. 1), which translates directly into infinite acceleration, which is most likely why it glitches out. This has to be a continuous thing. The AG force has to constantly be calculated and active to get the best results.

    Figure 1.
    Sorry but I don't get what you mean with infinite derivatives ... for that weirdness I know the cause and I think I can fix it : hover expects a floor and there's none at this position, it starts falling down and suddenly hover recovers and make it jump as it's pushed away and retrieves the floor below it. I guess a plane representing each section floor will do or as laid out previously, a manual approach will obviously do.

    EDIT: I think I do understand what you mean, but what is your suggestion then for having a continuous representation ?

    - - - Updated - - -

    Quote Originally Posted by Cipher View Post
    ^That's a pretty good representation yes! ^^

    Forces is most likely the way they went, because they probably didn't have fancy "physics materials", but also because they had to make it work on a console, which is very strict on resource management, especially back then, even if they had something like physics materials, there would be too much clutter code they don't need taking up performance, physics/ forces translated into gaming isn't so hard to grasp, should get a course on it if you're really interested, you'll learn a lot ^^

    Cipher
    I'm too old for school, i.e. it's too late no but seriously, physics courses won't necessarily address translating this to programming which is a must; and honestly I'm not that much interested in maths/physics, like one does not need to know electronics to use a PC. I however understand that I will somewhat have to dive deep for this, I hope reasonably !

  9. #89
    Join Date
    Jan 2011
    Timezone
    GMT + 1
    PSN ID
    Apple-Guy-Cipher
    Posts
    1,922

    Default

    It's never too late to learn anything
    Translating it to code is rather easy, it's just vectors really

    Cipher

  10. #90
    Join Date
    Apr 2015
    Location
    France, Paris
    Timezone
    GMT + 1
    Posts
    310

    Default

    I can't really find any good resource on the web, would you suggest looking at books instead ?

  11. #91
    Join Date
    Apr 2010
    Posts
    1,529

    Default

    You're going to have to code your own physics, there is no way around it. You can try searching for stuff on introduction to Classical Mechanics for the physics stuff. Technically you don't really need to look for books, although the only fault I find in them is their price. The real issue here is knowing what to look for, and to be honest the physics needed to simulate an AG ship require a bit of understanding on forces and gravity, stuff like that.

    You can obviously go the hacker way and throw real physics out the window when you're coding, but you'll still need to know what's going on with the ship.
    Last edited by Xpand; 24th June 2015 at 05:50 PM.

  12. #92
    Join Date
    Apr 2015
    Location
    France, Paris
    Timezone
    GMT + 1
    Posts
    310

    Default

    While books are generally pricey, they take your hand from start to end; I personally really lifted my C# level years ago only after I did read a really good book on it. But I agree that they have downsides, there are many of them but I'd say that they are however most of the time better than those web tutorials ...

    Back to the topic,

    Do you think that I can still benefit from drag, angular drag, force and thrust from Unity's rigidbody, instead of coding my own ? I would however not use OnCollision* overrides which apply physics logic, but OnTrigger* overrides which only tell me who collided with who and leaves me free to code my collision logic.

    The thing is as you said, one has to know these topics, which is not my case, hence why I'm trying to rely as much as possible on useful bits in Unity. I've left my code sleeping for a bit and to be honest, my new approach with OnTrigger* is not that bad as it's pretty much like the original so I guess this is the right route, those OnCollision* interferences are gone, but only time will tell.

    Do you have a rough idea of how does physics work in the original game ?
    What's your opinion on it, do you think they use some real physics concepts or is it all faked ?

    thanks

  13. #93
    Join Date
    Mar 2014
    Location
    Moenchengladbach, Germany
    Timezone
    GMT + 1
    Posts
    11

    Default

    Also Supraleiter has a side-project called Rewipeout which can load WipeOut 1 and 2097/XL asset data, where we (the Supraleiter team) can tweak the Supraleiter physics against the original WipeOut 1 and 2097/XL tracks. Rewipeout has a complete own codebase except the shared physics code from Supraleiter. And Rewipeout will be opensourced later (as base for a sort of "ScummVM" for the first two WipeOut titles), when Supraleiter is released.

    The physics of Rewipeout and Supraleiter are, or better, will be a mixture of primarily the WipeOut Pulse physics and secondary of the two WipeOut PSX titles. You might ask yourself why WipEout Pulse primarily. The reason is simple, the WipeOut Pulse physics were very good described by a WipeOut developer in a game developer magazine from November 2005, so it is comparatively easy, to reimplement these physics as a start base for our own physics behaviour style.

    And here finally is also a video to Rewipeout:



    And for more infos to Supraleiter itself see the Supraleiter thread http://www.wipeoutzone.com/forum/sho...039#post244039

  14. #94
    Join Date
    Apr 2015
    Location
    France, Paris
    Timezone
    GMT + 1
    Posts
    310

    Default

    thanks for the heads-up about the magazine !

    seeing your video was a bit depressing for me a 1-man team with poor physics knowledge VS a team of 5 with strong physics knowledge is not likely to achieve any better; just started questioning myself whether it's worth I pursue this effort !

  15. #95
    Join Date
    Mar 2014
    Location
    Moenchengladbach, Germany
    Timezone
    GMT + 1
    Posts
    11

    Default

    Quote Originally Posted by aybe View Post
    thanks for the heads-up about the magazine !

    seeing your video was a bit depressing for me a 1-man team with poor physics knowledge VS a team of 5 with strong physics knowledge is not likely to achieve any better; just started questioning myself whether it's worth I pursue this effort !
    In this one team of 5 peoples I am the only one with the physics knowledge, the other guys in the team are mostly only content artists.

    But the basic implementation details behind (at least) WipeOut Pulse style physics are really very simple:

    What you do need as first, is a true aerodynamics linear velocity drag equation (a la http://physics.info/drag/ ), where the drags in the forward&side&up axes are not the one same common drag damping value, but rather, the forward-axis-drag should be the biggest, the drags for the side&up-axes should be lower, because the rest is then quite easy to implement and will come comparatively easy, specifically the previously difficult things with the previously most fake physics implementation approaches (I even had to learn that).

    And instead springs, I'm using soft constraints for hovering with five hover world meshtriangle/plane distance constraints to the track floor down (four on the down ship convex hull edge points plus one on the center of mass), since these are more stable and more easy tweakable than springs. For more informations to soft constraints: https://github.com/erincatto/box2d/b...onstraints.pdf

    So don't give up, try rather new physics implementation attempts Also I myself needed several tries before I got it reasonably, including several complete rewrites of the core general physics engine itself, not just at the game physics code implementation itself.

  16. #96
    Join Date
    Apr 2015
    Location
    France, Paris
    Timezone
    GMT + 1
    Posts
    310

    Default

    thanks for all the tips !

    I did read all the links you've provided and while I do understand why they are a better approach, I have no clue at all on how to 'code' these concepts.

    The drag-related topic if I'm correct would require writing physics from scratch, right ? If yes then it is beyond my competence at all as I can't even get a simple formula to code BTW why do suggest a different drag for forward, is it for coping with high speeds ?

    For the soft constraints, I've read the whole 50 pages documents and again, while I do understand its benefits I'm completely left off as on translating this to code, for the very few samples I've seen unfortunately I couldn't find any hint on where I could start digging on and eventually get something up ... I guess that would solve stability of a multi-points hovering I previously experienced; for now I just stuck to the unique hover point (ship nose) approach, which works relatively well.

    That lays out my physics programming abilities -> zero

    Unfortunately when it comes out to applying concepts in code there is little resource on the web, or I missed it.

    But I haven't abandoned !!! Up to now I've been able to overcome issues one by one though it takes quite some time so it's a bit heartening. I started splitting things up and refining things as much as possible, eventually over time an expert such as @Xpand might come in and give me a hand hope he succeeded in his exams

  17. #97
    Join Date
    Mar 2014
    Location
    Moenchengladbach, Germany
    Timezone
    GMT + 1
    Posts
    11

    Default

    Quote Originally Posted by aybe View Post
    The drag-related topic if I'm correct would require writing physics from scratch, right ? If yes then it is beyond my competence at all as I can't even get a simple formula to code
    No you don't need to do it. You must set just the physics engine own drag to zero, and then for every time step as first step:

    1. Get the current world space linear velocity of the current rigid body
    2. Transform the world space linear velocity into local body space
    3. Calculate the drag force vector with the drag equation formula Fd = 0.5 * p * u² * Cd * A on basis of this local body space linear velocity
    4. Transform the local body space drag force vector into world space back
    5. Apply the now world space drag force to the rigid body


    For example, in my own physics engine called Kraft the code (where x is side, y is up, z is forward) looks like this:

    Code:
    const FluidMassDensity = 1.29; // Air density in kg/m³
          DragCoefficient : TKraftVector3 = (x : 0.01; y : 0.005; z : 0.005);
          ReferenceArea : TKraftVector3 = (x : 1.5;  // Side area in m²
                                           y : 1.5;  // Top-view area in m²
                                           z : 1.5); // Frontal area in m²
    
    procedure DragEquation;
    var LocalFlowVelocity, LocalFlowVelocitySignedSquared, DragForce : TKraftVector3;
    begin
      // Code for the drag equation formula: Fd = 0.5 * p * u² * Cd * A (is actually dimensionless, but it is applied dimension-axis-wise here in this case)
      LocalFlowVelocity := Vector3TermMatrixMulTransposedBasis(PhysicsRigidBody.LinearVelocity, PhysicsRigidBody.WorldTransform);
      LocalFlowVelocitySignedSquared.x := LocalFlowVelocity.x * abs(LocalFlowVelocity.x);
      LocalFlowVelocitySignedSquared.y := LocalFlowVelocity.y * abs(LocalFlowVelocity.y);
      LocalFlowVelocitySignedSquared.z := LocalFlowVelocity.z * abs(LocalFlowVelocity.z);
      DragForce := Vector3ScalarMul(Vector3Mul(LocalFlowVelocitySignedSquared, Vector3Mul(DragCoefficient, ReferenceArea)), -(0.5 * FluidMassDensity));
      PhysicsRigidBody.AddBodyForce(DragForce, kfmAcceleration); // incl. back-transform from local body space into world space 
      // so it equals to: PhysicsRigidBody.AddWorldForce(Vector3TermMatrixMulBasis(PhysicsRigidBody.LinearVelocity, PhysicsRigidBody.WorldTransform), kfmAcceleration);
    end;
    
    // Vector3TermMatrixMulBasis is a vector-matrix-multiplication of a 3D vector and the 3x3 sub-basis-matrix (rotation part) of a 4x4 matrix
    // Vector3TermMatrixMulTransposedBasis is a vector-matrix-multiplication of a 3D vector and the transposed 3x3 sub-basis-matrix (rotation part) of a 4x4 matrix (faster than to inverse the matrix first, but it will work only for normalized orthogonal matrices without scaling (so rotation+translation only))
    Quote Originally Posted by aybe View Post
    BTW why do suggest a different drag for forward, is it for coping with high speeds ?
    Because the handling of the ship will be then more natural, especially the acceleration and braking, without affecting steering+rolling and pitch.
    Last edited by BeRo; 5th July 2015 at 08:29 AM.

  18. #98
    Join Date
    Apr 2010
    Posts
    1,529

    Default

    BTW why do suggest a different drag for forward, is it for coping with high speeds ?
    Because aerodynamic drag changes with the cross section of your ship that the airflow sees. When you're moving straight you're presenting the most aerodynamic part of your ship to the wind, but when you turn/drift you start presenting a less aerodynamic section (the ship's side) and that increases the drag, reducing the ship's speed in that direction. That helps with handling as it stops your ship from drifting sideways a lot. Although you're going to have to exaggerate the effect of aerodynamic drag a bit to get noticeable effects in a short distance.
    For example: A ship turning 90 degrees:
    I only plotted one axis of the drag vector to understand how its components work. In reality the whole vector would be aligned opposite to the velocity vector.

    And so on until the velocity vector is pointing completely to the left of the image, which then the red drag component pretty much disappears.
    Last edited by Xpand; 5th July 2015 at 08:17 PM.

  19. #99
    Join Date
    Apr 2015
    Location
    France, Paris
    Timezone
    GMT + 1
    Posts
    310

    Default

    @BeRo : thanks, I've been trying to apply your code but there are a couple of things I've encountered :

    What is ReferenceArea supposed to be, the dimensions of the ship ?

    When I apply this code right before moving my ship and with the default value of DragCoefficient, it acts like being in the vacuum of space; I guess this is correct since they are low values. However I've tried to apply the same amount of drag I used to have (1.0f) and things start to fly instantly ! I guess there's something I've missed or I'm mis-using ...

    I've checked multiple times whether I'm calling the right functions in Unity compared to your code and I guess I do but here is it anyway:

    Code:
            public Vector3 DragCoefficient = new Vector3(0.01f, 0.005f, 0.005f);
    
            void UpdateDrag()
            {
                var rigidBody = GetComponent<Rigidbody>();
                rigidBody.drag = 0;
    
                var fluidMassDensity = 1.29f;
                var dragCoefficient = DragCoefficient;
                var referenceArea = new Vector3(1.5f, 1.5f, 1.5f);
    
                var localVelocity = transform.InverseTransformDirection(rigidBody.velocity);
                var localVelocitySignedSquared = new Vector3(
                    localVelocity.x * Mathf.Abs(localVelocity.x),
                    localVelocity.y * Mathf.Abs(localVelocity.y),
                    localVelocity.z * Mathf.Abs(localVelocity.z));
                var dragForce =
                    Vector3.Scale(localVelocitySignedSquared,
                        Vector3.Scale(dragCoefficient, referenceArea))
                    * -(0.5f - fluidMassDensity);
                rigidBody.AddRelativeForce(dragForce, ForceMode.Acceleration);
            }
    @Xpand thanks for the nice drawing, it makes things even more clear !

  20. #100
    Join Date
    Mar 2014
    Location
    Moenchengladbach, Germany
    Timezone
    GMT + 1
    Posts
    11

    Default

    Quote Originally Posted by aybe View Post
    @BeRoWhat is ReferenceArea supposed to be, the dimensions of the ship ?
    The reference area is in the most cases the to 2D projected area of a object to a axis view.

    There are several ways to calculate the area per side (from top view, front view and side view) of your ship.

    • This first damn simple but not so exact way is to simply measure the projected 2D area height multiplied by the projected 2D area width and then take 85% of it. A = (width * height) * 0.85
    • A other still simple way is to overlay a grid over the projected 2D area, where you determine the area of one grid square cell by counting the number of grid square cells in a given measurement (height or width). Once you've determined the area of one grid square cell, you just need to count all the grid square cells touching the ship and keep track of whole and half grid square cells to get the total frontal area.
    • A other more exact way is to calculate the 2D polygon area of the to-2D-polygon-converted 2D projected area of a side of your ship. The to-2D-a-top/front/side-view-projected triangles can merged to 2D-polygons for example with http://www.angusj.com/delphi/clipper.php which exists also for C#, and then calculate the area of these 2D polygons...
    • ... or you can do also just the more simple way (when you're lazy :-) ), where you calculate just the area of the 2D projected triangles itself and then sum these to a reference area value for a side/front/top-view, but this more lazy way is not more exact then, because of overlapped and intersected triangles.
    • and there are many more another ways....


    So there isn’t just one way of doing it :-)

    And you should play also with the DragCoefficient values with the trial-and-error method, since these are also not always universally for everywhere valid respectively suitable.

    For more good informations you can read https://en.wikipedia.org/wiki/Drag_coefficient.
    Last edited by BeRo; 5th July 2015 at 08:52 PM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •