Making a round planet stage

#1 I personally wanted to say that all ratchet and clank games are great though I don't have an answer for you I could use this also. You would probably (most likely)need to change the source though or we would see a lot more of this.

#2 You would have to make a custom gravity modification. Instead of just applying gravity in the Z direction all the time, you would have to calculate a vector to the center of the planet at each update for each object and use that to apply gravity. Then you just make a spherical dif to walk on. You'll also have to update all objects' orientation so they look like they're sitting on the planet. You'll need to update the player code so it can find a contact point even when upside down. These are all c++ source modifications, and some not terribly simple. You'll need to put some work into it, but it's not the most difficult thing to achieve, I don't think. The only way you could get terrain to work would be to rewrite the whole terrain thing using spherical terrain concepts. I've seen some things about doing spherical terrain, but never looked at them closely.

#3 What if you were to divide up the terrain into, i don't know, triangular sections? Then put a portal like thing at each edge of each triangle so that when you walk or look at (i.e) edge A of triangle 1 you see, or step into edge B of triangle 2... is that possible? I've been hunting all over for something like this. Seems like it would be easier to impliment than a truly spherical world. No having to change the direction of gravity and all that.

#4 Changing the direction of gravity would be the easiest part --- centerofplanet.getPosition() - player.getPosition(), normalize the resulting vector, then multiply it by -9.8, or whatever your gravity is.

#5 Make your sphere in 3dMax, set the player on top, and rotate the sphere when the player moves instead of actually moving the player. Player's Z position can still be manipulated to jump. Player's position NEVER actually changes, just the rotation of the sphere.

#6 And implement polysoup collision to use kongdutka's idea.

#7 That would work great, until you get more than one player on the terrain :)

#8 This is a 2 years old thread :D.

Maybe you could just use the radius of the planet instead of implementing polysoup.



Aun.

#9 Someone needs to put out a planet pack code. I see this code popping out in a few places. Buts its one of those holy grails of certain game type and probably a bit more advanced then some of the novice programmers to impliment in some games.

#10 I think I have some ideas of how to do this in a fairly decent way(and something I want for my own game). If enough people are interested I could release it with a few other things as a pack. So I guess what I'm asking is, are people interested enough in having spherical or sphere-mapped terrain for this to be worthwhile to make into a pack (or maybe just a resource) such that'd it be worth my time making it generic enough for people to use, instead of specific to my own needs?

#11 I'm extremely interested in having spherical or sphere-mapped terrain, and would even be willing to purchase a pack for a reasonable price, if one were to exist. If you decide to create a pack, please drop me a line. :-)

#12 @Ross
i would be interested in something like that, and so would others ( i have seen loads of questions about it elsewhere on the forums)

Neil.

#13 @Ross
I would be interested as well.

Jason.

#14 I'd like it using atlas and tgea and Bill Vee has already coded this.

video.google.com/videoplay?docid=4079193529847235422&hl=en

#15 I would imagine point and vector gravity would be more usefull (even mutiple gravity points), then it could be used with atlas or what ever, even without a terrain.

#16 Yes, i will pay too for a this pack/code!.

Start point:
www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=13249

@Aun: you can publish the source code for make that difs have gravity?

#17 Hey everyone, quick update a couple of questions. So I've done some more research for setting this all up, and I can basically go two routes (or do both).

One option is just to not deal with the terrain projection to a sphere at all and instead do something similar to Sean O'Neil's ROAM (real-time optimally adapting meshes) on a sphere technique ( www.sponeil.net ) for these planets. The benefit with doing it this way is that 1) it'd be easier and faster for me to get something out that's usable quickly and works well, 2) it won't require a bunch of changes to the engine itself since I'd be doing this all in my own classes.

The second option is to actually do the harder thing and go about projecting the Atlas heightmap into a sphere. The benefit here is that Torque already works with Atlas and you'd have some direct control over what does into your terrain(although if I were going to do #1, I'd probably at least look at doing a real time editor ala the Legacy terrain). A drawback is that you probably won't be able to do as large of planet objects as with the first method.

Third, I could just do both, but that means that it will probably take me slightly less than double the time to get something out there for you all.

Also a note: in terms of having this be a pack for TGE vs. TGEA, I'm most familiar with TGEA and don't want to deal with the Atlas1 stuff in TGE. Doing it for the Legacy terrain is basically out of the question (it's a monster, I've done some stuff with it and it was pretty hairy) not to mention that the "planets" would be very small (limited to 2km, and updating it to higher resolution is also somewhat out of the question for the same reasons). If I do the #1 option above, it'd be pretty easy to put into TGE, although I don't know what the performance would be like since ROAM really needs batching and stuff to perform well. If there's a lot of demand for this to be in TGE I could at least look at the feasibility of doing it, though. So, to start it will almost certainly be TGEA only. Just FYI.

#18 @ Javier Canon,

The planet is a normal DTS object that the player will use the location as a reference. I then normalize the vector between the player and planet and then multiply by the gravity force to push the player to the dts planet. After that, I used the normalize vector above to find a rotation between the player and planet to rotate the player to match the planet. The bad thing about it is that at some point you'll come to a gimbal lock. I think others would come with a better solution then I did.

#19 @Aun, if you're having issues with Gimbal lock you should use QuatFs or matrices to rotate (use AngAxisF to build the quat, since AngAxisF takes a vector and an angle, where as the quat is a bit different).

#20 @ Ross ,

It was something I did for fun and see if it was possible. I remember the player class had some problems passing some rotation values that made it almost impossible to avoid the rotation problems. Let us know if you got these issues figured out.