-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CA_RayCastLineAngle() #4
Comments
Kinda lol moment. I'm completely new to the normals and shit, I came up with the following but it doesn't work. I figured it'd be something along those lines.
The vectors of the CA func always come out to one of the following (it seems):
|
It is kind of confusing not to say the least. |
normX = (P2[0] - P1[0]) * (P3[0] - P1[0]); Then for the vectors I'm sure I have it incorrect. Is should be something like: |
@Crayder your algorithm is valid for tri-meshes, if you are ray tracing at three different points to get a triangle, you are doing it absolutely wrong. What if the object is a sphere or a hull shape or the traced ray is tangent to the surface ? and your triangle can consist of various other tri-meshes which is totally in accurate. Getting the normal can be very complicated.
The main complication here, is getting the hit face and it's vertices. |
|
Did you google it ? (your method) If you did, that site might contain information about triangles, which you passed out. |
I think there is a way to do it in bullet. if(rayCall.hasHit())
{
btVector3 normal = rayCall.m_hitNormalWorld;
} Tell me whether it works or not. |
Well I googled the small things above; I translated it to x, y, and z. |
@Pottus Are you looking for something like this: If I got it wrong, then please correct me. |
Yes, that's what he needs. |
Okay, so if you want to calculate the angle which is made by the ray and the normal. if(rayCall.hasHit())
{
btVector3 normal = rayCall.m_hitNormalWorld.angle(vector); //start or end vector of the ray
} |
Yes picture those lines as objects, I am looking for the correct rotation so that the object would be aligned on the surface perfectly. I will check you pull requests Saturday thanks, I am away for two days. |
Okay, now I get you. I am finding a way for it, looks very difficult though. Yes, do look at the pull request. I have closed two of them because I did some mistake there. Although, there is one open clean request. EDIT: I think it can only be done with objects consisting of meshes because you cannot have a vertex on a spherical child shape. |
What do you mean by "spherical child shape"? I'm pretty sure every object has a triangular mesh, even spheres. Look at JernejL's collision mesh (wireframe) layer in Map Construction, it has triangles for every object's collision. These triangle faces are all you would need to do this. Is it possible to get the three points of the face collided in bullet? |
All samp objects consist of meshes but not all gta objects contains meshes, I guess. |
Yes, I think renderware consider spherical objects as a polyhedral shape. I am not sure about bullet's consideration. Okay, test it with object, 2887, 19789, 2896, 2942. They don't have meshes at all and they are quite inaccurate in terms of their shape, especially object 2942. |
The objects have multiple meshes (i.e. collision mesh, and the other one). Also, spheres are not spheres in terms of gta objects.
Those also have meshes. They are just a few of the exceptional ones that do not have a good collision mesh. SInce their collision mesh is so simplified you could just take three corners and work like a trimesh. You can use any three on the same face, they will all give the same vectors. |
What's "the other one" ?
That's what I said, they are polyhedral.
No, they do not have collision trimeshes. They only consist of texture mapping meshes, textures and collision volumes.
Well, how will you determine their face ? GTA SA does not provide vertices for collision volumes, just only for meshes. |
If that's your argument, then mine is how will you determine the vertices on the trimesh? Apparently it's being done already or we wouldn't have the RayCastLineAngle function.
Obviously they can, you even said so just after you said this:
Exactly. They have both a collision mesh and a texture mesh. Here is my favorite example (other than the 3065's collision vs texture mesh): Obviously, the texture mesh is not the same as the collision mesh. The collision mesh is what ColAndreas detects. On this silo object RayCastLineAngle actually returns perfect values, just noting. |
We can determine the vertices of trimesh, they are actualy provided in .col files. I've answered your "argumentative" question. Now, you answer mine. For the silos, it clearly shows that they only consist of texture mapping meshes and collision volumes. If it had collision mesh then it should have a convex hull mesh on the top of it. |
I think you just answered it yourself, no need. If those are provided there must be a way to get the vertices of the quad meshes like that the silos have. Like I said before, the silos return perfect angles, and they do not have a trimesh.
The outer box is the collision. So aren't we both correct there? |
We shall not say it as a quad mesh (or poly mesh) because old games contains only trimesh. The silos only have a texture mesh and a collision volume. Collision files does not provide vertices for collision volumes and never will, because we actually do not need it and I did not answer myself, I guess. What angles are you talking about ?
Kinda, you said it's a mesh and I said, it is a collision volume. mesh =/= collision volume |
true
The angles returned by RayCastLineAngle, obviously... :P |
Yea, it returns the slope so it will be accurate. |
The point of this issue is finding a way to get the 'slope' of all surfaces in the collision. That's why we need three points and a normal. Go to the performRayTestAngle function in DynamicWorld.cpp to see where the current math is. It's only X and Y, but it works in most cases (like the silos for example XD). There are a few surfaces it doesn't work for such as the sides of some buildings, fences, some ground, and other objects. |
Yea, I understood now what he meant by slope. |
@Pottus is this what you wanted ? btVector3 hit = rayCall.m_hitPointWorld;
btVector3 normal = rayCall.m_hitNormalWorld;
float angle = hit.angle(normal);
float rX = (hit.getX() * cos(angle)) - (hit.getY() * sin(angle));
float rY = (hit.getY() * cos(angle)) + (hit.getX() * sin(angle)); Oh wait, you need the angles. I can try. |
Basically what we need to do is find the rotation needed to make an object parallel to a surface given the surface's normal. |
What we really need is a version of Unity's That Unity function aligns an axis of an object with a surface normal. This is exactly what we need to do. So, does anyone have the source code of that function? :3 |
https://github.com/libgdx/libgdx/blob/master/gdx/src/com/badlogic/gdx/math/Quaternion.java Contains Quaternion functions. |
The closest thing I found to |
Perhaps this (4th post) is what we need? http://www.bulletphysics.org/Bullet/phpBB3/viewtopic.php?f=9&t=10790 If not maybe you could post there and provide a better explanation. |
I think this is more accurate than the rx/ry version. nx, ny, nz: Normal Vector Also, the new mesh fix added in 3c5cfc4 seemed to fix the old normal vector bugs (the one that would cause rotations to be off by a few degrees). |
I don't think that will work right to be honest currently it works when placing objects on the ground. |
It works perfectly, I've tested it a lot and can provide you results. Here are just a few, taken in multiple directions.
Here is the code I used to ensure the algorithm worked.
|
Lets see |
See as in you're going to test it or as in you want to see pictures, or what? XD |
Pictures lol |
K, a sec |
I think I like the rX/rY angle version better still. With the rX/rZ version rotating on the z axis afterwards fucks things up. The fix still stands however, I haven't received any odd rotations yet. |
Sounds good. |
Will this be more accurate? rx = acos(nx) * RADIAN_TO_DEGREE; //nx normal x of the hit point
ry = asin(ny) * RADIAN_TO_DEGREE; //ny normal y of the hit point
rz = 0.0; |
This function needs to be updated to return the correct rx/ry/rz angles for in game objects. I've tried a lot of different things but I am still unsure how to accurately translate the normal to an object rotation in that the object would align perpendicular to the orientation of the collision plane.
I am hoping some math guys out there could figure out the steps to do this correctly it is very important for advanced mapping features.
The text was updated successfully, but these errors were encountered: