Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / Planetary FPS movement

Author
Message
C0wbox
20
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 23rd Aug 2010 03:18 Edited at: 23rd Aug 2010 04:06
Suppose one had a planet (sphere) and one wanted to have the player walk around on it using either first person or third person controls.

How would one go about doing this?

- I've attempted this but can't get the rotation for the camera to work at all.
- I've also attempted to search for similar things but no one ever seems to be doing this kind of movement.
- Ideally I'd like to do this using trigonometry/intersecting the sphere not physics.

dark coder
23
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 23rd Aug 2010 07:06
It's a little annoying to do in DBPro, your best bet is to just use EZRotate, because I believe the orbit functionality in that will do what you need.

If you really want to do this manually then you first need to find a decent way to represent the player's current orientation relative to the planet. Assuming the planet is relatively round and you don't need complex stuff like walking on walls then you only need to handle the player's orientation(as the location can just be multiplied out), this is usually done using a matrix or quaternion, but as DBPro only comes with a (very limited) matrix library, so you may want to use that.

First of all, you need to begin with some orientation, this isn't as simple as picking a longitude/latitude to spawn on because your player isn't a normal, it also has an angle about the normal that it faces, aka bearing. To keep this explanation short let's just begin with a unit matrix/quaternion, this will result in the player facing down the global Z axis and will be at a top of the sphere.

Now, let's say you wanted to move along the local X/Z axis FPS style, these input values can be anything, let's say 1 metre on the X and 2 on the Z axis, you then need to find the angle that these movements represent on the surface of the sphere. This is just the very basic pi*2*radius/movementDistance, do that on both axis, where movementDistance is 1 and 2 respectively. However, this equation will give you a 0-1 percentage of the distance travelled, if you're using radians then just multiply the result by pi*2, or 360 for degrees.

Now that you have these 2 angles, construct a rotation matrix/quaternion that performs these rotations, first on the global axis, so the first would be a rotation around the global X, and the second around the global Z. Multiply these together then multiply this result by the unit mat/quat discussed above, this mat/quat will then replace the identity one. Finally, you need to find the location for this orientation, this is just a case of transforming the vector {0,radius,0}. You then position your player there and convert the rotation to Euler and rotate the player to it, once that's done you can incorporate mouselook and such.

Neuro Fuzzy
19
Years of Service
User Offline
Joined: 11th Jun 2007
Location:
Posted: 23rd Aug 2010 14:55
I'm assuming you need help with the rotation and not positioning? Voila!



