[JackStone]

Hi,

I have run into something of a brick wall with my spherical terrain implementation (again!).

I may have gotten myself into a situation that can't actually be resolved here, I'm still trying to figure out what the problem is exactly, and I'm hoping someone here can shed at least a little light on what's going on.

Basically, I have got a very large planet rendering in T3D by dividing it up using a quad tree, and rendering only nodes close to the player. For the purposes of this argument, the player is close to the surface of the planet, and has moved 10,000 meters into the next "zone", and so I want to render the next set of nodes. This is what gnuplot shows:



This is correct. P1 (pink) are the original nodes, at the players starting position, these are now no longer needed, as the player has moved on to P2(green) which is now rendering. So far so good.

The problem is that I need to implement a floating origin system, I can't have the player walking all around the planet, since there will be all kinds of precision issues. So, I reset the player back to the origin, and I now need to move the P2 nodes back along the same vector that I moved the player back (let's assume it's 10,000 units along the x axis for now).

Now, the player should be at the origin, and the p2 nodes should be rendering as if they were in their original position, but they have been moved back 10,000 units.

The X axis is indeed correct, but for some reason, the nodes are in the wrong positions in the Y and Z axes. Each time I increase the distance by 10,000 units, this error increases, causing the nodes position to be completely incorrect.

This is the best image I have of what's happening. This is after just one movement by 10,000 units:



These two groups of nodes should be in exactly the same place, but as can be seen, the second set of green nodes is offset along the z axis.

I have tried all manner of solutions, from changing the positions in the spherical terrain code, changing them in preprenderimage, scaling and rotating, using rodrigues rotation formula, and adding an offset to the z axes to try to compensate for the shift.

Nothing seems to work.

I have confirmed that when I move the nodes by 10,000 units, then move them back by 10,000 units, they are *exactly* the same, which means that what ever is happening is not some random occurrence, for some reason there is an offset being added to the y and z axes of these nodes when I change their x values.

I suspect that the fact that the nodes are on a curve (being part of a spherical terrain surface) must be the issue.
It could also be to do with the local coordinates of the nodes, they are between -1 and +1, could this be an issue?
Another thing that I just thought of is some kind of an issue caused by the scale of the actual world object, in the mission editor.

Does anyone have any advice on where I could continue looking?

[JeffR]

What's your math look like for the actual offsetting back to origin?

If you can offset to origin and then offset back and it corrects itself, I'd highly suspect there's an odd math operation going on in there that's skewing the values.

Are you just doing a flat vertexPoint -= playerMoveOffset, or do you have something more complex in play?

[JackStone]

Yeah, I am basically just doing this:

nn1 += moveoffsetvec;

Where the moveoffsetvec is a simple vector. I was just doing:
nn1.x -= 10000, which was even simpler.

However, if you look at this image:



If I move point 4 by the offset distance, it will be beneath p3, since it is offset on Z. So, I am assuming that this is due to the curvature of the planet, and I need to move the new nodes along that curvature, but I may be totally wrong about that...

[chriscalef]

If you haven't accounted for the curvature of your planet, aren't you guaranteed to fail? Your player hasn't moved along a straight vector, he has rotated around a tiny arc of a circle with its center in the center of the planet.

It might help you to imagine the problem as if your player was moving around a significant chunk of the planet in one go, instead of just a few kilometers. It would seem that instead of simply adding a vector to all of your points, you need to actually rotate them around the center of the planet, by some small amount.

For instance, if you were to move your player around a full ninety degrees of the planet, the way you are doing it now the ground that had been under his feet would be moved down and over and would be exactly perpendicular to what the ground should be doing at that point.

[JackStone]

Of course, you are absolutely right!

I realised this myself a day or so ago, and your post put the final little piece into place.

The problem wasn't with the *planet*, it was with the *player*. I thought I was making this easier by moving the player along one axis only, but of course that is essentially what caused the problem.

What I need to do is move the *player* in a circular path.

That is going to take a little time to figure out, with my current implementation, but with all the work i've done on spherical rotation so far, it shouldn't be too difficult!

Thanks for your help, that was the last little piece of the puzzle that I needed!

[Bloodknight]

Surely the player just needs to know the gravity vector, as far as i can tell this is the only difference between 'regular' terrain and spherical terrain

There was somebody else working on speherical terrains a couple of years ago, tho in a much smaller scale, more like the british gas ads or that one little world in dragonball z, unless that was you, have you changed usernames in the past half decade or so?

anyway, upshot is, if you aregoing to have multiple planets of multiple sizes then you are likely to need a variable gravity vector anyway, how difficult this is i dont know, since at least some of the gravity system is hard coded magic numbers

[JackStone]

I have the 3D gravity completely done, that was fairly easy. That just pulls the player towards the center of the world though, it doesn't seem to help with moving/offsetting the terrain.

The player is already moving in a spherical path, really, since the terrain itself is actually working an paging properly. The only thing I need to do is reset the positions of the terrain and the player when the player has walked a certain distance.

This sketch illustrates what is essentially happening:


The player is standing at the origin, with the nodes close by rendering (The red x is the origin, and the nodes with the red lines are rendering). They then walk towards the blue X, which is a distance of 10,000 meters. They have now moved in a curve, around the terrain. I am now rendering the nodes with the blue lines under them. This works fine.

What I now need to do is move the player back to the red x, which is simple, AND move the BLUE nodes back to the origin as well, such that the player doesn't notice a transition. Moving the nodes is easy, but they are always offset in some way.

[kent]

I believe you need to rotate rather than translate. I'm kind of weak on all of this ... so this is my best stab at the concept.

It's easier to view things in terms of a spherical coordinate system. Consider your origin as the center of the planet. Any point on the surface would be defined as a vector consisting of the direction (rotation,elevation) and magnitude (distance) from the world center.

So say you pick an arbitrary fixed "virtual origin" point V1 (the red X). This is where we always want the player to end up when things shift. The second arbitrary point, V2, is the location of the player when we decide to warp everything back to V1 (the blue X),

I think you'd need to normalize the two vectors and compute a transform matrix that would rotate V2 to V1 then use the matrix to rotate all the desired points.

[JackStone]

Hi,

Thanks for your reply,

I think you're right, translating probably won't do it.

Ah, and there is matrix math again I'm still not great with that stuff, it's probably why I haven't figured this out yet.

From what I am told, I don't need to actually convert too a spherical coordinate system, is this correct?

I can use the translation algorithm on the cartesian coordinates?

I will have to look into matrix math then, and see if I can figure this out. Thanks!

[kent]

I'm pretty weak at matrix stuff myself - have to go through and re-learn what I'm trying to do every damn time (^%@$!* quaternions). Unfortunately, I haven't played with rotations for a while or I'd be more helpful.

But yeah, there's no need to actually convert to using a spherical coordinate system for the engine. The point is to produce a matrix that can be applied to cartesian coordinates. The steps involved with one common way for producing the matrix (I *think*) you need are easiest to describe in terms of a spherical coordinates though. Particularly in your context. You are trying to figure out a difference in angle between two vectors (from the planet center) rather than the distance between two points (on the surface).

Take a look at the code at the end of this tutorial (It seems to be missing a few CRLFs, so watch for that). I believe it is close to what you need.

http://www.euclideanspace.com/maths/alg ... /index.htm

In your case, the two vectors would be |world_center||current_player_location| and |world_center||fixed_warp_point|.

Torque has most of the functionality needed already built in one of it's core math classes if you dig a bit - so it is probably possible to pare that code down by the time it is implemented using Torque classes.