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

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

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

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

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

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]

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

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 ?