Announcement

Collapse
No announcement yet.

Gravity and Cylindrical Terrain

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • replied
    Originally posted by Makaze View Post
    Why make it that complicated? If all of your units are simply walking on the "ground" along the inner surface of the cylinder then they are a fairly constant distance from the axis of rotation. You simply need a unit vector to the nearest point on the axis and scale it by whatever arbitrary (or carefully pre-calculated) value you've decided that gravity is.

    An arbitrary point on the axis with the pawns current Y coordinate substituted in (assuming the cylinder axis of rotation is the Y world axis) gives you the nearest point. If your axis is the world Y axis then you can even use the origin as your arbitrary point since the axis will pass through it. Meaning you don't even need to do any calculations, just kill the Y component from the pawns location and normalize the result for your unit vector to the nearest axis point. Rotating actors smoothly each tick from that info is not difficult.
    Trust it from someone who has actually implemented it - you'll encounter catch, after catch, after unexpected behaviour, after catch. Just try and get it working yourself, and you'll see just how time consuming it is to get it working in a limited fashion, let alone very smoothly

    Leave a comment:


  • replied
    There are other things, like physx, that are out of control.

    Leave a comment:


  • replied
    However moving objects will need a continuous calculation where a force that is proportional to the distance (rather than the distance squared, I believe) from the closest point on the axis and with a direction always away from the closest point on the axis will have to be calculated every tick, I guess.
    Why make it that complicated? If all of your units are simply walking on the "ground" along the inner surface of the cylinder then they are a fairly constant distance from the axis of rotation. You simply need a unit vector to the nearest point on the axis and scale it by whatever arbitrary (or carefully pre-calculated) value you've decided that gravity is.
    It will also be necessary to align the player models' etc. up axis to point towards the nearest point on the axis
    An arbitrary point on the axis with the pawns current Y coordinate substituted in (assuming the cylinder axis of rotation is the Y world axis) gives you the nearest point. If your axis is the world Y axis then you can even use the origin as your arbitrary point since the axis will pass through it. Meaning you don't even need to do any calculations, just kill the Y component from the pawns location and normalize the result for your unit vector to the nearest axis point. Rotating actors smoothly each tick from that info is not difficult.

    Leave a comment:


  • replied
    I did read the other posts...

    I get that the physics engine is doing a whole hell of a lot else behind the scenes like collisions and physics state changes. The question was more along the lines of whether or not it does any of that stuff for any given physics impulse or only from the negative Z forces specifically imparted by gravity?

    Additionally you don't need to turn off the physics engine entirely. Setting it to Phys_Flying retains the vast majority of functionality including collision. Rolling your own set of interactions for things like pawn rotation and potentially manually setting the physics to Phys_Walking is a good deal less onerous than recoding the whole physics engine.

    Leave a comment:


  • replied
    ^ Someone needs to read the other posts...

    Leave a comment:


  • replied
    Originally posted by Makaze View Post
    Is gravity really doing anything other than applying a negative Z physics impulse to the actor?
    Behind the scenes, it handles all manner of other events such as determining whether the pawn has hit the ground or a wall, it also handles state transitions and lord knows what else.

    In the modern engine, there's absolutely no reason why this should be the case. The major issue in reality is that what we're looking at is a highly evolved version of previous games where a gravity vector might not have existed (a game without a discreet complex physics engine would be a classic example). As a result, we're stuck with the scalar Z value in Unrealscript.

    Leave a comment:


  • replied
    Obviously for most objects in a level (static with respect to the cylinder) the gravity is academic - they can be put on the terrain at any angle and be left there unmoving. However moving objects will need a continuous calculation where a force that is proportional to the distance (rather than the distance squared, I believe) from the closest point on the axis and with a direction always away from the closest point on the axis will have to be calculated every tick, I guess.

    As the cylinder has a radius of 1 km it would need to rotate at 0.946 rpm to produce 1g on the outer rim.

    It will also be necessary to align the player models' etc. up axis to point towards the nearest point on the axis

    Leave a comment:


  • replied
    Is gravity really doing anything other than applying a negative Z physics impulse to the actor?

    Wouldn't it be possible to set a 0 gravity, and on Tick() add a delta scaled impulse towards your gravity source and smoothly rotate the actor to align with the impulse? Or in this case an impulse directly away from the axis of rotation of the cylinder, which could be calculated by getting a vector from an arbitrary point on that axis and discarding the Y component. Not sure how the engine switches back to the Phys_walking state but if necessary you could force it by running a trace from your pawn along it's down vector and looking to see if it's standing on something suitable.

    I imagine there'd be a lot of fiddly tweaking to get things working right but it feels like conceptually it should work. Though only worth it if it is a core part of your gameplay, not a nice to have.

    Leave a comment:


  • replied
    I actually assumed that was what you meant anyway, haha.

    As the game has no real limitations in draw distance, you don't lose anything by using a cylinder instead of a hemisphere

    Leave a comment:


  • replied
    Actually it seems skydomes don't work too well in this case - the overhead lighttube has a gap and the views down the tunnel look pretty rubbish. Time to patent the concept of a 'skytube'.

    Leave a comment:


  • replied
    It's a pity that centrifugal 'gravity' cannot be spoofed in the UDK 'cos I really liked the idea of aiming upwards and picking off a target above you with a scoped weapon.

    My gut feeling is that I will have to use Vue to make a lot of skydomes for the distance views and somehow break up the levels into lots of flat, streamed chunks.

    The problem is going to be doing that in a plausible manner, a bunch of walls criss-crossing the terrain is not going to cut it imo.

    Leave a comment:


  • replied
    You're going to have a lot of difficulty achieving this because of how the game actually works - gravity is a fairly hard-defined concept in UDK, and it's not easily alterable on a per-object basis, nor is it easy to ignore all-together unless you're 'flying' (in which case surface orientation isn't so much of a problem).

    Leave a comment:


  • replied
    Ahh, you refer to centrifugal force. I think the best way would be to cheat it. Make your levels mainly flat, but have the background look like it's cylindrical. With each level like that it'd give the appearance of being in a tube, more or less.

    Leave a comment:


  • replied
    sounds like gundam. Way to go. Love the idea.

    Leave a comment:


  • replied
    I don't think the terrain system can do this, but I see no reason you couldn't emulate it using static meshes.

    Leave a comment:

Working...
X