Moving "down" from the bottom of the Z plane to 0x,0y,0z.

Get technical support about the C++ source code and about Lua scripts for maps, entities, GUIs, the console, materials, etc. Also covered are the Cafu libraries and APIs, as well as compiling, linking, and the build system.
Post Reply
Tatwi
Posts: 10
Joined: 2012-08-16, 23:13

Moving "down" from the bottom of the Z plane to 0x,0y,0z.

Post by Tatwi » 2012-09-12, 08:39

Doing this would allow a person to make a map as spherical "planet", where objects fall toward the center of the sphere, rather than down the Z plane. The way I would use this is really quite simple actually,

1. Make a pretty big spherical shape.
2. Move the sphere's center to 0x,0y,0z.
3. Build a sky box around the sphere, with ample room for tall objects.
4. Put a starry sky texture on the sky box.
5. Build the content of the game/project on the surface of the sphere.
6. Rejoice in having a nifty seamless "world"!

I'm willing to try to code this myself, but I was looking at the physics.cpp code from what I can tell, it doesn't work in the simple terms that I was thinking. Before I looked at the code, I assumed that the code would tell all objects, at all times, that their natural state is to fall down the Z plane. That way they would always drop "down" when not supported (much like an object on Earth). If that was the case, then making the change I want would be as simple as changing the code so that it tells all objects that their natural state is to fall toward 0x,0y,0z instead of down the Z plane. Then to use this feature, all one would need to do in the world editor is simply stick a polygon between the movable objects and 0x,0y,0z. Voila, you've got a planet that things fall down onto! Alas, the code itself does not seem to be organized in this manner.

I think this something worth figuring out and fundamentally, it's not a complicated problem to solve. It's really just a matter of applying the concept to the code base. And that's where I am not sure where to begin.

So my questions are,

- What chunks of code in Cafu are used to tell objects where "down" is?

- If Cafu was not made with the concept of "down", how was gravity emulated in Cafu? Can it's center of mass simply be moved as per my desire?

- Are all objects (players, items, etc) treated the same with respect to the movement toward "down"?

- After making "down" 0x,0y,0z, would character models automatically stand upright on any surface that is between them and 0x,0y,0z (rather than still standing as upright in relation to the Z plane)? If not, what code tells objects how to orient themselves in relation to the ground (ie. "I am standing on a slanted root, so I bent my ankles to make sure I am still standing straight up in relation to the ground")?

I think this would be a fun (and potentially useful, for orbital simulations, etc.) feature to have in the Cafu engine. Let me know what you think! :)
Thank you for making Cafu!
- Rob from Canada.
www.tpot.ca
User avatar
Carsten
Site Admin
Posts: 2160
Joined: 2004-08-19, 13:46
Location: Germany
Contact:

Re: Moving "down" from the bottom of the Z plane to 0x,0y,0z

Post by Carsten » 2012-09-12, 23:40

Tatwi wrote:I think this would be a fun (and potentially useful, for orbital simulations, etc.) feature to have in the Cafu engine. Let me know what you think! :)
Agreed! :cheesy:

The code that applies gravity "normally" is

Code: Select all

/// Changes the velocity according to gravity.
void PhysicsHelperT::ApplyGravity(double FrameTime, PosCatT PosCat)
{
    if (PosCat==InAir) m_Velocity.z-=9810.0*FrameTime;
}
The key for a spherical planet centered at (0, 0, 0) is that gravity must point - from the entities origin - "towards" (0, 0, 0). Thus the following code achieves the desired effect:

Code: Select all

/// Changes the velocity according to gravity.
void PhysicsHelperT::ApplyGravity(double FrameTime, PosCatT PosCat)
{
    if (PosCat==InAir)
    {
        const double l = length(m_Origin);

        if (l > 10.0)
        {
            m_Velocity -= m_Origin/l*9810.0*FrameTime;
        }
    }
}
I've tried it out (in map Kidney), it works nicely, but this alone is not yet very useful.

It seems that several other problems must be overcome to make this work in a better manner:

When the human player walks to the other side of the planet, it will be the top of his head rather than the bottom of his feet that touches the planet surface (because the bounding box did not rotate). Thus in the first persons camera it will look like we're making a headstand. This must somehow be compensated.

Is the player allowed to ever reach the true (0, 0, 0) center of the planet? Probably not, for several reasons. Physics should probably enforce a "minimum planet radius" that is in effect even if nothing else prevents the player from falling further towards the center.

