Gravity Shift Trouble
Blitz3D Forums/Blitz3D Programming/Gravity Shift Trouble
| ||
| I'm working on a 3D game in which the gravity shifts to the angle of whatever you are standing on. Kind of like Super Mario Galaxy. Originally, I had it just constantly move the player's relative Y down each frame, and align them to the collision normal if there is one. The problem with that was if the player walked off an edge, the gravity wouldn't adjust to the side of the object they walked off because they are no longer colliding with it. I thought a better technique would be to find the closest triangle in the level mesh to the player, and align gravity to that triangle's normal. Unfortunately, I couldn't decipher the few codes for point-to-triangle distance I found. Also, as a last resort, I figured I would have to set up "gravity-zones" where the gravity changes when the player enters one. Does anyone know of a better method to determine what direction the gravity should be, or can supply a get-closest-triangle-in-mesh code? |
| ||
| I figured I would have to set up "gravity-zones" where the gravity changes when the player enters one I advise that you go straight to this. 1) It will be much faster, and much simpler, than trying to force this data out of trimeshes, when (depending on the mesh) it may not match up with the intuitive behaviour and may not even be clearly defined. The maths to check if a point (player) is within a 3D region is rather simpler than the maths to do all sorts of complicated transformations against an entire list of polygons. 2) Point of principle: it's "cleaner" to design your mechanics first and have the graphical assets build detail on to them and represent them. It's almost never a good idea to try to extract meaningful data for gameplay mechanics from your art assets; you're working backwards, doing a lot of work to construct central themes out of ephemeral detailing. The gameplay mechanic information is more important than the visuals, so it should have the "primary" existence (in an ideal world, you shouldn't even have a mesh yet). i.e. It shouldn't be a last resort: the last resort is using mesh data for anything other than rendering. EDIT: Of course reading your question I realise I've made certain assumptions that could be wrong, so... perhaps the easiest way to get the "closest" triangle would simply be to iterate across all tris, and get the averaged position of each one's three vertices, then test for distance of that point from the player? As long as your level doesn't do anything odd like have wild variations in triangle size or intersecting polygons, it should be accurate most of the time, especially if you're using a simplified collision mesh (one assumption: that you weren't using one). Last edited 2011 |
| ||
| How would I go about doing a curved surface, such as a ramp? That requires the gravity to be changing constantly as you go up it. How would I do that with regions? Would I have gravity always coming from a point? perhaps the easiest way to get the "closest" triangle would simply be to iterate across all tris, and get the averaged position of each one's three vertices, then test for distance of that point from the player? That would fail if the player was on a large polygon, because if the player was near a small polygon while on the edge of a large polygon, smaller polygon would get chosen, even though the player is right smack on top of the larger. |
| ||
| That would fail if the player was on a large polygon, because if the player was near a small polygon while on the edge of a large polygon, smaller polygon would get chosen Hence the need for a collision mesh that conforms to a stricter set of rules than an arbitrary Blitz mesh. You'll be able to use much more efficient techniques if you disallow your algorithm from trying to solve all possible problems: use triangles of the same size. The simplest thing I can think of that would actually solve that example error would be to test that they're within the bounds of the triangle (viewed from its normal), and if so get the plane of the triangle and measure their distance from it - that's quite a bit of calculation. Would I have gravity always coming from a point? Any reason why not? Assuming that your maps have both curving surfaces and large flat areas in relatively even proportion, I would have two+ kinds of region: point-effect and plane-effect gravity. When within the space of a point-effect region, gravity moves towards a specific point; otherwise, it moves in a given direction. You could even combine techniques and add a third kind of region that does use polygons in areas of the map with very complex geometry, but stick to using the simpler models of gravity when the map is simple enough to let you. I think to a large extent which model will work best also depends on the nature of your maps... a huge amount of detail and complexity where every surface always means a gravity shift might well work better with triangles; if you have a larger, more open world where the player can move about a bit on any given surface and small edges don't mean a change in gravity, regions would be better. Last edited 2011 |
| ||
| OK, for what I'm doing (kind of like a racetrack) regions sounds like a good idea. So how would I go about defining them? Will I have to make an entire editor just for this or is there some way I can define the using model children...?? |
| ||
| Depends a bit on the shape of the regions, but I'm assuming cuboids and spheres are adequate... Given that the regions don't really do anything as such but simply define areas in space, I would just use a 3D modeller and draw them out as 3D models over the top of the level mesh, and export the file separately (as a hierarchical anim mesh). Regions would simply be defined as a single cube or sphere object, plus a second object (a pivot if your modeller lets you place those) to determine the direction of gravity. Set the region-kind and shape (cuboid or spherical) with one of the many mesh attributes available (e.g. vertex colours, use a different material surface for each style, use the Entity Name string). I'd then load this as an anim mesh (to preserve the hierarchy, as mentioned), and use the pivot and vertex data to create the regions as logical objects (then discard the mesh, as it's not needed). How you do this... is largely up to you, as there are dozens of ways to interpret data. Couple of other points: firstly, if you need regions to move, it may pay to have them represented as groups of pivots in B3D, and then you can parent them to objects. Secondly, one thing I would do is make the regions smaller than necessary (so none of them overlap), but have objects continue to observe the rule of the last region they entered: that way, you don't ever need to consider the case of conflicting priorities. (e.g. upon entering a straight section your racer receives the command to "fall downwards from this point on"; at the end of the straight, they enter a new rule about sticking to a curve.) Moral of the ramble: anything that involves simple positions in 3D space can usually be defined with any old 3D modelling application, as long as you're willing to reinterpret the resulting mesh data rather than just dump it straight into your scene as an actual visible prop. |
| ||
| OK, thanks for you help and sticking with my insanely specific questions! |
   |