it uses a spherical coordinate system, <alpha,beta,rot>. Alpha and beta are standard 2 angle spherical coordinates (rotated on the x axis then the y axis), and rot is how much the object should be turned perpendicular to the sphere (it uses vectors from the result of the 2 angle rotation to define the plane of rotation and what 0 rotation is). I'm sleepy now, and I don't know how hard it would be to work out a "move forward" command that preserves direction (IE if you move forward at the programs current state I think you would spontaneously rotate.


Is't life, I ask, is't even prudence, to bore thyself and bore thy students?
C0wbox
20
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 23rd Aug 2010 15:21
@ dark coder
Ok, well, given that I've only recently learnt how to use vectors in DBP (as opposed to in a maths classroom) I have no idea how to use matrices or even what a quaternion is.

I tried reading your explanation but got lost very quickly xD
(I don't know if it helps but I already have a plain which positions itself on the surface and points towards the centre of the sphere so I can get the angle of the normal to the sphere's surface - I just don't see how to get the camera to respond in an FPS style way ontop of this normal. )

@ Neuro Fuzzy
That code is 1/3 to what I'm looking for. As you say, it won't respectively move you forward and as well as that, it can't be rotated in the object's relative X axis (for looking up and down).



I may just capitulate and use EZRotate - My shoddy maths A level doesn't prepare me to do this sort of maths... all I can remember is roughly when to use cos and when to use sin in working out projections in 2D (and sometimes 3D) space.

Neuro Fuzzy
19
Years of Service
User Offline
Joined: 11th Jun 2007
Location:
Posted: 23rd Aug 2010 15:47
Quote: "it can't be rotated in the object's relative X axis (for looking up and down)."

Ah, that actually wouldn't be a problem at all!

As for moving forward... I think I can work it out, its just a little bit of a task. Moving forward is no problem. Preserving rotation is. Preserving pitch shouldn't be too hard.

I think my algorithm would be something like this:
(1) find the direction vector of the object (perpendicular to the sphere)
(2) move the object forward using trig (either move it forward in 3d space then normalize the vector, or do some weird great circle distance thing for better accuracy)
(3) find what the new direction vector should be (quaternions I guess :/)
(4) find what the direction vector is (IE the wrong one)
(5) find the angle between the two (dot product) and subtract that from the rotation.

and now that I think about it I definitely dont have to mess with pitch.
It's possible rotation is already conserved if you move forward, but I didn't take that into account at all so idunno.


Is't life, I ask, is't even prudence, to bore thyself and bore thy students?
dark coder
23
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 23rd Aug 2010 16:03
Quote: "I tried reading your explanation but got lost very quickly xD
(I don't know if it helps but I already have a plain which positions itself on the surface and points towards the centre of the sphere so I can get the angle of the normal to the sphere's surface - I just don't see how to get the camera to respond in an FPS style way ontop of this normal. )"


It depends how much accuracy you really need, if your planet is rather small then you will most likely require a method similar to what I described, but if it's massive then you can cut a lot of corners, because the angle you traverse on the surface would presumably be insignificant. This is done in real life too, as the Earth is flat! (on small scales).

If you'd like I can show you C++ code to do this(I won't touch DBP/GDK's vectors/matrices with a barge pole!) so it won't exactly be copy/paste, but if you're somewhat familiar with vector/matrix operations it should be easy to port.

C0wbox
20
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 23rd Aug 2010 16:42 Edited at: 23rd Aug 2010 18:58
To add to the list of things I don't know - I still don't know the difference between Euler and anything else.

@ Neuro Fuzzy
xD I replaced your code with some mouse movement stuff then looked at the algorithm again to see about implementing it... I'm afraid my mind doesn't comprehend what it says due to the fact I understand diagrams better than words when it comes to 3D or 2D maths. (I also still don't even know what quaternions are. )

I'm such a noob at all this, I can't for the life of me figure out what the significance of the number 57.29577 is. xD

All I've managed to do to that code is fix some problems regarding the actual movement and speed, change some syntax and increase the size of the sphere it walks around. - I can't do anything more impressive.


@ dark coder
Well ideally the planet would be fairly large, I'd just be worried about hills/mountains in this context. :S

Imagine walking over one of these mountains:


Hah, C++ code wouldn't help me in the slightest, I've never gotten an SDK or GDK to work with C++ so I can't get past console applications. xD (Therefore I'd have no hope at understanding the code for 3D maths. )

C0wbox
20
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 23rd Aug 2010 22:15 Edited at: 23rd Aug 2010 22:20
Gah, I nearly have it. - Using non complicated mathematics and a bit of DBP's awesomeness.

This is about the 4th attempt of doing this movement and so far is the only one that nearly works:

With that in the loop of my actual engine (around a 480 WU sphere in case anyone wants to try it out), the object the camera is positioned at is simply rotated around the planet as it goes. - It all works fine except for this line:
turn object right OBJ,TURN#
(the 1 before move object up OBJ,300)
For some reason it just isn't doing it... - and is the only thing stopping me having complete FPS control around this stoopid planet. xD

Someone wanna tell me how much of a noob I am?/What I'm doing wrong/should be doing?

EDIT:
Ok, upon closer examination that still doesn't do what I need...

It only moves around circles of the sphere, rather than in a true respective forwards, backwards, left, right movement.

Maaaan, this just sucks... I can't get it to work.

Neuro Fuzzy
19
Years of Service
User Offline
Joined: 11th Jun 2007
Location:
Posted: 23rd Aug 2010 23:34
Quote: "I'm such a noob at all this, I can't for the life of me figure out what the significance of the number 57.29577 is."


ooh, right, I should have mentioned that.
standard DBPro rotations use degrees, but not the matrix commands, the matrix rotation commands use radians. radians=degrees*360/pi ~~ degrees *57.29577.

Basically, what the code is doing (using rotation matrices) is creating a matrix, B, that rotates first by alpha# on the x axis, then by beta# on the y axis. Then, it creates a rotation matrix that rotates rotation# degrees around the up direction <0,1,0> would face after being multiplied by B, and stores that rotation matrix in A, then multiplies A*B. Pretty much the same thing goes on for pitch. Now we have a rotation matrix that would be applied to the object to change its vertice's position after rotation, but we can't pass that to the DBPro object. Instead, we have to find the euler angles such that Z*Y*X=C, where Z rotates z degrees around the z axis, Y rotates y degrees around the y axis, and X rotates x degrees around the x axis. To do so, you multiply Z*Y*X to get this matrix:
C=

and compare specific rows/columns of the matrix C to determine the values of x, y, and z. Now you have the euler angles, and you can apply those to the object

Sorry... I want to work on this, but I have to go... I'll post back in... about six hours?


Is't life, I ask, is't even prudence, to bore thyself and bore thy students?
C0wbox
20
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 24th Aug 2010 00:41 Edited at: 24th Aug 2010 00:44
@ Neuro Fuzzy
I...

I...... I'm not sure... I understood all that.

xD My experience with matrix maths is limited. I've certainly never done it in any code before.

So just to clarify; I got lost after the word doing xD

<Waits eagerly for your return>

(I just wan't a world I can run about on... I'm not even going to use it for a project or anything serious yet xD)

Dr Tank
17
Years of Service
User Offline
Joined: 1st Apr 2009
Location: Southampton, UK
Posted: 24th Aug 2010 01:17
You can do it with quaternions and stuff but there's no need really. Just use the pitch and roll stuff like you've done already. To find where you are on the surface, just do line collision projecting from the centre of the planet upwards. to get this vector, you can pitch and roll a test object, move it starting from the origin(perhaps after pitching up by 90) enough to get into "space" and use a line to this point for the collision.

How much you pitch and roll your player to get movement, you'll need to scale by 1/the distance from the centre.

You are along the right lines with your code. I'll try throwing together a quick demo of how it would work.
C0wbox
20
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 24th Aug 2010 01:49
@ Dr Tank
!

Well, I hope your demo shows what I've been doing wrong. - I'm so close, there's just 1 problem with mine; I can't get it to move relative to the direction you're facing. - If I solve that, it should fix the other problem where it only moves along a row or column (rather than across both)

Dr Tank
17
Years of Service
User Offline
Joined: 1st Apr 2009
Location: Southampton, UK
Posted: 24th Aug 2010 02:28
Here's the thing. Hope it helps. Please forgive the horrible texture stretching.
C0wbox
20
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 24th Aug 2010 02:40 Edited at: 24th Aug 2010 04:05


You make me seem insignificant.

But I don't mind ! I'll examine the code now I've proved to myself it works and attempt to write the engine a 5th time. !

xD Thanx

EDIT:
!!!!!!! I actually love you Dr Tank. It works so well now, no silly annoying bugs or procedures. And it's so simple I can actually understand what its doing instead of worrying about my confidence in 3D Maths.

- As a reward for your help, I've attached a demo of the awesomeness it unlocks.
(Ignore the name and the fact the stars show up through the skysphere. )

Neuro Fuzzy
19
Years of Service
User Offline
Joined: 11th Jun 2007
Location:
Posted: 24th Aug 2010 05:41
Cool its working!

I need to stop doing more math than I need to


Is't life, I ask, is't even prudence, to bore thyself and bore thy students?
C0wbox
20
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 24th Aug 2010 05:50
@ Neuro Fuzzy
xD I wouldn't have minded if the maths worked and gave me a solution therefore, but well... Dr Tank's method is just so much more concise, and user-friendly - like a bar of soap

Thanx for trying though, your method was on the way to working.

Neuro Fuzzy
19
Years of Service
User Offline
Joined: 11th Jun 2007
Location:
Posted: 24th Aug 2010 06:13
I would keep on calculating with my way but Dr Tank's way is also faster ('m pretty sure)


Is't life, I ask, is't even prudence, to bore thyself and bore thy students?
Dr Tank
17
Years of Service
User Offline
Joined: 1st Apr 2009
Location: Southampton, UK
Posted: 24th Aug 2010 16:32
Glad to be of help. Nice demo!

I look forward to seeing your project progress. I'll try to add some more stuff to my snippet like momentum, jumping, and maybe that will be useful.
C0wbox
20
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 24th Aug 2010 16:53
Quote: "I look forward to seeing your project progress"

Well, it may be a while before you get the chance.

Currently I'm making Happy Isle for the Intel competition and once that's over, we'll all be finishing off World Off Road.

So this won't become our main project until after WOR, and even then it'll be competing with a 50% chance with another game/engine.

Dr Tank
17
Years of Service
User Offline
Joined: 1st Apr 2009
Location: Southampton, UK
Posted: 25th Aug 2010 00:09 Edited at: 25th Aug 2010 00:13
That's cool. I can wait.

I added 2D momentum, upward momentum with jumping, and stopped going extra fast diagonal running.

There's no sliding down hills, working hard to go uphill, and going faster downhill. It's also too "hard" in that you can jump again the moment you land, and are airboune when you crest a polygon. Will tinker more at some point, but like you, I have my fingers in a lot of pies.

Here's the snippet. Put it in a .dba the same project folder as the last one.

C0wbox
20
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 25th Aug 2010 00:32 Edited at: 25th Aug 2010 04:16
@ Dr Tank
Hah, I like it, but I don't see it being much use unless I add vehicles or something to my magic planet. (Which for the time being I don't see happening)

I found running over mountains and taking off quite entertaining.

Let me know when you get sliding done, because that'll make it harder to go up hills and make you go faster down them. - That and jumping fixed will complete the engine. (Assuming I can figure out how to take out the horizontal momentum code once you're done with it xD)