Note that physics for human players are different from the true physics system (that is used e.g. for the crate in map Kidney) -- the above is only for the human player (and company bot and a few others). Objects like crates that are under the control of the physics system had to be considered and dealt with separately (this is probably more an extra rather than an important consideration in the beginning).

So far my initial thoughts, I hope it gets you started! :up:
Best regards,
Carsten
Tatwi
Posts: 10
Joined: 2012-08-16, 23:13

Re: Moving "down" from the bottom of the Z plane to 0x,0y,0z

Post by Tatwi » 2012-09-13, 01:37

Carsten wrote:
Tatwi wrote:I think this would be a fun (and potentially useful, for orbital simulations, etc.) feature to have in the Cafu engine. Let me know what you think! :)
Agreed! :cheesy:

The code that applies gravity "normally" is

Code: Select all

/// Changes the velocity according to gravity.
void PhysicsHelperT::ApplyGravity(double FrameTime, PosCatT PosCat)
{
    if (PosCat==InAir) m_Velocity.z-=9810.0*FrameTime;
}
The key for a spherical planet centered at (0, 0, 0) is that gravity must point - from the entities origin - "towards" (0, 0, 0). Thus the following code achieves the desired effect:

Code: Select all

/// Changes the velocity according to gravity.
void PhysicsHelperT::ApplyGravity(double FrameTime, PosCatT PosCat)
{
    if (PosCat==InAir)
    {
        const double l = length(m_Origin);

        if (l > 10.0)
        {
            m_Velocity -= m_Origin/l*9810.0*FrameTime;
        }
    }
}
I've tried it out (in map Kidney), it works nicely, but this alone is not yet very useful.

It seems that several other problems must be overcome to make this work in a better manner:

When the human player walks to the other side of the planet, it will be the top of his head rather than the bottom of his feet that touches the planet surface (because the bounding box did not rotate). Thus in the first persons camera it will look like we're making a headstand. This must somehow be compensated.
This is fantastic! I'll play with it and see what I can come up with. It will be pretty funny to see the head stand in action with the companyBot! :lol:

For giggles, I made a 32 sided sphere last night and it took my 2.33GHz Core2 Quad about 6 minutes to make the sphere and well over an hour to compile the map, but it was fun to run around on it (and on the sky box below when I fell off it). I'll try the code you've provided to test the practical usage/limits of the concept in relation to file size, movement, object placement, creating the illusion of a round surface, and that sort of thing.
Carsten wrote: Is the player allowed to ever reach the true (0, 0, 0) center of the planet? Probably not, for several reasons. Physics should probably enforce a "minimum planet radius" that is in effect even if nothing else prevents the player from falling further towards the center.
I've always joked with my wife about what would happen if one jumped in a hole that went all the way through the center of the Earth (if the Earth were solid rock). I figured you'd fall right on passed the center until gravity pulled you back down and you'd keep "rubber banding" back and forth around the center until you lost all your momentum and got stuck floating at the center.

That said, I don't know what would happen in the game engine if someone managed to reach 0,0,0, so setting a min radius for it might be required. Something to find out! :lol:
Carsten wrote: Note that physics for human players are different from the true physics system (that is used e.g. for the crate in map Kidney) -- the above is only for the human player (and company bot and a few others). Objects like crates that are under the control of the physics system had to be considered and dealt with separately (this is probably more an extra rather than an important consideration in the beginning).

So far my initial thoughts, I hope it gets you started! :up:
This is a great start for sure.

I was thinking that if I can get this to function reliably, then the next logical step would be allow any point to function as center of gravity, with a radius of influence around it. The radius of influence could be finite in length or asymptotic, depending on the level of detail that the user wants for their project.

As an example, a person could make the Earth and the Moon, each with their own finite radius of gravity, and then manually set up the path upon which the Moon orbits the Earth. Alternately, a person could recreate the actual gravitational relationship between the Earth and the Moon have, by applying a formula that mimics the asymptotic nature of influence that real world gravity has. The latter, of course, being far more complicated to use!

But it's best not to get ahead of myself!

Thank you again for your time, it is very much appreciated,

- Rob
Thank you for making Cafu!
- Rob from Canada.
www.tpot.ca
Tatwi
Posts: 10
Joined: 2012-08-16, 23:13

Re: Moving "down" from the bottom of the Z plane to 0x,0y,0z

Post by Tatwi » 2012-09-16, 07:16

OK, I have tried the suggested code on two maps, one with a sphere centered at 0,0,0 and one with a cube centered at 0,0,0 and I can safely that the code changes do not work as intend. Here's what happens:

