Faux Gravity and other stuff

Ok I’ve got the Faux gravity scripts and I’m trying to make a wipeout style craft go along a track with gravity set the the track.

My problem is that it seems as though gravity is just set towards the center of the attractor objects which is great for stuff like spheres but not so great for a track.

I’m also trying to make the craft hover, my first attempt was just attaching a box collider to the bottom of the craft and setting it’s friction to 0 but this produced some jittery results, I’m not really sure how else to do it, I tried using a raycast and adding a rigidbody force whenever the 3 unit ray hit the ground but this caused the craft to jump in the air too much rather than just hover. If anyone has any thoughts as to how I could do it that’d help!

I’m just pulling my hair out over a lot of this stuff, especially with uni assignments due in soon too :S.

Anyway any help would be greatly appreciated!

Ok new problem, I’m trying to get the hovering vehicle to just rotate so that it’s the normal of the surface of the track, however for some reason the normal is coming back as (0,0,0) regardless of wether the craft is on a slope etc.

:S

Ps I know that the “transform.localRotation.x = hit.normal.x;” is prolly wrong, I’m just trying to et it rotating in any direction in regards to the normal at this point.

Thanks
Adam

Garhhhh Ok, I’m just going to list the things I’m stuck on at the moment.

  1. Getting the craft to hover. What I’m currently doing is using a raycast and if the ray hits anything the applying a upward constant relative force to the hover craft. The problem is then going up a hill the craft still bumps into the track and it also jumps a bit then the raycast goes over the distance and normal gravity takes over.

  2. I’m trying to get the craft to rotate, however I’m really stumped as to how to go about doing this. I’m thinking about putting a raycast on the front of the hover craft and having it rotate if the ray hits the ground, however I expect it’d be just as “un- realistic” as my attempt to make it hover.

  3. I’m using the iPhone to turn the craft, the good news, the craft does rotate, however when it is moving at any kind of reasonable speed, turning becomes impossible, as the force built up in one direction makes turning to go in a different direction very difficult, anyone got any ideas as to work arounds for this?

  4. I’m also trying to get the craft to cling to the track, I tried using the faux gravity scripts however it resulted in the craft flying off the track (I think it was going towards the center of the track model) but any suggestions regarding this would be appreciated.

P.s. sorry if it comes across as a nag or whine or anything, I’m just getting very frustrated with stuff not working in the last week :S.

Hey I’ve been off in zomg the economy is borked survival land for the last six months and haven’t been monitoring the boards much. I hope you solved your problem.

What I would do in your case is build my own faux gravity attractor which forms a chain (think of a series of waypoints) and generates gravity both DOWN and INWARDS. This is going to be a bit more work, but it would probably behave the way you want.

(Another trick I use in racing games is to build an invisible tunnel around the track :slight_smile: )

I may not understand the bit about the gravity, but why not use Unity’s gravity? Opting out of that, I would imagine you would, depending on the kind of track-clinging you want, either attach a script that effects a velocityChange* force downwards (world oriented) at whatever your gravity value is, or effect a velocityChange* downwards(locally oriented).

The first method will result in normal gravity behavior. The second method will result in the craft being pulled relative to it’s own down (which may be unfortunate if it flips). However, if you implement a constant rotation so that its Y axis is always perpendicular to the track, it will “cling”. You keep it oriented to the track like that by casting a ray down its Y axis, getting the normal of the part of the track it hits, then using:

transform.rotation = Quaternion.FromToRotation (Vector3.up, normal);

I would definitely not recommend using the second method, as you have to account for a few things that can go wrong related to the orientation of the craft.

A better method, if you want the general target behavior of the second method without so many difficulties, would be to cast a ray down to the track, get it’s normal, and multiply that Vector by your gravity value. Then just apply the resultant vector (but it should be negative) as a velocityChange* to your craft.

*I think velocityChange is the right force mode to use here. You might have to try the others to see which is correct.

Now, for hovering, I’m not sure. I’ve read up on spring joints, and I know they pull on objects like rubber bands, but it doesn’t explicitly say it pushes on objects like a spring. I imagine it does. Try adding an empty game object with a rigidbody below your craft, roughly the distance at which it should be hovering. Set your minimum distance to this distance. If my guess is right, it should result in the hovercraft hovering above the ground, if not, well, at least you know that method doesn’t work. :slight_smile:

Faux gravity is designed for characters, not vehicles, so yes – snapping the up vector is probably a bit severe.

But snapping the up vector to the normal underneath you is actually worse – probably not what you want at all (get too close to a curved wall or bump in the road and zomg…). In fact the problems with this approach were already discussed in the original faux gravity thread.

If you actually read these threads you’d realize that not using Unity’s fixed gravity is the whole point.

Spinning the world to use fixed gravity won’t work if there’s anyone else in your universe.

Faux gravity allows you to run around on spheres or on walls or on Ringworlds, and allows each character (or whatever) to be in a different gravitational field. (And it plays nicely with the rest of the physics engine.)

But I don’t know how to read… :shock:

Seriously, though, I created a terrain following script a while back that used a similar method, except, instead of looking straight down, it looks ahead a short distance and reads the normal, then calculates the rotation needed and interpolates between current and target rotation over the time it will take to reach it. Curved surfaces don’t matter one bit. You can adjust the lookAhead distance to get a good prediction range without it anticipating too far ahead. It was designed for my AI to follow the surface of an asteroid, and it did just fine. If this sounds like what you need, OP, let me know.