Jump to content

Confusing issue when moving points in the renderlist


JackStone

Recommended Posts

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:


http://phoenixgamedevelopment.com/blog/wp-content/uploads/2016/08/PhoenixGameDevelopment-28_08_2016-08_06_07-AM.jpg


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:


http://phoenixgamedevelopment.com/blog/wp-content/uploads/2016/08/PhoenixGameDevelopment-28_08_2016-08_19_15-AM.jpg


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?

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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:


http://phoenixgamedevelopment.com/blog/wp-content/uploads/2016/09/PhoenixGameDevelopment-04_09_2016-01_43_54-AM.jpg


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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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:

sk-32ad402e1a08bcbea8cf4b1124f43f63.jpeg


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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 2 weeks later...

Hi,


Thanks for your reply,


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


Ah, and there is matrix math again :P 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!

Link to comment
Share on other sites

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/algebra/vectors/angleBetween/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.

Link to comment
Share on other sites

  • 2 weeks later...

Hello, thank you for your reply.


I had a good look at that link, and I do think it helped a lot.


It is possible that I am closer than I thought.


I actually have code that rotates a point (using Rodrigues' rotation formula). However, this seems to rotate about the wrong origin point.


I think if I could translate the nodes back to the origin, rotate them, then translate them again by the same distance, I could accomplish the rotation.

The angle to rotate by seems to be given by the code you posted.


Wikipedia says about Rodrigues formula:


"By extension, this can be used to transform all three basis vectors to compute a rotation matrix in SO(3), the group of all rotation matrices, from an axis–angle representation"


So, this should work... I will give it a go as soon as I can, and post an update either way, thanks again!

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...