What Techniques Are You Guys Using...
Blitz3D Forums/Blitz3D Programming/What Techniques Are You Guys Using...
| ||
| ... for keeping an object (vehicle, player,etc) on the ground and following the ground (terrain) variations? Thanks In Advance --Mike |
| ||
| all i do is apply constant gravity, so even when a vechicle jumps or somthing it is still forced to the ground. |
| ||
| Me 2 |
| ||
| I do a linepick straight down every frame to determine how high up my player is and then react accordingly. I don't just apply a constant force straight down because I don't want gravity acting while the player is on the ground. If gravity were acting all the time then the player would be constantly sliding downhill unless the ground beneath him is perfectly level (routine indoors but not common at all outdoors/using terrain.) |
| ||
| the simplest solution, moveentity,character,0,gra,0 ; ever what your gravity constant is or you can also use the "translateentity" command just do check to see if the player has collied with the ground, that way you wont slide down hill's ect. ....... Havent talked to you in quite a while Mike, we need to get together for another chat like before. Zmatrix |
| ||
| Store a Y-Velocity# variable for each object you want to have gravity for. Increase this by a constant amount, and move your object downards by it (each second). If you detect a collision with the ground, set Y-Velocity# back to 0. In an indoor level, check the collision normal to see if it is indeed the floor, not a wall or ceiling. I'm not sure if you need to know how to make the object follow the slope of the ground, but if you do, here's how: Firstly get the global X/Z co-ordinates of the front and back of your object (probably with TFormPoint and MeshDepth() to check the object length). Then do some trig to find the angle between them and set your object's pitch to that angle. You can also do the same with all four corner points to get pitch and roll but that's a little more complex. |
| ||
| Thanks Guys for the tips... Does the current Blitz collisions slow down the engine any? I mean, checking sphere to poly collision every tic, does that have a negative effect on the performance of a Blitz app? I was wary that this might be the case, and was doing something similar to the linepick solution that JH suggested. Hey There Z... ... yeah, long time no see. What have you been working on lately? I did want to relate to you some problems I've been having using CShop to make objects, and lining them up em with the ground and volumes in RAD. Also, the Maptool thingee works fine in Blitz .b3ds, but nothing shows up when I try to see .X format meshes... Someone over there is tying to convince me that he can get a RAD net app to connect to 64 people at a time, so I guess we'll all get together over that... keep an eye on the board. --Mike |
| ||
| inmy (rather limited) experience, collision detection rns extremely fast,and slowdown is negligible compared to general rendering etc. I think it's because its all worked ot internally, with just the few quick checks made to see which entities and/or vertices collide. But then again, Others I am sure will give you better, more accrate answers :) |
| ||
| Blitz collision seems to be considerably faster than using LinePicks. Use it, it's very good :) |
| ||
| I use meshes and based on where the character is on the tile, the programme calculates the height based on the vertices of the triangle the character is on. |
| ||
| It mostly depends what exactly you need to do. If all you need is to keep the vehicle stuck to the ground Linepicks are overkill. But for other things the additional information you get is necessary. In many cases you will need to know stuff which gets returned using the various PickedSomething commands. |
| ||
| OK... thanks again guys... --Mike |
| ||
| Hey again Mike, I had a few problems with maptools .X export also, i dunno what i did...illegal geometry maybe...but i converted it with Deepex and it became visible. also i have trouble with the B3d export. i get it to export, but then have no control over the object. it wont scale or accept collision data. (I think Josh posted a way to fix this on the cshop forum...but i havent gotten around to going there to find it yet) play with the pick commands...they can be quite handy, im working on a level editor..or constructor maybe i should say,It loads objects. its not a modeler. good for laying down grass,trees,rocks ect. As for 64 players in 3dRad,,,yeah its "Posible" by that i mean they would probably connect.lol but Peer/peer starts to slow significantly after about 6 players. you might get 16 on a lan.(ive never tried so i dunno) but it will be interesting to see the outcome,,ill try to join in if he gets it ready. Zmatrix |
| ||
| Z... it loaded into Deep Exploration??? Hmmmmm... crashes mine (an older version). Lemme try it one more time :) Thanks --Mike |
| ||
| yeah it will load into mine, all the textures in the Wad file you are using are the same in the maptools folder? first time i made mine i used jpgs in the wad creation and bmp in the folder...so ofcourse they didnt show up. you can always try sending the .x to me and ill see if it visble on my system. Zmatrix |
| ||
| I use Linepicks aswell. I tested the speed and I can do about 5000 of them every game loop without any noticable slowdown. No-one should ever need to use that many tho'. |
| ||
| I use gravity, collision and Entitypick. The EntityPick is to make sure a character DOESNT fall through the floor. |
| ||
| Flameduck/edzup/... I could do with some advice in this area as well I've a lot of vehicles moving over a fairly complex mesh terrain and I've been doing line picks at each vehicle's four corners to set height and also calculate pitch/roll for each vehicle. However I'm doing this way too often and its killing the framerate. I can reduce the frequency, but would a better method be to say, use four pivots with a collision radius at a vehicle's corners and apply a downward force to them at each update (which I haven't tried yet)?. Has somebody tried this/any ideas along this line? |
| ||
| You could actually avoid collision detection altogether and simply calculate the height of the terrain mesh DIRECTLY from the underlying data. Since the underlying mesh is on a regular grid, it's pretty easy to determine the actual ground level at any point above the grid. A B P C D To determine the height at P simply interpolate the heights at A, B, C, D. The easiest way to do this is to interpolate along opposite edges and then on the line between them: A e B P C f D All the necessary divisions (in essence 1/g, where g is the size of the grid) can be done once and cached, so this operation only requires adds and multiplies and should be VERY fast. |
| ||
| Pod Thanks for the idea - as my terrain verts are fairly loosely modelled in Lightwave there's not a one to one regularity with the underlying pathfinding grid and it does allow for much more irregular levels. So instead I've instituted collision pivots at a vehicle's four corners, keeping them in place and moving them downwards each cycle and it works very well. The bad thing is that having eliminated 90% of the linepicks, it's really pointed up the 'flabbiness' of my code in terms of logic being pretty much updated each frame, the particle engine taking a chunk o' cpu even without any particles set up(!), number of surfaces, loadmesh vs copyentity, interface draw time (a biggy),camera range, man, the list goes on... So alhtough I thought I was close to a demo, I've got a rewrite to do instead ;-9 |
   |