Cube: With the starting position on the "top" side, I was able to move around as normal. Once I moved over any of the edges, I fell to X plane and got stuck there. This was half way down the side of the cube. When I recompiled the map with the whole cube above the X plane and then moved over the edge of the top side, I drifted down to 0,0,0 and got stuck there (bobbing side to side). So that's what happens at 0,0,0. :)

Sphere: This was a 16 sided sphere 17,680 units in diameter. With the start location on the "top" or "North Pole", I was able to move around as normal on the top two sides. Traveling south to the third side I began to move in a bounding motion when moving south, but not when moving north. When I moved further south to the fourth side, movement was extremely slow (and jumping once caused me to move north continuously). The bottom of the 4th side was on the X plane and I was not able to move beyond it. There were a few times where I inexplicably became stuck.

More Sphere: When I placed the start point at the South Pole, I fell to the skybox and then fell back toward the south pole of the sphere. Once I landed on the sphere, movement was extremely slow (keep in mind that I am using my 15,000 movement speed client!) and I was not able to leave the side that I landed upon.

I tried commenting out various parts of the physics.cpp file to help get a better understanding of how parts function (google translator helped a bit too lol...). I found that disabling the jump function eliminated compounding weird behavior, due to it's assertion that jumping means moving in the positive Z direction, but that's all I was able to accomplish.

Things I have noted:

- There seems to be a non-linear motion when moving down a slope, but a nice, smooth linear motion when moving up a slope. I read the code from line 284 to 317 of physics.cpp, but I don't see the difference between to directions in relation to the Z axis. What's important for me though is that I don't want there to be a difference - motion should be smooth in all directions.

- While I don't understand exactly what the code you provided me does, I think it's safe to say that it does not factor in the negative Z axis numbers below the X plane. In fact, motion appears to approach zero the closer one moves toward 0z, but that doesn't explain the ability to move (slowly) in all three directions when the spawn point is forced into a -Z location.

- I have very little hope in solving this problem without the assistance of a tutor or "pseudo code" that explains what each function, class, variable, and arguement is actually doing in the physics.cpp and physics.hpp files. Obviously tutorials are way beyond what I would ever expect from CFS! :lol: However, if you have some pseudo code or super detailed comments, I'd be happy to read them, even if they are in German (English is a close enough derivative of German that google translations make sense most of the time).

- I was thinking that perhaps it would be possible to achieve the same effect by replacing the whole Cafu physics system with the camera code for CaWE world editor and binding the camera such that "down" was always the outer surface of a brush that had a new property (called planetSurface). For my purposes, this would suffice, but it's a cheesy way to accomplish the task and it wouldn't add anything useful to Cafu as a whole.

On a related note, I read about dynamically loading maps when players collide with a trigger brush. That process could also achieve the effect of having a seamless world that wraps around itself. However, for smaller projects or simulations, what I am trying to do in this thread has merit (even if it is a little eccentric!).
Thank you for making Cafu!
- Rob from Canada.
www.tpot.ca
User avatar
Carsten
Site Admin
Posts: 2160
Joined: 2004-08-19, 13:46
Location: Germany
Contact:

Re: Moving "down" from the bottom of the Z plane to 0x,0y,0z

Post by Carsten » 2012-09-18, 00:20

Hi Rob,

thanks for your detailed analysis!
Honestly, I somewhat feared that my simple patch would not suffice to make this properly work, and that a more thorough review of the physics, camera and player control is required.

This looks quite teasing to me, too, especially as it might give rise for another nice, small demo MOD besides the current DeathMatch (desperately wanted as the old VSWM is totally broken and really must be deleted soon).

However, I really should finish fixing/updating the multi-MOD support before I do anything else. Although it clearly was the right thing to do, my change r572 broke the way in which people can create their own games (and possibly have several games/MODs all linked into a single Cafu.exe binary), and I would like to restore a solid basis again before starting anything else.

Besides that, I still think that trigger brushes for loading the next (or "neighboring") level, while not being the smoothest or best solution, are easy to handle and easy to implement, and so a good alternative to bridge the time until we have something better. (Please let me know if you have problems getting it work, creating a sample would not be a problem.)

:up:
Best regards,
Carsten
HWGuy
Posts: 95
Joined: 2011-05-31, 07:37

Re: Moving "down" from the bottom of the Z plane to 0x,0y,0z

Post by HWGuy » 2012-09-20, 06:05

Vehicles AND spherical world support in Cafu... would be one hell of a cool demo.
Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests