I advise you to follow some tuto on youtube. That's how i get started. Unity seems to be a little bit intimidating at start but it's actually pretty easy.
About you debug issue : why don't you use MonoDevelop?
Printable View
I advise you to follow some tuto on youtube. That's how i get started. Unity seems to be a little bit intimidating at start but it's actually pretty easy.
About you debug issue : why don't you use MonoDevelop?
Ok, I've got something on screen, have a couple of things to do before rendering a track, stay tuned ...
EDIT
I'm getting familiar with the thing and it's pretty good though it crashes from time to time ... re-used most of my low-level classes with little to no changes, in probably 2-3 days I'll have something up (hopefully) :D
To be continued !
Attachment 9500
Here's some more Unity treats :P
Attachment 9502
Still fighting a bit with Unity tutorials but now on the track to get busy with physics :blarg
Good progress :hyper
Is it Altima VII ? if yes, it seems the whole track is flipped around the X axis.
- - - Updated - - -
trivia : on DEMO01 CD (official demo CD delivered when PSX comes out), there is a Wipeout demo.
The CD had to be ready before the game was released so Wipeout was probably still in beta stage.
In "Wipeout" folder, on CD, there is TIM files (textures) that does not look like regular game textures but rather from an editor for the game.
Why TIM files ? was the game developed on machine similar to the PSX itself ? or was the editor running directly on PSX ?
Here is a screenshot of them and my comments (this is pure speculation from me)
http://s2.postimg.org/pm1gxym61/editor.png
BOOM, BOOMW: an unfinished weapon icon ?
BUG : call technical support ? :)
CAMERA : probably allow to define cameras along the track
CHNGTRK : edit track faces textures ?
DPA: ??
EBOLT, ECM, ELECT, FLAR, MINE, MISS, NEG, ROCK, SHLD, TURB : related to bonuses. in the first ever wipeout, were the bonuses placed directly on the track (instead of a "X" cross ?). Or is this to view bonus 3D models ? or to test debug (because the editor run "in game") ?
HALO : ?
EMPTY : ?
LNDONOFF : to switch the land (the scene objects around the track) on/off
RADIUS : to define bounding spheres around scene objects, for occlusion culling.
SAVE : pretty obvious. suprisingly there is no load icon :)
SHIP : to set start position of the ships, or to view 3D model ships in game ? AFAIK, the ships start positions are determined by texture indexes on track (to confirm)
SKY : turn skybox on/off
SMOKE : to add some smoke particles ? (as seen in talon's reach )
TRAKVIEW : track visiblity on/off ? or is it related to VEW files ? (to view actual culling performed at a given position?)
TRANSTRK : to edit track structure ? (eg:extend track on the side, create a tunnel,...)
VRAM : PSX vram debugging (eg : to view loaded textures, actual framebuffer ? ...).
Some of those images seem to be part of some developer's debug menu. It isn't rare for developer tools (eve if it's just some part of them) to be left in the final game's files.
Those files are also in the final release version of the game.
I did not know that. I would be cool if it was left there and it would be possible to reactivate it.Quote:
Those files are also in the final release version of the game.
Anyway the exe seems to not reference any of these files (while the other seems to be referenced) :/
So either there was two EXE's files, or there was two builds (compile switches)
And they are also in the PC version, can't remember exactly where ... and yes it's Altima VII.
I've been trying to get hold of this ptiDebug variable on the disassembly in hope this infrastructure was still in place and could be triggered but without much success :paperbag
Bit of progress in Unity:
I have a ship that moves and hovers now ! but it can leave the track very easily :g
I need to get hold of how to constraint it close to it as well as the angles as it can become reversed ... any clues are welcome :D
What we did for slipstream GX was to basically override Unity's physics regarding rotations and gravity. We use rigidbody components on the ships with frozen rotation and no gravity. The rotation in each axis is then calculated with a script, same with every force on it. That gives a lot more control over the ship.
It'd be a good start to look at the forces in action on a plane, because it's exactly the same thing:
https://howthingsfly.si.edu/sites/de...sna-1_lg_0.jpg
I was going to post something but Xpand was faster than me :hyper
Here is my two cents :
- either constraint rigid body movement (eg : rotation on X/Z axis) so it wont happen. check rigidbody panel properties; some movement (eg : roll) can be purely visual. to do this you can add ship model inside another parent object and rotate only that one. this is probably Xpand direction (no joke here :P).
- (or) apply a stabilize force (torque) that make sure the ship is always up right. you need measure the difference between actual ship orientation and a target orientation and apply a force accordingly. (like a putching ball)
something like this : http://answers.unity3d.com/questions...l#answer-10426. Might be unstable or unable to handle violent collisions.
Thanks :clap :clap :clap trying to apply your suggestions !
The plane analogy is really great and it seems the way to go as well as constraining rotations.
I have some sort of a plane for now, it does lift off a bit like WO does but it's really naive ... found a plane sample that I'm trying to pick ideas from.
A rough guess is that such kind of physics would more or less give what's needed like aero brakes and so on.
But I've never done any physics as of yet so this is likely to take a bit of time :blarg
Here's a code snippet of an Anti-gravity physics engine I'm programming in C:
This takes care of the vertical portion of the forces on the ship:
the K/(A+fabs(height)) bit does the AG magic, making the ship float around a certain height above the ground. I can make the ship float higher or lower by increasing or decreasing "K" and make the ship respond more or less to the variations of the track by adjusting the "A" parameter (and also avoids that whole thing becoming infinite when the height is zero).Quote:
player->acc.z=player->gravity+(20.0/(0.1+fabs(player->pos.z-player->proj.z))-player->vel.z*player->vel.z*player->vel.z*2.0)/player->mass;
The three velocity components vel.z take part in damping the ship's wobble. It's basically the drag force present in that airplane diagram, only in the vertical axis. It's there just so the ship's oscillation decays with time.
I remember I wrote (some months ago) a game similar to wipeout with a constant force to be applied from the ground. This was prototype wrote for testing only.
The vertical push force was not stable and wobble a lot. I solved this by using a simple PID controller :
Code:distance_target = 5.0 //we want object to be always 5 units above the floor
distance_to_ground = cast a ray from object to the floor
error = distance_target - distance_to_ground
derivative = error - last_error
// kp and kd are constants to be adjusted (stability vs speed)
force_to_apply = error * kp + derivative * kd
last_error = error
Thanks everyone :D This comes in really handy and I hope I'll be able to apply all these tips, I sort of found a couple of decent links yesterday about all this but I still need to read them. I'm quite confident that I'll get to it ... one day ! This is an entirely new topic to me so it's pretty much sound like Chinese to me for now. :bomb
this works really well :+Quote:
Originally Posted by tigrou
@Xpand still trying to digest your formula :pizza
Well it uses real physics (I'm a physics engineer, so I guess that might have something to do with it), hence why it seems more complicated, but it's nothing more than the forces that would exist if the ship existed in real life, with a bit of tweaking for optimization.
The main thing to retain is the "K/(A+fabs(height))" bit, which is basically the equation for the upward force created by a compression spring (like car springs), and the vel.z^3 works as the damper in a car's suspension.
Basically what I have there is:
acceleration in Z axis = gravity + (lift_force+damp_force)/mass
Tigrou's method is best for performance on the long run though, I'd use his idea if I didn't want to waste too many resources calculating the ship's behaviour (although my method doesn't take that much more, it's just because it uses a division operation), or if I wasn't too worried about how accurate the floatiness would be (mine takes into account the ship's mass (inertia) and gravity)
I'll definitely give a try to your method, it's just that it takes time for me to understand this new topic :brickwall
That's about 2-3 days now I'm on the physics thing and I guess it's going to take quite some time by now, I am confident however !
Here's my little training field : :D
Attachment 9506
- - - Updated - - -
I haven't been able to reproduce your snippet :brickwall
I don't understand whatCode:var gravity = Physics.gravity.y;
var zPos = carRigidbody.position.z;
var zProj = 0;
var zVel = carRigidbody.velocity.z;
var mass = carRigidbody.mass;
var zAccel = gravity + (20.0f / (0.1f + Mathf.Abs(zPos - zProj)) - zVel * zVel * zVel * 2.0) / mass;
is supposed to be.Code:player->proj.z
Also, I might have missed something but, how does this works against Y axis since you never update it ?
thanks :g
(as you might have guessed, I lack complete knowledge about the subject topic :D, right now I'm still on the phase of copy/paste/run )
I'm so sorry, I just copied that from my engine, which uses that variable to get the height of the ship above the track (it calculates proj.z from the projection of the ship's X and Y position on the mesh triangles of the track to get the distance of the track's surface to z=0). It's native to my engine, and not a generic thing (you don't need to use it).
In sum: (pos.z-proj.z) is "height":
K/(A+fabs(height))
You need to tweak the numbers to your liking, hence why I wrote K and A, they're just numbers you choose.
Also in my case the Z axis is vertical. It might not be your case (just change it to the Y axis).
Okayyyy that's what I just thought and been thinking it was a trap you just set for me :D
I have been able to get some cool results, but it's kinda hard to really understand how the thing works without proper context. Basically for both of your suggestions, they are applied when a ray cast hit is true and then I apply that force to the car (I guess it's correct since both formulas are working).
But your formula brings in 2 other interesting properties : it gets affected by mass and drag (defaults of 1.0, 0.0) while @tigrou's formula is not ... it's like in the Universe -> you discover 1 thing but there are newcomers ... I guess I'll have to document myself a bit more on the overall subject ! This just got me for today but I'll see tomorrow.
Also, I hate those non evocative variable names usually found in math formulas (K, A) but I reckon it's the usual approach. I've been trying to come up with ones a bit more meaningful : stiffness and feedback but this is pure speculation from me. Would you qualify them as such ? thanks :D
K is stiffness, higher K makes the ship float higher and makes it harder for it to hit the ground. A is the "give". It's kinda hard to find a word for it. "A" basically determines how violently the ship will react when its height approaches 0. If A=0 then as the height approaches zero, the lift force will tend to infinity, if A=0.1 the lift force will be K/0.1 when the height=0. It provides control to avoid very larger force values that will make the ship shoot up to the sky if it hits the track.
By the way, since Unity already simulates drag, you don't need to have the drag portion of the equation there (the vel.z*vel.z*vel.z), I had to add that because my engine assumes drag is included in the acceleration equation and it's not a separate thing.
@Xpand : interesting.
The formula I give (PID) is a general purpose method. This can be used to control systems using a feedback loop (with stability and precision to a certain degree).
Some specific formulas that model concrete physics models (like the one you give), might, however, work better or be more precise.
I would not care too much about CPU performance on today computers. This should not be the bottleneck. I would simply choose a method that can be tweaked easily and give the best gameplay. That is the most important aspect to me.
About the formula you give :
"K/(A+fabs(height)) " and also " vel^3 " where does this came from ? do you have any reference, paper, wiki page? (for learning) i'm (unlike you) not a physical engineer :redface:
I took a look at Hook formula, but it seems to be not that thing.
about "dividing the force by mass", it came from F = m a right (pretty basic stuff :D)?
Yes, you divide force by mass to get acceleration, like Newton's 2nd law states: F=mass*acceleration
about the K/(A+fabs(height)), it's a cheat that comes from, for example, the electrostatic force between two charged particles: Fe=Ke*charge1*charge2/(r^2), which states that the repulsion/attraction force between two charged particles is proportional to their charge and inversely proportional to the square of the distance between them (as distance increases, the force decreases). I just considered "Ke*charge1*charge2" as "K" and since I wanted to save some processor cycles I used the absolute value of the distance between the track and the ship fabs(height) instead of calculating its square. I added the "A" to avoid problems with division by 0, like I stated in my previous post.
The vel^3 (cube power of the velocity) comes from the aerodynamic drag equation:
http://upload.wikimedia.org/math/9/9...7b238e5de9.png
all those variables have a meaning you can see here: http://en.wikipedia.org/wiki/Drag_%2...#Types_of_drag I just made them all "2.0" for now.
I know it says v^2 in that equation, I used v^3 because I want to take into account the sign of the velocity (if it's negative or positive), so the force points opposite to the movement of the ship. I can use the v^2 just like that equation, but then I have to multiply by v/abs(v) to get the sign of the force (v/abs(v) can be -1 or 1), but again, to save processor time and avoid divide-by-0 problems I just used the v^3.
The PID method is good for setting variables that you can consider independent, like temperature in an oven, position of a mechanical arm, etc. For something that requires other stuff to characterize it (like a force), the PID leaves out those important variables and treats the force as an independent thing (when it isn't). Because this is a game PID would probably be a better choice than doing a physical simulation of the whole thing due to its simplicity, and I'm pretty sure they used it in the first Wipeouts. When rigidbody physics come up, you get stuff that depends on other stuff and differential equations everywhere, and PID just doesn't cut it.
You guys rock, Amazing how much work .. I checked all your formulas, :dizzy :eek , yes,yes it's all right :g lol
Surely velocity cubed would make the drag parameter unphysical/unrealistic? Would it not be better to define a Heaviside function using logic to ascertain the direction of the drag e.g....?Quote:
Originally Posted by Xpand
if (v < 0) {
sign = -1;
} else {
sign = 1;
}
and therefore have your velocity squared again.
Oh indeed. I forgot about that function (which is weird because I use it so many times in other stuff)! Thanks!
The velocity^3 would be unrealistic in the sense that the dampening would happen a lot faster than with v^2. Which isn't necessarily a bad thing, but yeah its real world equivalence is the drag Power and not the drag Force: http://upload.wikimedia.org/math/e/3...82a89503b1.png
Things are stalling over here ... :frown: @Xpand I've somehow tried to 'upgrade' your code with a hover distance but failed miserably, I've also looked at 'hovercraft physics' on the web and got a cube to hover manually, then I tried to use that PID approach on it but again I failed ...
Also I've been looking at thrust/torque, while I can move and turn fine another problem surfaced : it never stops since I'm not on the ground ! Applying a physic material on the rigid body obviously did nothing...
Just to make it clear : should I completely bypass Unity's physics system and think of everything or are there are physics-related things you'd keep on ? (beside constraining X and Z rotations)
thanks !!!
You just need to constrain the rotations, because you'll have a rolling ship everytime you enter a banked corner otherwise.
For the linear movement just use the AddForce command in Unity: http://docs.unity3d.com/ScriptRefere....AddForce.html
Also use the rigidbody.drag property so your ship doesn't accelerate without limit and slows down when you stop accelerating.
The rotations you have to work with angles directly and transform rotates.
Ok I'll give it a try and post my results ! thanks !!!
EDIT also, I found that script posted by the BallisticNG author and this is really a good hint; however it cannot be a simple copy/paste, will have to digest those 900 lines and hopefully I'll have something solid !
- - - Updated - - -
Works very well, victory :rock
Next step is to try upgrade your script with hover distance :D
When I get comfortable enough I will start looking at sources of BallisticNG and AGR2280 !
I love the look (graphics) and feel (physics) : https://www.youtube.com/watch?v=zuy9sryZSIc
It is very PSXish (it is intended I guess)
Now imagine being able to play this with all W1 & WXL tracks :hyper
EDIT : oops, seems it is discussed on this forum : http://www.wipeoutzone.com/forum/sho...project/page13 :redface:
Yes it's pretty good but it runs way too fast, I can't stop hitting walls ! There should be some Vector class IMO :P
@Xpand
here's the situation here:
I've been striving to do some of the ship physics all by myself, from scratch :D
Using 4 hover points, an angular drag of about 20 and not constraining the rotations : the thing is quite 'okay' in the sense that I've got an automatic leveling to the surface below myself and it's quite realistic. But there were 2 major issues occurring then : this was undesired when on edges of the track and whenever on air the ship was not leveling to the horizon or whatever.
So I began trying address the 'on-air' issue but it just seems that in the end, to get an 'enjoyable' game one has to resort to all kind of hacks (understand here not rely at all on physics provided by Unity), just like the BallisticNG ship controller code that has been posted recently on the forum.
My question is : is this really the way to go or is there a slight hope in getting cool craft physics using the facilities provided by Unity ?
thanks :D
Enjoyable gameplay is indeed riddled with hacks. You have to "bend" the physics engine to your will, and do some trickery for it to do what you want. That happens in pretty much all games.
I kind of forgot there were programming patterns recently as I was quite amazed by Unity, but that definitely makes sense.
Okay, I'll just base myself on that BallisticNG ship controller code then and see if I can improve/tune it to my needs ... thanks :+ :+ :+
@aybe : can only agree with Xpand.
About your hover issues : have you tried the following : when you shoot rays against the track, you do it against a special collision track 3D model that has only the "ground" track faces set (these faces have a special flag in the TRF file). These are the one that rise up/down quickly when you use the "Quake disruptor" weapon. Only these faces should be considered when calculating ship/floor distance or actual track orientation.
BTW, you consider ALL track faces when performing regular colisions, because you want don't want ship to go out the track.
To avoid issue with gaps : if a ray does not collide with anything, simply take the latest valid result (that you keep somewhere) :
or you might consider another approach : the idea is to always have a 3D track orientation for any given ship position. I supsect the original game to do something like that since it's quite easy to calculate. Not need to shoot rays. Here how to do : you loop trought all track sections, calculate the one which is the nearest from the ship (by calculating ship/section distance). Once you have the nearest section, you calculate the normal vector of that section (easy and could be precalculated before and stored). This is the actual track orientation and the one the ship should have. Even if the ship goes out off the track but continue moving forward) you still get a 3D orientation.Code:if(ray.hit(..., out result))
{
lastValidHit = result;
}
else
{
//oops, there is a gap, take latest result
result = lastValidHit;
}
//do something here with "result"
...
To avoid brutal changes, you can smooth that out using an interpolation method :
instead of using 4 push forces, you might consider using only one (at center of gravity) and actually rotating the ship by simply applying a torque to the rigid body (so that the ship is always more or less oriented like the track).Code:var orientation = to calculate...
smoothorientation = Quaternion.Slerp(smoothorientation, orientation, 0.7f); //between 0.0 and 1.0
Thanks everyone, going to give all your suggestions a try !
Bit of a deception here, I thought those 3D frameworks would provide a smarter approach but that seems to apply only when it's fully featured in regards to realistic physics. I guess that BEPU physics is a little more featured but not sure it outweighs the facilities of Unity ... I might give it a try later though as what seemed to be tough is a bit clearer now -> I'd just have to follow that composition pattern of Unity.
Basically at this point it's a simple copy/paste operation, still I'd like it to be a bit more than that ... still have a few links to read and also look at the AGR2280 and I think I'll get started. (and the TRS format as well since I've never used it yet, just seen that debug path in the experiment)
Bit of progress here !
- I separated concerns of model and controller
- tried that hovering/leveling again from scratch and it seems it's a better route -> leveling is coherent and it is now unaffected by a tunnel whereas previously it was going crazy (@tigrou seems like I'll need your air tip at some point !)
- also hitting walls is coherent as well though it will certainly need a different physic material to behave like the original game
- edit : I do constrain rotations now
The simplest approach works the best !! The feeling is definitely Wipeout-like when the ship raises/lowers its nose, will need a few magic values later.
For BallisticNG code however, I've abandoned for now as it's too early, I'll certainly take higher-level hints from it but at this point I was not feeling that simply fixing the errors will do the job, plus many constants were missing as well.
So a little victory but definitely more positive than the stalling of last days :D
Quick update to let you know what's going on:
- cleaned out the classes and now have separate layers for the walls and the ground -> prepped the thing for easier usage
- got some sort of DIY prototype with hovering, pitching, airbrakes, sections and so on, though wall hitting was not right
But I've just started porting the Ballistic NG code :g Been able to guess the missing constants for now, got the hovering and thrusting, still a lot remains to be done. I'm trying to understand the thing a bit at the same time, I kind of went the same route on my own but it was way less tuned ... I should have some solid physics within a few days, hopefully :D
Go go aybe!
Here is a video of the 1st prototype ! :rock
https://www.youtube.com/watch?v=0hVcILbw4tw
There are still a few issues but the main substance is here, I've been studying the game and tried to mimic its behavior as close as possible.
I've abandoned using code from BallisticNG and AGR2280, problems being that the 1st is incomplete and misses many things, the 2nd while fully available I could hardly find anything to grasp from it (you might disagree). The copy/paste of snippets worked at first but later went problematic, I guess all should be in but I did not feel taking this route :blarg
So what you see above is my DIY approach, different by a couple of aspects, done by a physics newbie not constraining rotations, letting the engine do its job and try to cohabitate with it instead of bending it; over time I got something relatively stable ...
Let me know what you think about the video !
I have a couple of questions for you guys if you can give some hints:
- how to make pitching more reactive when going down the long air-jump ?
- how are on-air periods approached, is it by using a stronger gravity ?
- how to add the user's free pitch and make hovering aware about it ?
- proper airbrakes, is it just torque+slowdown or does horizontal force should be considered too ?
- high-speeds can still make the ship pass through the ground when landing, even with continuous detection
Thanks :D
EDIT: website secured @ http://wxx-rebirth.com/ :p
@aybe :
This is great, lot of hard work so far. Please continue like that...
There still many things to fix until it really feels like the real game but the gates are now open
I take a look at your questions later on, when i will have some time.