Mohsen Zarsanj

Members
  • Content count

    18
  • Joined

  • Last visited

Community Reputation

137 Neutral

About Mohsen Zarsanj

  • Rank
    Member
  1. Hi everyone. I'm working with physX 3.2 and going to write an OnCollisionEnter, OnCollisionStay and an OnCollisionExit for a physics engine. I have implemented a sample filter shader like this: [CODE] PxFilterFlags PhysXSample::SampleFilterShader( PxFilterObjectAttributes attributes0, PxFilterData filterData0, PxFilterObjectAttributes attributes1, PxFilterData filterData1, PxPairFlags& pairFlags, const void* constantBlock, PxU32 constantBlockSize) { if(PxFilterObjectIsTrigger(attributes0) || PxFilterObjectIsTrigger(attributes1)) { pairFlags = PxPairFlag::eTRIGGER_DEFAULT; return PxFilterFlag::eDEFAULT; } pairFlags |= PxPairFlag::eCONTACT_DEFAULT; pairFlags |= PxPairFlag::eNOTIFY_CONTACT_POINTS; if (filterData0.word2 & FilterDynamic::eCCD || filterData1.word2 & FilterDynamic::eCCD) { pairFlags |= PxPairFlag::eRESOLVE_CONTACTS; pairFlags |= PxPairFlag::eSWEPT_INTEGRATION_LINEAR; } if((filterData0.word0 & filterData1.word1) && (filterData1.word0 & filterData0.word1)) { pairFlags |= PxPairFlag::eNOTIFY_TOUCH_FOUND; } else { return PxFilterFlag::eSUPPRESS; } return PxFilterFlags(); } [/CODE] and an onContact function: [CODE] void CollisionCallback::onContact(const PxContactPairHeader& pairHeader, const PxContactPair* pairs, PxU32 nbPairs) { for(PxU32 i=0; i < nbPairs; i++) { const PxContactPair& cp = pairs[i]; if(cp.events & PxPairFlag::eNOTIFY_TOUCH_FOUND) { } } } [/CODE] eNOTIFY_TOUCH_FOUND works fine but the problem is that I don't know how to tell the shader to notify the eNOTIFY_TOUCH_PERSIST and eNOTIFY_TOUCH_LOST, and if they are notified, how to catch them in the onContact function. is there anybody who can help me on this? I would really appreciate.
  2. Help with Obstacle Avoidance Behavior

    [quote name='IADaveMark' timestamp='1350359156' post='4990601'] Shoot random rays in a cone ahead of you. 1 per frame. If it hits, immediately shoot another one straight forward. The orientation of the two points where the two rays hit (if the 2nd one hits at all) gives you a picture of whether the obstacle is angled toward or away from your immediate direction of travel. It also gives you an approximate angle that the object is oriented at. Therefore, you could choose to turn far enough to align parallel to the object (or farther). [/quote] Well I understand all you said except the first sentence. "Shoot random rays in a cone ahead of you". what's "in a cone" supposed to be?
  3. Help with Obstacle Avoidance Behavior

    [quote name='slicer4ever' timestamp='1350326054' post='4990466'] if you draw a straight line between the avoider's center, and the obstacle's centers, then take the line from the avoider to it's destination, whichever side the line is on relative to the center line, is the side you should turn toward. [/quote] Well that's interesting. I'm going to try it and see what the result will be. thanks.
  4. Help with Obstacle Avoidance Behavior

    I got what you said but just a little problem: which way to turn? I mean suppse there is an agent moving straight ahead in the forward direction to reach a target and between them lies an obstacle. now at a certain distance the agent detects the obstacle and decieds to turn away. which way should it turn? right or left?
  5. Help with Obstacle Avoidance Behavior

    [quote name='slicer4ever' timestamp='1350213114' post='4990014'] [quote name='zar2012' timestamp='1350209138' post='4990009'] well I understand that but let me clarify my problem. suppose there is a cube with 10 unit long and 2 unit width. when the agent is walking along this cube, it must be way at least 2 units away, but if I use a circule, it walks at most 5 units away when it reaches the middle of the cube. I think it would make more problems with rectangular obstacles bigger this assumption. [/quote] yes, you don't have to decompose the cube the way i did, that's just generally the simplest solution. to use your example in a better light, if you take a line from your avoider, to it's destination, and it intesects the barrier, then you need to get two points that create a perpindicular line from the obstacle, so, with the cube, you can fire a ray from the center of the obstacle, towards the perpendicular directions, and take those points as your obstacle radius, this gives you a variable sized circle based on the direction of the avoider, to the obstacle. but as you can see, we still end up with a circle, regardless of how the object is decomposed, this is why the papers give solutions in terms of circles, the solution generally requires a point of some distance away from the obstacle in order to avoid collision, and since a circle defines such a shape, that's why it's used as the agent which is presented, since it's simple, and easy. it's up to you to select an algorithm which can accurately decompose the object. if you look up the RVO2 library, and look at the source code, it has an algorithm for decomposing non-circle objects to generate the obstacle cone's. [/quote] Thank you. I will look at the source code to see what I get.
  6. Help with Obstacle Avoidance Behavior

    [quote name='IADaveMark' timestamp='1350236161' post='4990089'] This circle discussion is odd. If you are shooting rays for detection of objects -- static or dynamic -- then any convex hull that can register a hit will do. [/quote] Yes I can shoot rays to detect objects but the problem comes after it finds an obstacle. actually I don't have any algorithm to avoid it.
  7. Help with Obstacle Avoidance Behavior

    well I understand that but let me clarify my problem. suppose there is a cube with 10 unit long and 2 unit width. when the agent is walking along this cube, it must be way at least 2 units away, but if I use a circule, it walks at most 5 units away when it reaches the middle of the cube. I think it would make more problems with rectangular obstacles bigger this assumption.
  8. Help with Obstacle Avoidance Behavior

    [quote name='slicer4ever' timestamp='1350171112' post='4989923'] [quote name='zar2012' timestamp='1350152727' post='4989846'] Hi everyone. I'm facing some issues while implementing the steering behaviors such as wall or obstacle avoidance. I share these issues with you as some questions and hope you could help me. 1 - Why do we need to use wall or obstacle avoidance at all when we use A* search algorithm as we know that it ignores obstacle nodes in the search. 2 - the implementation of obstacle avoidance I've accomplished is the one explained in the book Programming Game AI by Examples which use steering behaviors for a 2D space. Shoud I take advantages of raycast or collision detection instead for implemening such a behavior in a 3D space or that one is enough? 3 - Any obstacle avoidance behavior explanation I've seen either in the book or on the Internet assumes that the obstacles are circles. what about for rectangular obstacles? Is there any differences in the calculations? [/quote] 1. A* is a great pathing system for a known environment, if you can design your system in a way that A* is fine enough for avoidance systems, then by all means, solely use A*. however, sometimes A* can only be used for generating an overview of the path to take, but doesn't describe how the object should reach a node, particularly for highly dynamic scenes, where an fixed A* grid is simply not precise enough. At the end of the day, it's upto you to choose how your objects well get from point A to point B. 2. I can not comment, as i've not read the book. 3. a circle is used because that is simply the shape which you will always end up with. since obstacle avoidance relies on generating one(or two) points that allow's your avoiding obstacle to avoid the other object, you've successfully generated a circle(which is a center point, and a radius, the radius is the distance from the center, to this arbitrary point.) since any object well have to be decomposed into a circle to be successfully avoided, then it's simpler to only work with circle's when presenting the idea. [/quote] Thanks for answering slicer4ever. but what if we have a rectamgular cube with a long length and short width in the middle of the room? should we consider it as a wall? in this case we can't determine any circle since the length and the width are not the same size.
  9. Hi everyone. I'm facing some issues while implementing the steering behaviors such as wall or obstacle avoidance. I share these issues with you as some questions and hope you could help me. 1 - Why do we need to use wall or obstacle avoidance at all when we use A* search algorithm as we know that it ignores obstacle nodes in the search. 2 - the implementation of obstacle avoidance I've accomplished is the one explained in the book Programming Game AI by Examples which use steering behaviors for a 2D space. Shoud I take advantages of raycast or collision detection instead for implemening such a behavior in a 3D space or that one is enough? 3 - Any obstacle avoidance behavior explanation I've seen either in the book or on the Internet assumes that the obstacles are circles. what about for rectangular obstacles? Is there any differences in the calculations?
  10. Smoothing a path calculated by A*

    yes I did. both on on the web and this forum. but almost everywhere they would refer to the article I mentioned above. otherwise I would never start a new topic for this. If there is anything I'm missing please just let me know.
  11. Hi everyone. I need to know if there is any way to smooth a path gained from the standard A*. I store the path as indces of each tile of the grid into a std::list<unsigned int>. I've actually read the article "Toward More Realistic Pathfinding" in Gamasutra but since the sample code is not available, it's hard for me to understand it correctly. so I would be grateful if someone could help me on this. thank you.
  12. Navigation Mesh Generation

    thanks everyone. you were really helpfuhl.
  13. Navigation Mesh Generation

    [quote name='snowmanZOMG' timestamp='1347657036' post='4980187'] [quote name='zar2012' timestamp='1347653301' post='4980158'] Well since a navmesh's nodes are much less in comparison to a grid's, I thought it will be more useful to spend time on it to generate. actually we are a team programming a 3d game engine and we don't want to step in the wrong way. I think you're right about the performance. I exmined the situation and found out that we run the pathfinding on the same thread as the game and AI was running and I suppose we should have it being run on a separate thread. But again, as we are designing a 3d game engine we do not want to start our work with a grid representation and in the middle of the work (maybe some months later) we notice that we should change our pathfinding system. So I take your advice and will examine the current situation more accurately but I think you agree with me that a navmesh would be really really faster than a grid representation in similar circumstances. [/quote] Again, it depends. If the nav mesh results in a drastically smaller number of nodes to search (which is usually the case), you will of course gain some performance. But if you were to end up with a similar number of nodes, you may not see a performance improvement and have done a ton of work for effectively no gain. I do agree that navigation meshes are "better" in some sense, but don't be so quick to drop your current implementation if they suit your needs already and your performance is the only thing that's an issue. A grid based approach has advantages due to their simplicity. The simplicity does have its own cost though, such as more sensitivity to area if you have a uniform grid and the need to have a higher number of nodes if you wish to have high accuracy. When going to a navigation mesh, you'll often find that you have to do more than a graph search as well to get some decent results. When I switched my pathfinding to use a navigation mesh, I had to implement string pulling and add in some extra logic to detect when units of non-zero radius were pathing through the level (which is non-trivial, many people end up with multiple navigation meshes to handle this). It sounds to me that you may benefit greatly from navigation meshes, but in ways other than performance. Unless you reduce the number of nodes you have drastically, you won't see that much of a performance improvement. [/quote] What you said led me to the conclusion that we must fisrt implement a navigation mesh to see if it could be useful or not and there is no prediction. still, I need to know the great benefits of using navigation meshes because almost everywhere I've read that they are more efficient and I don't have any prior experiences about it.
  14. Navigation Mesh Generation

    [quote name='zar2012' timestamp='1347653301' post='4980158'] [quote name='snowmanZOMG' timestamp='1347649223' post='4980142'] Are you sure the grid representation is the cause of slow performance? I'm not convinced that going to a navigation mesh just on the grounds of performance is the wisest idea. The performance of your graph search depends on many factors, and people often assume it is their representation that is at fault, when it may not be the case. The layout of your data structures for the graph can have an enormous influence on the performance of your graph initialization. Your underlying data structure for the priority queue can also have a large effect on performance. The nav mesh may be a better choice if you notice that performance degrades significantly as the pathable area increases, since nav meshes can be less sensitive to area. But your observation of the performance being reduced when the [i]number[/i] of agents increases, makes me believe that a nav mesh will not necessarily improve performance. This implies that your graph initialization is slow or your graph search is slow due to a poor choice in a key data structure. Possibly even the heuristic. Bottom line is, I'm not sure it is worth switching over to a nav mesh. Unless you have prior experience, you'll spend a significant amount of time trying to set up the navigation mesh and then altering the search portion to account for the nav mesh. When you finally have it done, you may come to discover it's not that much faster than your original implementation since it may still have the root problems that cause slow performance as your original. [/quote] Well since a navmesh's nodes are much less in comparison to a grid's, I thought it will be more useful to spend time on it to generate. actually we are a team programming a 3d game engine and we don't want to step in the wrong way. I think you're right about the performance. I exmined the situation and found out that we run the pathfinding on the same thread as the game and AI was running and I suppose we should have it being run on a separate thread. But again, as we are designing a 3d game engine we do not want to start our work with a grid representation and in the middle of the work (maybe some months later) we notice that we should change our pathfinding system. So I take your advice and will examine the current situation more accurately but I think you agree with me that a navmesh would be really really faster than a grid representation in similar circumstances. [/quote]
  15. Navigation Mesh Generation

    [quote name='snowmanZOMG' timestamp='1347649223' post='4980142'] Are you sure the grid representation is the cause of slow performance? I'm not convinced that going to a navigation mesh just on the grounds of performance is the wisest idea. The performance of your graph search depends on many factors, and people often assume it is their representation that is at fault, when it may not be the case. The layout of your data structures for the graph can have an enormous influence on the performance of your graph initialization. Your underlying data structure for the priority queue can also have a large effect on performance. The nav mesh may be a better choice if you notice that performance degrades significantly as the pathable area increases, since nav meshes can be less sensitive to area. But your observation of the performance being reduced when the [i]number[/i] of agents increases, makes me believe that a nav mesh will not necessarily improve performance. This implies that your graph initialization is slow or your graph search is slow due to a poor choice in a key data structure. Possibly even the heuristic. Bottom line is, I'm not sure it is worth switching over to a nav mesh. Unless you have prior experience, you'll spend a significant amount of time trying to set up the navigation mesh and then altering the search portion to account for the nav mesh. When you finally have it done, you may come to discover it's not that much faster than your original implementation since it may still have the root problems that cause slow performance as your original. [/quote] Well since a navmesh's nodes are much less in comparison to a grid's, I thought it will be more useful to spend time on it to generate. actually we are a team programming a 3d game engine and we don't want to step in the wrong way. I think you're right about the performance. I exmined the situation and found out that we run the pathfinding on the same thread as the game and AI was running and I suppose we should have it being run on a separate thread. But again, as we are designing a 3d game engine we do not want to start our work with a grid representation and in the middle of the work (maybe some months later) we notice that we should change our pathfinding system. So I take your advice and will examine the current situation more accurately but I think you agree with me that a navmesh would be really really faster than a grid representation in similar circumstances.