edge grabbing in 3D platformer
Hello everybody!
I have recently learn to use BLITZ3D and it's amazing how efficient and fast it is to make 3D game with, it's even easier than making 2D game as it handle anything fundamental like animation, camera and collision with breeze!
That's how i have start to code a 3D plateformer in the like of Mario 64. So far so good, after 2 weeks of work i have even done more thant previously plan without prior knowledge in 3D game making. Now i start to increase my ambition, from a "showcase" prototype i want to do a fully playable game but still educational for me. My goal is to implement nearly all the mario move in the game. The game woud be a pure and simple platformer, only platform and the character and collectible.
But the things i didn't expect is that i have no idea how to do "grab edge" efficiently in 3D. I mean without tagging the level prior to the play, i want it systemic so the player can thrust his ability and not read the designer's thought.
Anyone have an idea, did this idea was discuss before in another topic?
EDIT: After thinking a little more about my post, i think i need to precise the problem more!
What i want is "viable edge detection for grabbing onto an arbitrary mesh in runtime" :) of course the viability of edge is decide by parameter to tweak
How about making a physics bounding box to represent the player's arms? Take a look at this drawing:
When the player jumps, the green bounding box will be checked for collision with the environment. If you detect a collision between the bottom of the green box and the environment(the solid blue box), and the player's normal bounding box(red box) does not stand on anything, you know you should activate ledge hanging.
When the player jumps, the green bounding box will be checked for collision with the environment. If you detect a collision between the bottom of the green box and the environment(the solid blue box), and the player's normal bounding box(red box) does not stand on anything, you know you should activate ledge hanging.
Thank you and nice try ;)!
But i have already thought about that...
The problem is that it detect a surface not the edge
I could not "snap" the edge and you may have an offset from the edge :(
It's not elegant also if you want your character to move along the edges!
But i have already thought about that...
The problem is that it detect a surface not the edge
I could not "snap" the edge and you may have an offset from the edge :(
It's not elegant also if you want your character to move along the edges!
You can check for the angle between the green box and the surface. If it's too steep, you know it's not an edge.
As for moving along the edges, you can check the intersection between the face in the surface that collides with the red box and the face in the surface that collides with the green box, and use that line as the direction of the movement.
As for moving along the edges, you can check the intersection between the face in the surface that collides with the red box and the face in the surface that collides with the green box, and use that line as the direction of the movement.
Instead of doing real time checks maybe procedurally determine grabbable edges during level compile time. Essentially making the designers choices for them; if you have a level editor you could then go in and check which edges have been made grabbable and fine tune it.
I think you would basically be using a similar algorithm as the real time check just adding hints for the game engine to use during run-time.
I haven't ever thought about or implemented this before, so that idea can be considered well and truely half baked :p. I have for some reason a nagging feeling its been implemented like this in some commercial game, though I could be dreaming that :p
I think you would basically be using a similar algorithm as the real time check just adding hints for the game engine to use during run-time.
I haven't ever thought about or implemented this before, so that idea can be considered well and truely half baked :p. I have for some reason a nagging feeling its been implemented like this in some commercial game, though I could be dreaming that :p
Well the point is still missing...
If i do that i will not get the correct alignment of the character along the planarity of the surface, since the only information i get is the normal of a triangle.
Plus in term of gameplay it is really weak, the character would not be able to grab if it came from below, plus depending of the framerate and the player's motion, there can be "miss" that felt unnaturel...
If we study this little video above (Ok it's in 2D and it's easier to do in 2D, but i want to achieve the same effect) we can see that the grab happen to a certain distance to the edge, wether the character is going up, down or even left or rigth and have a satisfying "targeting" snap to reposition the character on the edge. The feeling of control is very important to me so that's why i have kept the project focus on manipulating the character, edge grab is a big part of it.
Also i ant to achieve contextual grabing like in zelda, when the character is below an edge and the pressing of the button target him toward that edge within an height range.
I cannot achieve those effect with that simple solution (which is a correct way to do it but doesnot serve my need).
If i do that i will not get the correct alignment of the character along the planarity of the surface, since the only information i get is the normal of a triangle.
Plus in term of gameplay it is really weak, the character would not be able to grab if it came from below, plus depending of the framerate and the player's motion, there can be "miss" that felt unnaturel...
://www.sirlin.net/blog/2008/11/9/smash-bros-brawl-tutorial-videos.html
If we study this little video above (Ok it's in 2D and it's easier to do in 2D, but i want to achieve the same effect) we can see that the grab happen to a certain distance to the edge, wether the character is going up, down or even left or rigth and have a satisfying "targeting" snap to reposition the character on the edge. The feeling of control is very important to me so that's why i have kept the project focus on manipulating the character, edge grab is a big part of it.
Also i ant to achieve contextual grabing like in zelda, when the character is below an edge and the pressing of the button target him toward that edge within an height range.
I cannot achieve those effect with that simple solution (which is a correct way to do it but doesnot serve my need).
Quote:Original post by Guthur
Instead of doing real time checks maybe procedurally determine grabbable edges during level compile time. Essentially making the designers choices for them; if you have a level editor you could then go in and check which edges have been made grabbable and fine tune it.
I think you would basically be using a similar algorithm as the real time check just adding hints for the game engine to use during run-time.
I haven't ever thought about or implemented this before, so that idea can be considered well and truely half baked :p. I have for some reason a nagging feeling its been implemented like this in some commercial game, though I could be dreaming that :p
Fair point, but i still need an idea to get the edge out of it, my intuition says me it's easy but my mind just seems to follow up :(
Everything was coming up so nice until i decide to implement edge grab :/
Quickly I'm going to say use your world up vector, opposite to gravity, and then some edge picking. I'm just having my lunch but I'll come back to this, not much else on today :)
Oh and some extra information about blitz ( http://www.blitzbasic.com/b3ddocs/command_list_3d_cat.php >> the command list )
I cannot pick edge directly, i have only access to triangle and vertex, but i can pick up the closest triangle of an collision or a "pick" (linepick as exemple) within an entity (mesh as ex ), so i need to infer edge by comparing triangle sharing same vertex)
Then saying that the logic would be:
0) on "grab enable" state
1) Pick triangle within a grab radius
2) find edges
3) test edges viability
4) Find the viable edge that match criteria
or maybe there is a better way to do it?
I cannot pick edge directly, i have only access to triangle and vertex, but i can pick up the closest triangle of an collision or a "pick" (linepick as exemple) within an entity (mesh as ex ), so i need to infer edge by comparing triangle sharing same vertex)
Then saying that the logic would be:
0) on "grab enable" state
1) Pick triangle within a grab radius
2) find edges
3) test edges viability
4) Find the viable edge that match criteria
or maybe there is a better way to do it?
If you go with the pre-determined (during compile time) grabbable edge then your runtime code might something like.
Runtime:
0) grab enabled
1) Is Character within range of a grabbable edge? (this would be some hint to the runtime code ie. an invisible line or volume)
2) Grab Edge
The compile-time edge picking might be something like this:
1)Select triangle
2)triangle normal Upwards?
3)Select Edge.
4)does the edge have an adjacent triangle which has a normal greater than 90 degrees from up.
5)Place grabbable edge hint at selected edge
I think I need a diagram to better explain this, and I have probably missed something major; also the complexity of your geometry might have an affect.
Runtime:
0) grab enabled
1) Is Character within range of a grabbable edge? (this would be some hint to the runtime code ie. an invisible line or volume)
2) Grab Edge
The compile-time edge picking might be something like this:
1)Select triangle
2)triangle normal Upwards?
3)Select Edge.
4)does the edge have an adjacent triangle which has a normal greater than 90 degrees from up.
5)Place grabbable edge hint at selected edge
I think I need a diagram to better explain this, and I have probably missed something major; also the complexity of your geometry might have an affect.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement