• Advertisement
Sign in to follow this  

edge grabbing in 3D platformer

This topic is 3286 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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...

://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).

Share this post


Link to post
Share on other sites
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 :/

Share this post


Link to post
Share on other sites
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 :)

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Oh great!
I did think about discriminatng the triangle from the normal, cool idea

Also i was already thinking about extreme case, for exemple what if the systeme snap a "crack" in a model, i mean if two edge are too close and would get the model stuck in a imposiible place? OF course this is a problem that could be allievate by using correct metric in level design, but just in case of it's a good thing to prevent these things. Also it's easy to discrimate edge that are too small on grab or too close but still need to consider them (for exemple if we could move along the edge).

Thanks for that input

but now i must discover how to do a line to sphere collision...

Share this post


Link to post
Share on other sites
You'll need to check for both triangle normals attached to the edge, to determine if it is grabbable.



red are no-go, black are potential good edges.

Also, there is the environment around. What would happen if the the edge was like very close to another surface, or if the character could simply jump over from below, ect...

Share this post


Link to post
Share on other sites
Thanks for the input! I have plan some study about the edges really like yours Oliii, fortunately illustrator crashed i cannot post them now...

This is amazing that there is so little documentation about this and how crazy my first attempt was :)

Share this post


Link to post
Share on other sites
i have done this little study to see case for a tagging at level compilation time.

http://img89.imageshack.us/img89/5413/grabedge3cc3.jpg
<br/>

But we must assume close mesh, with self intersection , and without fan...
An interesting edgy problem is the fan, the double sided and "folded" triangle

Share this post


Link to post
Share on other sites
Is there any reason you wouldn't want designers/artist to tag which geometry is an edge grab?

When our studio created Daxter, a 3d platformer, we first created a system that automatically detected which edges should be 'edge grabs'. We moved away from that system in the end because it allowed the player to get to places where he shouldn't be. The artist and designers wanted more control.

The system we put in place was a tagging system. We would tag geometry as wall climbable, death, floor, normal collision and a few other random game specific tags. When the level geometry was processed during the build stage it would create the 'edge grab' list. It would determine which one were 'grabbable' by checking if adjacent floor geometry was a wall. If it was then you could grab on to it.

Of course, Daxter's hands had to get close enough to the geometry to grab onto it so any wierd geometry cases that you were drawing out wouldn't happen because of his body's 'collision geometry' wouldn't allow him to get close enough. When Daxter's hands were close enough, and a few ray casts would tell us that info, we snap his hands to the ledge.

I don't know how Mario 64 did it but I know of a few more commercial titles that do it that way as well. I think the method works very well unless you have procedural or user created content - only then would you have to automatically determine which parts of the geometry are edge grabs.

-= Dave

Share this post


Link to post
Share on other sites
Hello David thanks for your input, it's great to see that people already had that experience!

http://www.gdcradio.net/Daxter.jpg

Tell me more about the raycast? I'm not sure i visualize that in details, you cast ray AFTER having collided the edge for grabbing?

Thinking a little more, i guess you first process all edge for proximity (i have yet to figure how to do this since they are not point and can span some length), then find the edge that face the character's hand and at the end process the closest point of the line?

But i'm a designer and not much a real programmer.

Quote:
Is there any reason you wouldn't want designers/artist to tag which geometry is an edge grab?


However having worked on AAA like canned game, having make a pandora tomorow mod, and having done some research before, i'm well aware than most studio use tagging as a mean to navigation in the game world. I have to admit that my original post is somewhat vague about that and my claim about mario must be overdone (however my experience with the game and most N64 era nintendo game shows any king of weird case that hint a no tagging but collision mesh based navigation).

The reason i choose to investigate a more systemic approach is because i don't have a studio to tag level, it has a cost. For a Game studio hiring people to do that is most cost effective in term of time, quality and money. Also most triple AAA game have a great part which involve with linear and script scenography, having the player go anywhere any time is a big no no to not break the intended flow. Automated process in such situation is a mean to save time and does not necessary seek the state of the art since R&D bring some risk and cost money and time.

Investigating this solution is really an exercise to investigate the problem and is short coming and eventually finding solution to these shortcoming toward a more robust solution. The game I plan is a pure and simple plateformer without any sense of scripted encounter, that mean that sequence breaking is part of the game as a gameplay, for which the focus is exploration. This design choice that fit the constrain of automation and let me explore the case. The other solution is to put constrain on level editing regarding respect of metrics... But artist...

Yes most game artist, coming from a fine art (instead of graphic design and information design), want "chaos". We always have the fight against them as designer are all about grid align and metrics, but this is a designer control project ;)

EDIT: short answer, the player should thrust and read the world not the designer's idea :)

[Edited by - Neoshaman on January 20, 2009 4:47:00 AM]

Share this post


Link to post
Share on other sites
Daxter would shoot a ray from his chest in a direction that was computed from his velocity. If the ray collided with a polygon it would check the polygon to see if any of its edges were tagged as an edge grab. If the edge was an appropriate edge to grab then it would snap its hands to the position.

The scheme worked well because Daxter's hands were close together it wont work if the players hands are far apart then you have to take into account two ray casts.

-= Dave

Share this post


Link to post
Share on other sites
I have already check splinter cell pandora tomorow, and lately mario64 et tomb raider

Tomb raider level editor tutorial:
http://www.skribblerz.com/tutorials.htm
Does not seem to feature edge tagging but the level are structured and edited in a rigid ways with grid, so it must happen in compilation time or in realtime since the level geometry is "readable".



Interestingly looking at this video we can se that it cover more case i previously thought (grab after a slope with a vertical wall)

Mario 64 level hack editor:
http://jul.rustedlogic.net/thread.php?id=419
I have browse the tools and the forum to see if there is some hint, it seems that the only things which is important is the collision mesh, no tagging per see

I wonder how many game that feature grabing have a level editor, so we can find hint from editing ?

Share this post


Link to post
Share on other sites
perhaps you could do the opposite:

Calculate all the possible edges, but -exclude- all the edges that lie in special exclusion bounding boxes.

This way you would place some big bounding boxes around the places you don't want your players to go, and you simply generate all the rest automatically...

Just my 2 cts

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement