b3d angle of elevation
Blitz3D Forums/Blitz3D Programming/b3d angle of elevation
| ||
| I've wanged a maplet level together that contains a few ramps and I thought it would be nice if the objects which mill about over the map actually follow the contours properly (ie their pitch alters to suit the particular section of the b3d they are on). I've implemented this a couple of times now, but never to complete satisfaction (dropping a child in front of the parent object so you can point at it is abrupt and runs the risk of the child getting caught up; calculating the angle of incline based on the altering entityY from one frame to another is dependant upon velocity) and I'm wondering if there's a standard way to achieve this effect? As the collision system has sliding built in Blitz is probably holding onto some very handy numbers (ie the severity and direction of any incline diectly beneath a certain object) internally but I bet they're inaccessible :( Any suggestions gratefully received... except that "Tokamak" isn't an answer of course ;) |
| ||
| check the Y directly below you, and 1 unit back from your current position... that will get you a slope value that progresses from one "normal to surface" to another smoothly as you transition on to or off of a slope. check one unit in front and one behind if you want to transition sharply, if either is equal, you are on the level, else whichever has the greatest change in altitude is the slope you are currently on (presuming that you never have a ramp that changes its slope). Hope one of these behaviors suits your needs !! |
| ||
| Thanks for that... I got the basis for a similar system with the child-dropping (unfortunate term) and had a bit of a think about how to refine it at work. I didn't want to spend time doing it long-hand if there was a built-in technique though (too lazy :D), but it looks like this is indeed the ticket. |
| ||
| Sledge, If you already have collisions set up, why not just aligntovector the object based on the collisionNX, NY, NZ but on the Y-axis only. You could also make the level pickable and use a linepick straight down, aligntovector based on the pickedNX,NY,NZ, again on the Y-axis. Either method should work for you unless I'm misunderstanding you ... |
| ||
| why not just aligntovector the object based on the collisionNX, NY, NZ but on the Y-axis only. Mainly because I'm not knowledgeable enough to know that that's what the commands can do... or at least I wasn't. I'll give it a go now -- cheers for the pointers. |
| ||
| wasnt aware of those functions either - much simpler implementation :) I'll get BB figured out one of these days :) |
| ||
| much simpler implementation Not so far... going off the side of a ramp using this (collisionNY etc) method seems to make other axis' than the pitch go out of whack. Compensating for that makes the y-axis wrong again (always points downwards, even when going up an incline). Might try picking next. EDIT: Oh no, worst thing ever! I tweaked the collisions version so that it works fine... but I now have NO IDEA WHY! :P |
| ||
| Sometimes your object collides with more than one thing at a time.Check the CollisionNY() for the first collision. CollisionsNY() Returns a nomalized Vector depending on the angle of the slope. If it is withing a certain range then, and then only align to vector. Just a thought. |
| ||
| Yes I had to allow for collisions with the vertical sides of the map (which the alignment process now ignores). My main problem currently, though, is that the numbers don't add up... well they DO add up, I just don't understand how or why, and that bugs me a bit. (For example the last parameter of AlignToVector [rate] is apparently capping the extent to which the vector is aligned, not the rate of alignment. The alignment also leaves me 90 degrees out, but altering the rate also affects this figure and the extent to which any manual realignment is effected... it's all a mite odd.) I'll take a look at it with fresh eyes tommorow, and I should probably learn what a "normal" is at some point (they sound handy). Just glad it essentially works now, thanks for the help everyone. |
| ||
| Normals, Heck, I'm new to this stuff too... I understand it to mean that it is in a range of Magnitude -1 to 1. But I know that can't be all to it. http://mathworld.wolfram.com/NormalVector.html Regards, Eric |
| ||
| *plug* I've just added this to the code archives: http://www.blitzbasic.com/codearcs/codearcs.php?code=1085#comments It actually draws normals which might give you a better understanding of them. :) |
| ||
| Coo, I'll take a look... well I'll have to as my implementation isn't as robust as I thought it turns out :( |
| ||
| Try something like, nx=collisionNx(entity,collisionNum) ny=collisionNy(etc) nz=collisionNz(etc) aligntovector entity,nx,ny,nz,2 depending on your models orientation you may want to do it on axis 1, or a combination of axis. I've never found one combination that works in all cases.(Across apps that is..once you get it working with the media/set up you have it should be 100% stable..alot better than pointentity, none of that mad rotating going on) |
| ||
| Hooray, it was ME being THICK all along! The Yaw was sliding out of whack because I'm only allowing incremental turning (ie x degrees in total, in equal stages each frame) but I wasn't waiting for one turn to complete before stacking up the next one... meaning you could start a whole new turn halfway through the current one, leaving you half an increment (or so) out at the end. Why was it tied to ramps? Because, due to my level layout, leaping off the side of ramps is the only time you ever turn so quickly as to interrupt an in-progress rotation. Nothing to do with the normal detection, which works fine after all. Phew, eh? aligntovector entity,nx,ny,nz,2 I'm using a variation on that (only the nx,ny & nz calculations go where you have the nx,ny and nz variables... I can understand the benefit it using variables given that we potentially have three axis' to plough through, though) but am curious as to why you would set the rate to 2. I thought it was supposed to be a value between zero and one? |
| ||
| 1 Means X Axis 2 Means Y Axis 3 Means Z Axis He is not using the Optional "Rate" |
| ||
| Ha ha... I looked at the docs and have been typing in "y-axis"! :D That's probably the last piece of the puzzle right there, bet I can make the numbers add up now (God only knows how it has been managing to work as well as it does thus far). |
| ||
| Yes, that was it... the text was being converted to a value and screwing things up I guess -- works exactly as expected now. Top banana everyone! :D |
   |