Announcement

Collapse
No announcement yet.

Gravity and Cylindrical Terrain

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

    Gravity and Cylindrical Terrain

    This is a general query to all code experts out there.

    I am toying with a concept for a Sci-Fi first person SP adventure.

    The setting is a giant cylindrical spaceship which rotates to spoof gravity on its inner surface.

    Is it possible to create a cylindrical terrain and also is it possible to create a polar co-ordinate system for gravity (i.e. have the z direction always be towards/away from a central axis)?

    This is the kind of thing I mean, here....


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

    Comment


      #3
      sounds like gundam. Way to go. Love the idea.

      Comment


        #4
        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.

        Comment


          #5
          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).

          Comment


            #6
            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.

            Comment


              #7
              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'.

              Comment


                #8
                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

                Comment


                  #9
                  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.

                  Comment


                    #10
                    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

                    Comment


                      #11
                      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.

                      Comment


                        #12
                        ^ Someone needs to read the other posts...

                        Comment


                          #13
                          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.

                          Comment


                            #14
                            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.

                            Comment


                              #15
                              There are other things, like physx, that are out of control.

                              Comment

                              Working...
                              X