Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

999641 Posts in 39235 Topics- by 30649 Members - Latest Member: 7yp

April 24, 2014, 02:01:18 PM
TIGSource ForumsRecent Posts
Pages: [1] 2 3 ... 10
 1 
 on: Today at 01:59:30 PM 
Started by Tumetsu - Last post by C.A. Silbereisen
http://blog.metaclassofnil.com/?tag=gedosato

 2 
 on: Today at 01:57:09 PM 
Started by GregWS - Last post by Gimym JIMBERT
BRILLANT

 3 
 on: Today at 01:50:30 PM 
Started by dangersam - Last post by dangersam
Another long gap between updates I'm afraid!  I thought I'd gotten through the last of the really tricky physics issues once I'd sorted the gears, but oh no...  Over the past month I've been battling through a bunch of problems with wheel physics, but I finally have a solution that I think is satisfactory (albeit at some performance cost unfortunately, as I'll explain later).

There are two things to deal with when two physical objects contact each other (in this particular case, a wheel, and the ground), these being collision and friction.  In Unity, you'd normally just attach colliders to your objects, and leave it to PhysX to take care of it all, but this is not particularly well suited for wheels.  First of all, there are no colliders available that properly match the shape of a wheel (i.e. a cylinder), and that also roll smoothly across the terrain, really the only options are a sphere or capsule collider.  Secondly, you don't have enough control over friction, which is particularly important for wheels / tires.  Unity's built in wheel collider is a specialised solution that includes a spring / damper model, and must be attached to a vehicle chassis, not directly to the wheel itself, so it is not suitable for my purposes.


Various attempts

I tried several approaches to deal with the wheel to ground collision and friction response, which I'll briefly go through now.

Built in collider

Until now the wheels had been set up to use a capsule collider, but this doesn't conform to the wheel shape, the capsule ends stick out of the wheel itself which means the wheel can't tilt over properly while contacting the ground.  I even tried using a mesh collider to approximate the cylindrical shape of the wheel, but because it is faceted it doesn't roll smoothly across the ground.

Raycast to find ground contact

Given that using a built in collider wasn't going to work, the first thing I had to do was find the wheel's contact point with the ground for myself.  To do this, the wheel fires raycasts towards the ground (perpendicular to its rotational axis) to find a contact point and normal.

Custom constraint solver

I implemented a constraint solver that resolves the collision by calculating an impulse along the contact normal to push the wheel away from the ground so that it doesn't penetrate.  It also finds an impulse (tangential to the ground contact) to resolve friction, using a simple Coulomb friction model.  Essentially, exactly what PhysX does internally to resolve contacts, except now I'm able to use my own contact points.  This took a while to code up as I had to brush up on my physics knowledge a fair bit, it's very easy to screw things up and introduce energy into the system if you're not careful!  Once I got it sorted though, it worked great, the wheel rolled smoothly across the ground, was able to tilt over properly, etc.

However, there was a problem, with heavy constructions the wheel would sink into the ground and spring back out.  This is actually a similar issue to the laggy springiness my gear constraint solver suffers from.  I think it's because my solver update runs independently of the PhysX internal solver updates, and so doesn't get a chance to properly "compete" with the built in constraints (joints etc.)

Configurable joint

So, rather than use my own constraint solver, I tried to recreate it using a configurable joint (as available within Unity), connected to the wheel's rigidbody.  Every update the joint gets repositioned above the ground contact point, and has a linear limit set up to prevent the wheel going below the ground, thus providing the collision response.

For friction, the configurable joint's velocity drive is set up to force the ground relative velocity (tangential to the ground contact) to zero.  This alone would result in essentially infinite static friction, so a maximum impulse is set on the drive.  As per Coulomb, this impulse clamping needs to be based on the contact normal impulse.  However, there's no way to find out what impulse PhysX is applying to constrain the wheel to the linear limit, so what to do?  In the end I had to estimate it by using the approximate mass over the wheel and the force against gravity along the contact normal.  Kludgy, but it'll have to do.

This solution worked nearly as well as the custom constraint solver, and without wheels sinking into the terrain, so was the one I settled on.  The only downside of this method is that when you have a lot of wheels, the configurable joints seem to incur quite a noticeable performance cost.


Hopping wheels and sagging joints

The wheel collision and friction were not the only issues to deal with.  A problem I found a while ago after adding the servo part and using it in the game to build cars with steering, was that during cornering, the lateral forces would cause the wheel (or rather the hinge joints connecting it) to flop over.  It would then lose contact with the ground, snap back, gain contact again, and so on, causing the wheel to skitter and hop across the terrain.  Also, if the construction was heavy, the joints attaching the wheels would sag under the weight.

I tried to think of ways of forcing the wheel to remain vertical to the rest of the construction, but because the player is free to build in whatever way they want, I have no way to know which direction a wheel should be constrained in.  To be honest, the physics engine isn't really designed for what I'm trying to do, normally you wouldn't model vehicle physics with joints and rigidbodies for all the moving parts, instead you'd build a specialised vehicle physics engine.  For my game I can't do this though, as players construct the vehicles themselves in game.  In the end the only fix I was able to come up with was to increase the physics solver iteration count, which has the effect of tightening up the hinge joints and lessening their sloppiness.  This comes at the cost of a significant performance hit though unfortunately.


The build is now updated with the new wheel physics so you can try it out!  I've also added a wheel skid sound effect, and fixed a bunch of bugs, including a pretty major screw up with the rigidbody mass properties update that I've now sorted.

 4 
 on: Today at 01:48:12 PM 
Started by gerardrallo - Last post by MAVW
Looks amazing! I saw the video before and I felt exactly how you described, I had no idea what was going on but felt compelled to play hahah. Too bad I don't have an Ipad to play :/
Good luck with your game! Has a lot of potential  Smiley

 5 
 on: Today at 01:46:33 PM 
Started by Schilcote - Last post by Mittens
I don't like when encounters just happen from random chance (like while in the grass in pokemon)

I much prefer when you can see the enemies you will encounter moving around (like in Mario RPG)

I also don't like that encounters often transition you to a new kind of chessboard environment, I always wanted to see a JRPG where the encounters happen on the same map as the one you travel around in

I am also yet to play a JRPG where the combat moves happen simultaneously instead of one after another.
Why not choose an action for every member of your party, have the enemy choose theirs then play them all out at once?

I don't like when a players party gets amalgamated into their ass, I much prefer party members be like pikachu in Pokemon yellow and physically follow you around

Aaaaaand that's all I can think of for now

 6 
 on: Today at 01:45:58 PM 
Started by Tumetsu - Last post by John Sandoval

 7 
 on: Today at 01:44:31 PM 
Started by Nate Kling - Last post by Rabbit
Too subtle of a movement for as few frames as there are, so it really stands out when it hits those frames. I think itd be better with more frames or you just make the overall movement a bit bigger.

 8 
 on: Today at 01:42:52 PM 
Started by EminenceRev - Last post by EminenceRev
Introducing Qinglong - Guardian of Judgement and the final card of the Ixion Division.


 9 
 on: Today at 01:38:33 PM 
Started by Tumetsu - Last post by Rabbit
Soul Memory is every soul you've ever earned, spent, lost, or otherwise.

EDIT: dammit Zach

 10 
 on: Today at 01:38:18 PM 
Started by TGoCoGames - Last post by TGoCoGames
Hey everyone,

Germán Gaussmann, the amazing animator for Diesel Tactics, has put together a sweet animation reel for the Conveyable Matter Liquefier Specialists unit from the Usonian army and I’m showing it off today!

These guys are a particularly devastating offensive unit against other infantry squads because their flamethrower attack hits all members of the enemy unit!  Most units have 3 squad members, and generally when a unit makes an attack they get just the one attack, but these soldiers get one attack per enemy squad member!

For example, if an enemy unit has a full complement of 3 soldiers, and the Conveyable Matter Liquefier Specialists have all 3 members alive as well, they would make 9 attacks against their opponent!

We’re considering changing this system a little though, and any feedback you guys might have would be great!

Okay here’s what we’re currently doing: squad of 3 attacks squad of 3 results in 9 attacks, just like I described above.

What we’re thinking of doing: squad of 3 attacks squad of 3 results in 3 attacks on each enemy squad member individually.  What I mean here is that we don’t just pool the attacks and remove that number of enemies, but instead check to see if any given member is killed.

Here’s an example of what I’m talking about: if you use the current system and make 9 attacks and the last 3 attacks result in a kill, then all three enemies are killed.  If you divide up the attacks and the last 3 attacks result in a kill, then only one enemy is killed since those attacks were all specifically against the last enemy squad member.

To show the difference, let’s say each attack has 25% chance to kill enemy squad member. 
Version 1 with 9 attacks results in 2.25 deaths on average.

Version 2 has a 64% chance of killing any 1 enemy unit member. 

The odds of killing exactly 1 would be about 25%, the odds of killing exactly 2 would be roughly 44%, and the odds of killing all 3 would be 26.2%. 

Finally, the odds of killing no one would be about 4.66%.

The math:

Odds of killing any given enemy: (1/4) + (3/4)*(1/4) + (13/16)*(1/4) = ~64%
Odds of killing no one: 0.36^3 = ~4.66%
Odds of killing exactly 1: (3!/(2!*1!)*(0.64*0.36*0.36) = ~25%
Odds of killing exactly 2:(3!/(2!*1!)*(0.64*0.64*0.36) = ~44%
Odds of killing all 3: 0.64^3 = ~26.2%


What do you guys think?

Whatever we go with, these guys are going to be incredibly dangerous when they get close to the enemy!

Check out the animation reel here!

Pages: [1] 2 3 ... 10
Theme orange-lt created by panic