I just like how much I whittled your original snippet down:
- That is literally the extent of the FPS engine in Terra.rar xD (With unimportant parts taken out)
Pointers for improvements I've added:
* I'm using sc_intersectobject from Sparky's DLL to calculate the upper most polygon on any model (meaning I can add rocks and stuff to the landscape (I won't be able to do multi-floored buildings though))
* I took out the 2 random arrays for the planet's position and space's position because well, the planet won't be moving for a start, so that will always be 0,0,0, and I don't like using arrays unless its for a large amount of data (not 3 variables xD)
* I added a limit for the camera angle so you can't look lower or higher than is humanly possible.

KISTech
18
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 25th Aug 2010 00:46 Edited at: 25th Aug 2010 00:47
Wouldn't it be easier to keep the player still and just move the planet under their feet?

Then you would only have to worry about vertical placement of the player, and you could do multi-story buildings.

[edit]
Well, ok, you might have to switch to a traditional method of movement while the player is in the building. But that wouldn't be hard to do either.

C0wbox
20
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 25th Aug 2010 01:56
@ KISTech
Yeah, that was always the easy way out if I couldn't get this but due to the number of objects I want to place on this planet, it would just slow it down too much trying to move them all at once. So to keep things efficient (i.e. not moving 1523623 objects all at the same time) I'm moving just one object.

(As well as "moving" all these object, I would have to update their meshes in Sparky's DLL, so it would get really inefficient ontop of the number of polygons I'm using and the fact I'm using 2 cameras. )

Moving the player only is definitely the way to go.

KISTech
18
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 25th Aug 2010 04:07
Hmm.. I see the challenge now.

Good luck with that.

C0wbox
20
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 25th Aug 2010 04:10 Edited at: 25th Aug 2010 05:35


Already met the first problem.

The second I try and do some Sparky's collision it blows up on me again. xD

How doesn't this work?

It is basically just using the usual Sparky's collision method where it records the position before movement, the position after movement then if a collision is there it'll position you at the old position - only this time I've replaced old position to old rotation.
You'd think that would work but it seems to be positioning the player on the complete opposite side of the planet to where it should be.

I need another method, because even with this method it still wouldn't handle and sliding collision (you know, the thing we all love Sparky's for )

Halp again


EDIT:
Ok, 1 hour and 20 minutes later, I now have a relatively working collision system. Basically it switches the engine to use a non-planetary FPS engine when it detects a foreign object beneath the player. So, this therefore only works on buildings but I may be able to make a system that checks in a small perimeter around the player and switches to a non-planetary FPS engine when there are any objects nearby. Due to the fact the planet is fairly large and the collision zones for objects will be small, the player shouldn't notice that they aren't moving over the horizon while sliding around an object.

Dr Tank
17
Years of Service
User Offline
Joined: 1st Apr 2009
Location: Southampton, UK
Posted: 25th Aug 2010 21:20
You'll kick yourself! Just add an extra line to the last part of your snippet:



Adding sliding collsion will be more difficult. Actually it might not be too bad. Using the standard DBP line collsion thing like I did, you'd need to cast extra rays to find gradients. I think Sparky's gives you the polygon normal and stuff.
Benjames8
16
Years of Service
User Offline
Joined: 6th Jan 2010
Location: Your Nightmares
Posted: 25th Aug 2010 21:38
I did something like this like a couple months ago but when it came time to point my enemy's in there movement direction i failed.
C0wbox
20
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 25th Aug 2010 23:58
@ Dr Tank
I'll try sticking that on in a bit. - Any recommendations for sliding collision though?

@ Benjames8
Hopefully I won't need to do that for anything I use this for because I'm sort of thinking of using this as an AI testing ground, where I set up an ecosystem on a planet or something. (So there would be no enemies)... buuuuuuuut things in the ecosystem will still need pointed - I have an idea for this though.

Dr Tank
17
Years of Service
User Offline
Joined: 1st Apr 2009
Location: Southampton, UK
Posted: 26th Aug 2010 01:34 Edited at: 26th Aug 2010 01:36
I don't have much experience with the collision DLL, but here's how I'd try to do it:

Do the sliding collision as normal in 3D space, between your current and destination positions. You can get the destination position in the previous way (rotations), or just apply 3D velocity, acceleration. I recommend the latter.

Then the problem is rotating the player model such that it stays upright in the new position got from the sliding collsion routine. I think EZrotate allows objects to be rotated about arbitrary world axes, making this fairly easy. Basically you'd want to look at the cross product of the vector from the centre of the planet to the position the player is being put at, and the player's previous "up" vector, and rotate by that vector so your player's "up" is aligned with the world "up".

Basically you lose the simple solution from before, but it should work I think. This explanation turned out quite long! I'll try to code it in a day or two.
C0wbox
20
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 26th Aug 2010 04:08
@ Dr Tank
xD

I actually felt it that time, the second you said cross product I instantly felt I didn't understand xD (And was proved correct)

I'll probably see it better with code.

In the meantime, I'll see if I can get my method fixed.

Wilf
Valued Member
20
Years of Service
User Offline
Joined: 1st Jun 2006
Location: Gone to Unity.
Posted: 26th Aug 2010 19:56
Really cool, maybe submit this to the codebase so it doesn't get lost to the archives of the forum?
C0wbox
20
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 26th Aug 2010 21:20
@ Wilf
What are we submitting? - This is now a project... xD I wouldn't go submit all my other projects to the codebase. xD

All the parts of this project can either be found on the forum or worked out.

Dr Tank
17
Years of Service
User Offline
Joined: 1st Apr 2009
Location: Southampton, UK
Posted: 27th Aug 2010 00:56 Edited at: 27th Aug 2010 01:04
I altered Sparky's simple sliding collision demo to add in a planet. You say you didn't want momentum, and it isn't in this. Just simple sliding collision. There is no upward momentum either - when you fall you drop at constant speed. It's a bit like a simulation of what would happen if air resistance was really high. Kind of like the Drude model or something.

I digress. This should work with the same media I used in the other demo.

I'd like to put in some stuff like ground resistance, momentum. The more advanced Sparky sliding collsion demo is better. I'll check that out and see if I can implement it into this.

C0wbox
20
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 27th Aug 2010 05:08 Edited at: 27th Aug 2010 05:10
@ Dr Tank
Once again you amaze me by achieving what I cannot.

I will sift through the code tomorrow after work. (I can implement jumping from my old FPS engine I think)

So thanks so much again, for getting sliding collision working. !!!

(You will get full credit for the engine core if this turns into anything major (regardless of how much I've altered, the original base is your work))

Dr Tank
17
Years of Service
User Offline
Joined: 1st Apr 2009
Location: Southampton, UK
Posted: 27th Aug 2010 17:41
Thanks dude. I appreciate being appreciated.

If you've made a satisfactory engine from the Sparky demo before, you should be able to do the same with this. The only differences from the standard version are rotating the player upright each time, and the direction of gravity.
C0wbox
20
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 27th Aug 2010 20:43 Edited at: 27th Aug 2010 20:48
@ Dr Tank
The engine we all refer to as "the Soharix FPS engine" is just an ordinary FPS engine that uses Sparky's DLL, has jumping, crouching and various other added extras but it's never been adapted for use for a planetary FPS system. So what I'll end up doing is taking the basis for the engine we've been cobbling together in this thread and stick in the main parts that are adaptable from the Soharix engine. (I've already stuck in the entity handling and graphics settings from the Soharix engine, its just mechanics that need to be implemented now.) Once that's all done I'll probably give it some official name like the Soharix planetary FPS engine.

So far we have the following engines which can be combined at any time on any project:
FPS/3PS/Topdown engine (The main engine we've been upgrading and working on since MarvinTheMagician (any game engine we used before that we now refer to as the John_engine due to their similar complexities and hard coded aspects)
Racing/Driving engine (The engine we're using in conjunction with DarkPhysics in WorldOffRoad)
Host|Client network engine for DBP_net and DarkNet (Although we are discontinuing the use of the DBP_net engine as the Host application, regardless of the simplicity in its task will constantly use up virtual memory; DarkNet does not do this) - (This engine is being used with the Racing driving game to create the online experience we hope to provide in WorldOffRoad)
Menu engine (Currently being upgraded by TheComet)
2D platformer engine (Currently being used badly in Happy Isle)
Space engine (Never actually released a game of any great substance using our space engine because it's a bit simplistic and basically just an adapted version of the FPS engine)
Topdown shooty enginey thing (We only used it once and it was made purely for Zone; we've not used it since and don't really intend to. )
Planetary rotation engine (Currently being worked on in this thread )

So I guess, having said that, what I'm really going to do is combine the planetary rotation engine which is already solid with the FPS engine to make either a recognisable hybrid or just call it a new engine. - Undecided yet, :S - depends how much changes.

Sven B
21
Years of Service
User Offline
Joined: 5th Jan 2005
Location: Belgium
Posted: 28th Aug 2010 14:33 Edited at: 28th Aug 2010 14:35
[edit] Meh there was already a solution...

Cheers!
Sven B

C0wbox
20
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 28th Aug 2010 20:07
@ Sven B
Hah, yeah sorry, the thread got solved pretty early on and it's now all a discussion about other things related.

C0wbox
20
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 29th Aug 2010 00:05 Edited at: 29th Aug 2010 00:10
Ok people, we've got a chance to help again xD

I attempted to gather the Ynormal of the ground to determine whether to stick the player or whether to slide it but because we're dealing with a sphere not a flat map, this doesn't apply.

Is there a way I can get the player's normal and subtract them or something so I can determine what the angle of the slope the player is stood on is? (If I can get that angle, I can manage the rest (for once) xD)

EDIT:
Ok, having said that, no the method I'd use to "stick" the player to the ground if he was on a shallow slope also wouldn't work as there is no sc_getstaticcollisionsortofYaxis() command xD - I fail.

Dr Tank
17
Years of Service
User Offline
Joined: 1st Apr 2009
Location: Southampton, UK
Posted: 29th Aug 2010 02:37 Edited at: 29th Aug 2010 02:40
Again you'll kick yourself.

You want to change the y-component of the collsion normal for the component in the "up" direction. The up direction (unit vector) is got in my snippet- it's very simple to get- it's the vector from the centre of the planet to the position you're at, normalised. To get the collision normal component in this direction, dot the collision vector with the up direction unit vector.

BTW "Zone" on a planet would be sweet.
C0wbox
20
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 29th Aug 2010 03:07
@ Dr Tank
!!! I'm afraid I don't know how any of that works in DBP. - I've only used vectors properly on paper so I don't actually know what I'm doing anymore xD

(And making Zone on a planet would just be Super Badass Spaceship X by Mr Tank. So I won't be going down that line. )

Dr Tank
17
Years of Service
User Offline
Joined: 1st Apr 2009
Location: Southampton, UK
Posted: 29th Aug 2010 04:10 Edited at: 29th Aug 2010 04:13
You should buff up on vectors sometime - they're really useful, and probably not as hard as you think. I guess you're more concerned about getting an working engine ASAP than understanding how it works, which is fair enough. I can help when I have a spare hour or two. Would be helpful to have an idea of what kind of mechanic you want. I'm guessing something like the Sparky "sliding demo"- the one with the grassy pyramid and the mini balls. Porting that should be pretty easy.

BTW SBSX isn't really on a planet- it's fake. The mechanics are on a simple wrapping square world, and the bit you see is sort of "draped" over the top of a ball. Means some stuff is much simpler, although downsides are that everything is repositioned each frame, and I can't use 3rd party collision because of the space wrapping.

Would be cool to do a proper planety version at some point, but envision difficulties with lighting (It can be day or night if you can go around the planet), and the level editor, which can't use a simple grid for the whole level. I imagine you'll run into issues like these and I will be interested to see how you address them.
C0wbox
20
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 29th Aug 2010 13:27
@ Dr Tank
I have your last sliding demo implemented perfectly into Splanet and you can see what we're doing with it here the only issue left to address is stopping the player sliding down all hills and across all floors. In our main FPS engine we have this code being used to determine whether to slide or not:


(Not that exact code but that sort of principle, in the collision part of the main loop.)
(MYSLOPE# is usually like 0.65)

What I can't get my head around is how to use vectors to do the same sort of thing on the player's respective Y axis, not "the" Y axis.



Even if I did Zone on a planet, I'd get really bored of it and it would be basically the same game all over again anyway. xD
As for making minimaps and things I'd probably cheat and do an ordinary flat minimap that just shows objects in your vicinity and altitude (or slightly lower than your altitude) so it just seems like you've got a minimap and is easy to implement. (Again I'd probably need DBP_vectors though. )

Dr Tank
17
Years of Service
User Offline
Joined: 1st Apr 2009
Location: Southampton, UK
Posted: 29th Aug 2010 21:23 Edited at: 29th Aug 2010 21:36


I've basically ported the second sparky demo. It works, apart from some juddery wierdness on occasion, but I think this may happen with the the original engine anyway. Though it has a number of features that I find unsatisfactory, like air control, no momentum, I expect this is the mechanic with which you are familiar.
C0wbox
20
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 29th Aug 2010 22:48
@ Dr Tank
Ay, air control and aresto-momentum is fine for what we need.

I'll have a wee look at this snippet when I get a chance and incorporate it into Soharix Planet.

Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 6th Sep 2010 11:44
I submit this simple approach.

Forget working out the curved motion of the player across the 3D sphere (while forgetting about problems with uneven terrain).

1. Instead rotate the planet. Maybe even use sparkys collision to ray trace the xyz of the players position on the surface to help with uneven terrain.

2. Have the player always have a relative orientation to the center of the planet (best explained as when standing straight down always points to the center of planet). Then he moves forward relative to direction he faces. Use some math to carry the players vector. As he moves forward feet always point down to center so he slightly rotates. Have gravity always add vector to center of planet. Hit scan the collision with the ground.

Ok i think i got it with #2.

C0wbox
20
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 6th Sep 2010 16:38
@ Mage
Umm, yeah... - you clearly haven't read anything that was already posted. - That problem got sorted out after about the 5th post. :S
(I also said I wasn't going to rotate the planet for the fact I'd also have to rotate everything else on the planet so I would be rotating hundreds of objects and orientating them instead of just 1.)

Login to post a reply

Server time is: 2026-07-22 19:27:34
Your offset time is: 2026-07-22 19:27:34