Jump to content
  • Advertisement

Andor Patho

  • Content Count

  • Joined

  • Last visited

Community Reputation

286 Neutral

About Andor Patho

  • Rank

Personal Information

  • Interests
  1. One thing you might not have considered yet, is that precomputing the "distance field" or in your case the clear_area function for static obstacles does not mean you cannot consider dynamic obstacles as well. Note, that dynamic obstacles have a localised effect on the distance field. That means you can take the static precomputed field, make a copy of it, recompute or adjust values only in the vicinity of dynamic obstacles, and then use it for pathfinding. That way, instead of map_size number of calculations of clear_area, you do unit_count * unit_influence_area calculations per turn, which should be a much lower number hopefully. Also, just to point this out, if multiple leaders are doing pathfinding in the same turn (which I'm still not sure happens in you game), you can fully reuse the precomputed + adjusted map for each of them (with maybe some minor adjustments so they don't consider their own formation as an obstacle, but I'm sure this can be solved reasonably easily).
  2. Couple of ideas: If you modify your test example to force classic A* to find the indicated correct route (by closing off all passages that are smaller than required), and run simple A* on it, is it faster? By how much? If it is, the problem should be your extra "obstacle finding" addition to A*. If it's not, the problem is your implementation. If "classic" A* is much faster (e.g. order of magnitude or more): you could try running multiple A* searches with clearance, with gradually decreasing the required clearance (thus avoiding the problem of not finding any solution), or running simple A* on multiple versions of the map (which you could get by processing your map with e.g. morphological erosion or something similar that gradually narrows "paths"). You could do the multiple maps in preprocessing, although you mentioned dynamic obstacles, which would mean you would need a clever way of updating multiple versions of the map. If you go the route of multiple searches, you can even do them in parallel. you could generate a distance field on you map to have the path "gap" sizes available without searching locally at every node. If "classic" A* is not much faster, then you have to optimize your code. Try measuring with a profiler. I'm not experienced enough in python to spot a performance problem just by looking at your code, but the usual suspect in algorithms like this is using containers suboptimally - wrong type of container, copying containers when it's not necessary, etc. You can also consider rewriting the pathfinding in C/C++ and calling it from your Python code.
  3. Andor Patho

    Unity Mid Point

    You're still using Vector3.Lerp incorrectly. The third parameter to Lerp is supposed to be a float in the range [0,1] that acts as a parameter to the interpolation. If you pass the same value to it, you will get the same result. Vector3.MoveTowards would be more suitable for what you are trying to do here.   As for the destinationPoint not being correct, you are creating a new Vector in the set_destination method instead of modifying the private variable (the compiler should generate a warning at least). You are also multiplying by 0.5 at the wrong time. You probably want this: void set_destination() { Vector3 vectorToPlayer = player.transform.position - transform.position; destinationPoint = transform.position + vectorToPlayer * 0.5f; } which can also be written more succintly as: void set_destination() { destinationPoint = (transform.position + player.transform.position) * 0.5f; }
  4. Andor Patho

    Unity Mid Point

    Hi,   your immediate issue is this line: Vector3.Lerp(transform.position,destinationPoint, 1.0f * Time.deltaTime); Lerp returns the interpolated value, so if you want the transform position to change, you should do this: transform.position = Vector3.Lerp(transform.position,destinationPoint, 1.0f * Time.deltaTime); The way you calculate the destinationPoint is also weird, but I'm sure you can figure it out with a little experimentation.
  5.   When is your Shooter::update method called? Is it called automatically e.g. every frame? If so, that is what's causing the problem. The movement of your ship is always in the m_angle direction, regardless of the target position, and m_angle gets updated to point toward the mouse position via Shooter::angleShipToMouse everytime update is called.
  6. Andor Patho

    Grid Based Block Placement

    You're right of course, thanks for the correction.
  7. Andor Patho

    Grid Based Block Placement

      There is a more efficient way to calculate what you are after, you basically want the closest larger multiple of the block size to the current number: blockPositionX = BLOCK_SIZE * ((playerPositionX / BLOCK_SIZE) + 1); blockPositionY = BLOCK_SIZE * ((playerPositionY / BLOCK_SIZE) + 1); If you remove the "+1", you would get the closest smaller multiple.   Note that I used sensible variable names and constants to make the code more readable and maintainable, this is a very useful habit to get into, even if you are doing a one-man project.
  8. Andor Patho

    Specfic AI scripting question

    Based on this I would go a step further and spawn a new game object for the friendly entity after the enemy entity dies, effectively replacing the enemy with the friendly. This is the easiest solution I can think of. The only downside is that if other game objects hold a reference to the original enemy and want to keep the reference after it transforms, then you would need to update these references somehow.
  9. Are you sure it makes sense for the PhysicsMover to be a component in the first place? Based on Your description, it seems to me it's some kind of subsystem which might operate on gameobject components, but why would it itself need to be a component?
  10. Yeah, sorry about the vague wording. Glad it's working now, and you're welcome.
  11. Luckily adding the rotation part should not be that hard either. We can just generalize what we did with the position to the entire transform of the object. We want the object to be "frozen" in view space, so we take the entire transform in view space, and transform it to world space.   So instead of taking the ahead position, multiplying with the inverse of the view matrix, then using it in the model matrix, we do it in a slightly different order: Take the ahead position, plug it into the model matrix and then multiply with the inverse of the view matrix.   Sorry if I confused you earlier with doing just the translation part, but maybe it helped you understand what the different parts of a transform do better. Another interesting way to look at this problem is this: you want the object to be frozen in view space, so what you are essentially trying to do is cancel the view transformation (because you don't want the position and rotation of the camera to have any effect on the object's screen position). The way I showed you works, because if you put all the transforms together, you get: Model * View^-1 * View, which is just Model * Identity. If you are able to modify the view matrix for just this single object, you could also just set the view matrix to identity directly, and achieve the same effect.
  12. Let's try to simplify a bit a reduce the code only to the parts that are relevant to getting the ahead position right.   Start with an identity model matrix. Calculate the world-space ahead position from the view matrix as we discussed. Translate the identity model matrix with the ahead position. This should give you a model matrix that transforms model space to the ahead position in world space. Use this model matrix in the standard transformation pipeline. Comment out any other code that is in that function. How does it behave? If it is behind the camera, flip the input (view-space) ahead position, so in the example you posted above change it to [0, 0, -2, 1].
  13. Try multiplying with the inverse of the view matrix. I assumed based on what you wrote, that the view matrix contains the camera position and rotation, and your transformations get applied as model * view^-1, but the view matrix might already be inverted, so it contains the transformation into view space from world space. That would mean you need to go the other direction, and need to invert the view matrix.
  14. When you are moving the player position around, the ahead position does not change, which means the translation component of your view matrix doesn't seem to affect it (rotation seems fine). I think I see the problem:     You use the Mtx_MultiplyFVec3 function, which guessing by the name multiplies matrices with a 3-component vector. I'm guessing if you pass a 4-component vector to it, the 4th component gets ignored (or considered 0), which in this case is quite important, in short if the 4th component is 0, the vector represents a direction and magnitude not a position, so it can only be rotated, not translated. If this sounds confusing, read up a little on linear algebra. If you work with 3d transformations, the minimum you have to understand are the components of the 4x4 transformation matrix (rotation, translation, scale), and how it behaves with vectors using homogeneous coordinates. If you work out the matrix multiplication on paper, you will see how the 0 or 1 in the 4th component changes the outcome.   Short answer: see if you have a variant of the matrix multiplication function for 4-component vectors.    
  15. If I understand you correctly, you want to calculate the world space position of a point a certain distance straight ahead (in the camera look direction) from the camera. That should be pretty straightforward: take the position of your point in view space - assuming "into the screen" is +z in your coordinate system, this would be a point with coordinates P[0, 0, distance, 1], and multiply it with your view matrix. This should give you the coordinates of your point in world space.
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!