Unity Community


Page 4 of 7 FirstFirst ... 23456 ... LastLast
Results 61 to 80 of 130
  1. Keyboard operator

    Location
    Copenhagen, Denmark
    Posts
    2,929
    Ah. Sorry. I thought that was in this thread. Oh well - now it is. Thanks for bringing it up

    Regarding your illustrations of zig-zagging pathes: Please don't confuse the actual followed path with the debug rendering (the one you're referring to) the debug rendering simply serves to show the order of the polygons in the path.

    I do indeed plan to get a better NavMesh for the demo, but in this beta stage I've set that on low priority. This author is not a very good 3D artist, but I'm betting on that not being central in peoples decision of using the system or not.

    Regarding the path following script and its abilities, I highly recommend you read the documentation at http://angryant.com/pathdoc.html and shift through the example code provided in the demo project (its not much).

    I don't get which features you're missing from the pathfinding functionality and which you're requesting in a path following script. Currently the only parameter used aside from distance in pathfinding is the radius of the path finding agent. More are coming in 0.4b.
    Emil "AngryAnt" Johansen

    Game developer, AI specialist, Unity expert
    Freelancer, ex Unity Technologies

    AI in Unity, tips and tricks: http://angryant.com, http://twitter.com/angryant

    Coding bare-footed grants you extra CPU cycles!


    Want to play? http://angryant.com/freelance/
    Behave 2 is out! http://angryant.com/2013/12/23/Behave-2-2/
    Check out ReView!

  2. Creative Programmer

    Location
    Copenhagen, Denmark
    Posts
    636
    Quote Originally Posted by AngryAnt
    Regarding your illustrations of zig-zagging pathes: Please don't confuse the actual followed path with the debug rendering (the one you're referring to) the debug rendering simply serves to show the order of the polygons in the path.
    I'm not confusing them - that's why I explicitly created a thick orange trail showing the *actual* path followed. My point is that this actual followed path takes a route that is far from optimal within the traversed polygons. And I don't just mean that it should be smoother - I mean that it makes several turns that are not necessary and ultimately does not follow the shortest path possible (again, within the triangles used).

    Rune
    Rune Skovbo Johansen - Creative Programmer at Unity Technologies
    unity3d.com | runevision.com | my blog

  3. Keyboard operator

    Location
    Copenhagen, Denmark
    Posts
    2,929
    Ah right. Now I get what you're saying!

    While it's still in the realm of path following, I'll make a note of it for an updated path following script for the demo
    Emil "AngryAnt" Johansen

    Game developer, AI specialist, Unity expert
    Freelancer, ex Unity Technologies

    AI in Unity, tips and tricks: http://angryant.com, http://twitter.com/angryant

    Coding bare-footed grants you extra CPU cycles!


    Want to play? http://angryant.com/freelance/
    Behave 2 is out! http://angryant.com/2013/12/23/Behave-2-2/
    Check out ReView!

  4. Administrator
    Location
    Indianapolis, IN
    Posts
    1,070
    If I'm following this discussion correctly, the real distinction being made (after removing mesh creation - whether by an artist or programatically) is between path finding and path following with Path being concerned only with the former? More specifically, that the distinction between finding and following should be made after sequencing polygons? (that the route through the polygons falls under "following"?)

    I wonder if users will intuitively understand the distinction between the two or if they will view them as all part of the same problem and see the line between finding and following as being blurry. The challenge, I suspect is in the demo -- to demo path finding, you need to implement path following. If you implement something that is efficient and generalized enough to make a good demo, you have effectively expanded the scope of the project to include both. If you implement something that does the minimum required to move across the path that you have found, users might mistake poor path following for poor path finding.
    Charles Hinshaw


  5. Location
    Austin, TX
    Posts
    29
    I've been following this thread as well, and I think you make a very good point. Speaking as an artist, I do find it easy to blur that line. I can picture what I want to happen with the game object, and that seems to overshadow what is really necessary programmatically.

    So I guess the question from my point of view it, once the path is found, doesn't the next step become use specific? I.e. the pathfinding is creating a set of point information that is then passed along to another function. Along those lines, isn't the navmesh itself specific to your use? For example, a wandering, ambient NPC would have a much coarser navmesh than an AI-using, fighting NPC?

    My thinking is that the resulting path issues being discussed are potentially better or worse depending on what navmesh you wind up with and ultimately what the routine is 'looking for' when it's developing the path.

  6. Keyboard operator

    Location
    Copenhagen, Denmark
    Posts
    2,929
    Charles:
    You're spot on. And the recent discussion in this thread has made it very clear to me that once I get to a release, I'll have to beef up the demo and the documentation heavily.

    dhogan:
    Not quite. The idea of the Path project is to have one system using one set of data (one collection of inter-connected Nav Meshes) for all pathfinding in a game or other simulation.

    The reason why I've chosen to abstract path following as much as it is, is because of the wide range of different aspects path following may or may not need to cover in a project.

    To illustrate the benefit of using an abstracted path following mechanism, take this as an example:
    You've got a city simulation with three types of AI controlled entities: A citizen, a policeman and a car.

    The citizen could be implemented very simply by having a set roaming area decided by a spread of pathes to choose from. These could very well be calculated once and then stored and reused over and over. Should one or more of the pathes become invalid by a building collapsing and blocking a street or something like that, the citizen script would be notified by the Path system and an appropriate response could be implemented (most likely the calculation of a new path between the points previously connected by the now invalid path).

    The car could also use a similar mechanism, but its path following routine would be quite different as it'd need to take turn radius etc. into account.

    If the policeman was implemented with a simple two-state behaviour patrol and pursue, it would be able to re-use much from the citizen script, but for the pursue part it'd need much more dynamic scripting.

    Despite the different behaviour, these three entities would still use the same system, operating on the same dataset for all their pathfinding needs.

    While designing this system I very decided to abstract rather than finitely implement path following for this very reason. I believe that this way the programmers using the system will have a desirable level of freedom without having to do too much legwork on their own. Rephrased: I believe that further development and direct integration of path following would restrict the developers to an undesirable level.

    I've got some features in the pipeline for extended dynamic path finding by storing more meta data in the Nav Mesh itself - I'll put up a more detailed description of the idea behind the system once those are stable as that'll hopefully make things more clear.
    Emil "AngryAnt" Johansen

    Game developer, AI specialist, Unity expert
    Freelancer, ex Unity Technologies

    AI in Unity, tips and tricks: http://angryant.com, http://twitter.com/angryant

    Coding bare-footed grants you extra CPU cycles!


    Want to play? http://angryant.com/freelance/
    Behave 2 is out! http://angryant.com/2013/12/23/Behave-2-2/
    Check out ReView!

  7. Creative Programmer

    Location
    Copenhagen, Denmark
    Posts
    636
    Quote Originally Posted by dhogan
    So I guess the question from my point of view it, once the path is found, doesn't the next step become use specific? I.e. the pathfinding is creating a set of point information that is then passed along to another function.
    I think this is what AngryAnt is arguing, but I'd still say that string-pulling is a pretty integral part of a NavMesh implementation with only smoothing being use-specific (see attached image).

    Quote Originally Posted by dhogan
    Along those lines, isn't the navmesh itself specific to your use? For example, a wandering, ambient NPC would have a much coarser navmesh than an AI-using, fighting NPC?
    No, one of the advantages of NavMeshes is that you only need one. The same NavMesh can support small and big characters, and is independent of their behavior.

    Rune
    Attached Images  
    Rune Skovbo Johansen - Creative Programmer at Unity Technologies
    unity3d.com | runevision.com | my blog


  8. Location
    Austin, TX
    Posts
    29
    Ah, I see! Thank you both for a good explanation!


  9. Location
    Frankfurt Main / Germany
    Posts
    47
    @AngryAnt

    what I see, is, you have a problem with the conversion of A*. Because the shortest way is not always found. Try the over-lying corners.
    Heinz

    Unity 2.5 Pro, iMac, OSX 10.5.7, Maya 2009, Modo 401, ZBruch 3.1

  10. Administrator
    Location
    Indianapolis, IN
    Posts
    1,070
    Quote Originally Posted by HJPuhlmann
    @AngryAnt

    what I see, is, you have a problem with the conversion of A*. Because the shortest way is not always found. Try the over-lying corners.
    I don't think that is correct or what anyone is suggesting -- it appears to be finding the shortest sequence of triangles to travel. I think Rune's diagrams on string pulling and smoothing are helpful to demonstrate why it doesn't appear to be the shortest path.
    Charles Hinshaw


  11. Posts
    280
    So.. Will this system work with Unity Terrain as the navmesh? I know you can read the angle ( relative to 0 = flat ) of a terrain tri( the fps controller prefab script does it ), but is that enough?
    while(!(succeed = try()));

    Unity 2.6
    2.8 GHz Core 2 Duo
    4 GB Ram
    Radeon HD 2600

  12. Keyboard operator

    Location
    Copenhagen, Denmark
    Posts
    2,929
    HJPuhlmann:
    None of the examples shown in this thread reveals any bugs in my A* implementation. I have however found some cases where a faulty route will be returned - this bug has been fixed in my current build and will be made available in 0.4b.

    Dragon Rider:
    The idea of a Nav Mesh is that you have an extra mesh, used for navigation, which estimates the surface being navigated (for instance a unity terrain).

    This means you can indeed navigate a unity terrain, but using the terrain itself as Nav Mesh would not make sense - way too many polygons which would generate outrageous pathfinding times.

    In stead, for a level with a terrain, I'd export the terrain to a 3D application and in that create a simplified mesh which estimates the terrain.
    Emil "AngryAnt" Johansen

    Game developer, AI specialist, Unity expert
    Freelancer, ex Unity Technologies

    AI in Unity, tips and tricks: http://angryant.com, http://twitter.com/angryant

    Coding bare-footed grants you extra CPU cycles!


    Want to play? http://angryant.com/freelance/
    Behave 2 is out! http://angryant.com/2013/12/23/Behave-2-2/
    Check out ReView!


  13. Location
    Frankfurt Main / Germany
    Posts
    47
    Awesome, I'm looking forward to see the further development.
    Heinz

    Unity 2.5 Pro, iMac, OSX 10.5.7, Maya 2009, Modo 401, ZBruch 3.1

  14. Administrator
    Location
    Indianapolis, IN
    Posts
    1,070
    Quote Originally Posted by Dragon Rider
    So.. Will this system work with Unity Terrain as the navmesh? I know you can read the angle ( relative to 0 = flat ) of a terrain tri( the fps controller prefab script does it ), but is that enough?
    If you wanted a simple way to create a NavMesh from a terrain, you could probably just scale the height data (as if you were scaling an image) and then create a mesh from that. You would end up with a simplified mesh roughly matching the terrain. You could then check the normal of each triangle and if the triangle is too vertical to be navigable, you could remove it.

    This wouldn't be a very nice mesh, but it could be generated quickly with little code if you had a terrain that was generated programatically, for example.
    Charles Hinshaw


  15. Location
    California, USA
    Posts
    577
    To learn 3d modeling, I set to work on a test area and animated critters for AngryAnt to use in demoing his project. This is unfortunately still in the works as I did not know a polygon from a spline when I started (and still sometimes feel over my head), but in any case a finalized package should be shipped to AngryAnt before another month passes.

    My strategy for creating the nav mesh is as follows:
    ( 1 ) Construct terrain object in Unity.
    ( 2 ) Add to the Scene with other 3D assets. (Things like cliffs that need good texturing on vertical faces for example)
    ( 3 ) Export terrain's height map from Unity.
    ( 4 ) In Cheetah3D create a "Relief" object using the exported height map.
    ( 5 ) Fiddle with Relief object's polygonal resolution before making it editable as a Mesh. (Will need to find the sweet spot of overlap between minimal polygons, and usefulness.)
    ( 6 ) Factor in obstructions from other 3D assets not expressed by the heightmap (like trees, and other 3D assets plopped into the scene), and remove these areas from the Nav Mesh.
    ( 7 ) Export Nav Mesh to Unity.
    ( 8 ) Orient Nav Mesh to sit just over the Terrain Object, and put on an unrendered layer.

    I have gotten as far as step 5. Steps 3 - 5 once you know what you are aiming for take about 10 minutes tops.

    I have an idea about how to handle Step 6, but would like to finish my area and talk with AngryAnt about it before leading any of you astray. Steps 7 and 8 are easy.


  16. Location
    The sunken city of R'lyeh
    Posts
    2,061
    In most A* implementations I've seen the 'smoothing' involved recursively traversing the calculated path and removing unneeded nodes. For example, the system calculates a shortest node to node path of a->b->c->d->e. It then determines if a->e is actually traversable and if so removes b, c and d. Your avatar then moves in a straight line between the a and e nodes, the true shortest path.

    There are other unity related questions I would have, the main being node 'weighting.' Take say, a path across a body of water and a path around it. If weights (essentially a proxy for movement speed) are taken into account then in certain circumstances crossing the river might be faster than moving 100 yards downstream to cross a bridge. I'm unaware of any way in Unity to determine the terrain 'type' other than maybe somehow sampling the texture under your feet? Being able to somehow insert this proxy info into the navigation mesh would be useful if not..

    Lastly, you had said last spring that you had yet to load test your implementation with a slew of characters. Have you got around to that yet? Curious as to wether or not C# is going to be fast enough for heavy use of this, as opposed to a pure C++ implementation. Especially as the number of avatars and the resolution/size of the navigation mesh grows.

    Great work and looking forward to Path getting out of beta stage one day!

  17. Keyboard operator

    Location
    Copenhagen, Denmark
    Posts
    2,929
    I'm currently focusing all my energy on the Behave project. As Path was my first unity project, I had to redesign quite a bit while developing it, as I learned the ways of unity. Furthermore, the addition of the EditorWindow class in unity 2.1 opened a lot of possibilities which I'd really have liked to have when I first started the Path project.

    Therefore, as soon as I have the Behave project at a stage where I can throttle down development a bit (which isn't that far into the future), I will begin redesigning large parts of the Path project. I will be taking all input from the community into consideration while doing this plus my experience in working with editor scripts in the Behave project.
    Emil "AngryAnt" Johansen

    Game developer, AI specialist, Unity expert
    Freelancer, ex Unity Technologies

    AI in Unity, tips and tricks: http://angryant.com, http://twitter.com/angryant

    Coding bare-footed grants you extra CPU cycles!


    Want to play? http://angryant.com/freelance/
    Behave 2 is out! http://angryant.com/2013/12/23/Behave-2-2/
    Check out ReView!


  18. Location
    Stockholm, Sweden
    Posts
    904
    Hi.
    is it possible to use the terrain as the pathfinding mesh?

  19. Keyboard operator

    Location
    Copenhagen, Denmark
    Posts
    2,929
    Currently no. And I have no plans to make it a feature. The terrain is way too polygon heavy to serve as a navmesh.
    Emil "AngryAnt" Johansen

    Game developer, AI specialist, Unity expert
    Freelancer, ex Unity Technologies

    AI in Unity, tips and tricks: http://angryant.com, http://twitter.com/angryant

    Coding bare-footed grants you extra CPU cycles!


    Want to play? http://angryant.com/freelance/
    Behave 2 is out! http://angryant.com/2013/12/23/Behave-2-2/
    Check out ReView!


  20. Location
    Stockholm, Sweden
    Posts
    904
    Darn! Do you know about another pathfinding system using the terrain(or can handle a massive amount o polys)?

    /Aron

Page 4 of 7 FirstFirst ... 23456 ... LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •