Horde3D

Next-Generation Graphics Engine
It is currently 29.03.2024, 10:43

All times are UTC + 1 hour




Post new topic Reply to topic  [ 3 posts ] 
Author Message
 Post subject: For Applying Physics
PostPosted: 09.01.2012, 21:01 
Offline

Joined: 09.02.2011, 17:02
Posts: 83
Helloo

I have walls that i created in max exported them and after converting them. I used it in Horde3D game engine. '

For my keyboard controlled agent I have to make it avoid walls, I wrote a code by which I avoid walls by calculating the distance to the walls,
and as soon as it reaches in a certain distance i stop translating it in positive direction and rather translate it in negative so tht it moves away from
the wall.
does any one has an idea that shows that if I want to apply physics on the wall, which function is suitable. I want my agent to stop when it is about to
collide into the wall. I want to apply some physics that avoids my agent to collide into wall.


By taking a decision based on distance i m not able to get good results because when the distance will remain same I mean when my
agent will keep closer to the wall¨then i will not be able to move it back. (and some other issues also)
Thanks In Advance


Top
 Profile  
Reply with quote  
 Post subject: Re: For Applying Physics
PostPosted: 03.02.2012, 00:34 
Offline

Joined: 01.11.2011, 02:23
Posts: 5
Hi imranhabib,

Naturally the task is not directly handled by Horde3D, which is purely a rendering engine and does not handle physics-based calculations for you. It does, however, provide raycasting functionality which you can use for determining the distance of your character from a given wall (from your post, I assume you already have the collision distance worked out). I gave a basic approach to solving this in another topic which you've also commented on, so you use that for manually working out distances too. With that in mind, you can progress in one of two main ways; incorporate a self-contained physics engine (such as Bullet, PhysX, Havok Physics, etc.), or write your own collision response.

Integrating an existing physics engine will give you far greater functionality when dealing with physics meshes, character controllers, collision detection and response, as well as access to more advanced features (ragdolls, hinges/joints...) for later development. Depending on your requirements, this would be a comprehensive solution to almost any physics-related problems you come across. If you want something more lightweight, however, you may want to consider writing your own collision handler.

As I understand it, you have a method of finding the distance the agent has from a given wall - if your requirement is simply to not go through the wall (no bouncing off or sliding involved) then this should be no problem to implement manually. Put simply, you need to know whether the agent is being moved towards the wall or away from it; finding the wall's surface normal should suffice. Once you know the direction the wall is facing in, you can compare it to the direction the agent is moving in (not necessarily the direction it is facing, if it can move sideways or backwards for example). As long as the agent is moving in the same general direction as the wall's surface normal, up to +/-90 degrees either way, it should be allowed to move. The quickest way to work out if the two vectors are facing in the same general direction is by finding the dot product of them:
Code:
Vector3 wallNormal(1, 0, 1);      //the direction your wall is facing in (currently 45 degrees)
Vector3 moveDirection(0, 0, 1);   //the agent's movement direction (in this case, directly forward in the z-axis)
float product = GameMath::dotProduct(wallNormal, moveDirection);   //find the dot product
Naturally, the code will vary depending on your implementation. At the very least, you need to calculate the dot product in the following manner:
Code:
static float dotProduct(const Vector3 &lhs, const Vector3 &rhs)
{   //Vectors should be of unit length before this is calculated
   return (lhs.x * rhs.x) + (lhs.y * rhs.y) + (lhs.z * rhs.z);
}

The dot product is commutative, so it doesn't matter which way around the values go. If the result is a negative number then it means the agent is moving into the wall; if he is within the wall's collision distance and the calculated product is negative, then it is colliding. If the result is positive then the agent is moving away from the wall (i.e. in the same general direction as the wall). Therefore, in the example above, the moveDirection is away from the wall and should therefore be allowed (unless it collides with a different wall).

This solution should get you a method which stops your agent moving into the wall, but it will 'stick' to the surface until it tries to move away. There are several ways of refining this, depending on your application's requirements. Sliding along the surface of the wall should be quite straightforward with some number crunching; work out how much lateral movement is left if you subtract the wall's surface normal from the agent's movement, and apply that movement to the agent instead. Other less elegant methods include allowing the agent to move into the wall, calculating how far it has pushed in, and directly relocating it outside of the wall; usually effective, but can lead to tunnelling. There are many more hidden issues whenever physics is introduced, especially when dealing with many objects bunched together.

Hope this helps!


Last edited by Tindros on 06.02.2012, 20:38, edited 1 time in total.

Top
 Profile  
Reply with quote  
 Post subject: Re: For Applying Physics
PostPosted: 03.02.2012, 17:12 
Offline

Joined: 09.02.2011, 17:02
Posts: 83
Tindros wrote:
Hi imranhabib,

Naturally the task is not directly handled by Horde3D, which is purely a rendering engine and does not handle physics-based calculations for you. It does, however, provide raycasting functionality which you can use for determining the distance of your character from a given wall (from your post, I assume you already have the collision distance worked out). I gave a basic approach to solving this in another topic which you've also commented on, so you use that for manually working out distances too. With that in mind, you can progress in one of two main ways; incorporate a self-contained physics engine (such as Bullet, PhysX, Havok Physics, etc.), or write your own collision response.

Integrating an existing physics engine will give you far greater functionality when dealing with physics meshes, character controllers, collision detection and response, as well as access to more advanced features (ragdolls, hinges/joints...) for later development. Depending on your requirements, this would be a comprehensive solution to almost any physics-related problems you come across. If you want something more lightweight, however, you may want to consider writing your own collision handler.

As I understand it, you have a method of finding the distance the agent has from a given wall - if your requirement is simply to not go through the wall (no bouncing off or sliding involved) then this should be no problem to implement manually. Put simply, you need to know whether the agent is being moved towards the wall or away from it; finding the wall's surface normal should suffice. Once you know the direction the wall is facing in, you can compare it to the direction the agent is moving in (not necessarily the direction it is facing, if it can move sideways or backwards for example). As long as the agent is moving in the same general direction as the wall's surface normal, up to +/-90 degrees either way, it should be allowed to move. The quickest way to work out if the two vectors are facing in the same general direction is by finding the dot product of them:
Code:
Vector3 wallNormal(1, 0, 1);      //the direction your wall is facing in (currently 45 degrees)
Vector3 moveDirection(0, 0, 1);   //the agent's movement direction (in this case, directly forward in the z-axis)
float product = GameMath::dotProduct(wallNormal, moveDirection);   //find the dot product
Naturally, the code will vary depending on your implementation. At the very least, you need to calculate the dot product in the following manner:
Code:
static float dotProduct(const Vector3 &lhs, const Vector3 &rhs) const
{   //Vectors should be of unit length before this is calculated
   return (lhs.x * rhs.x) + (lhs.y * rhs.y) + (lhs.z * rhs.z);
}

The dot product is commutative, so it doesn't matter which way around the values go. If the result is a negative number then it means the agent is moving into the wall; if he is within the wall's collision distance and the calculated product is negative, then it is colliding. If the result is positive then the agent is moving away from the wall (i.e. in the same general direction as the wall). Therefore, in the example above, the moveDirection is away from the wall and should therefore be allowed (unless it collides with a different wall).

This solution should get you a method which stops your agent moving into the wall, but it will 'stick' to the surface until it tries to move away. There are several ways of refining this, depending on your application's requirements. Sliding along the surface of the wall should be quite straightforward with some number crunching; work out how much lateral movement is left if you subtract the wall's surface normal from the agent's movement, and apply that movement to the agent instead. Other less elegant methods include allowing the agent to move into the wall, calculating how far it has pushed in, and directly relocating it outside of the wall; usually effective, but can lead to tunnelling. There are many more hidden issues whenever physics is introduced, especially when dealing with many objects bunched together.

Hope this helps!

hello
Thank you So much.
I have carefully read it, but for now i am using another techinque using recasting a ray from keyboard controlled function and hopefully i can use your suggested points also, and if i came up with something i will surely share it
Regards Imran


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 3 posts ] 

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 59 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group