Jump to content

  • Log In with Google      Sign In   
  • Create Account
  1. Viewing Profile: Posts: Steadtler
Watched Content New Content

Awesome job so far everyone! Please give us your feedback on how our article efforts are going. We still need more finished articles for our May contest theme: Remake the Classics

Steadtler

Member Since 31 Jan 2002
Offline Last Active Apr 22 2012 01:41 PM
-----

Posts I've Made

In Topic: Trouble with Recast/Detour

22 April 2012 - 01:44 PM

Then you're down to good old debugging :) Make a simple map with only a flat square surface. Then step in the method and see while it fails.

In Topic: Trouble with Recast/Detour

21 April 2012 - 11:08 AM

Do you have debug display to show the resulting mesh ? Tools are important.

In Topic: How do navMesh work with agents in different sizes?

21 April 2012 - 11:04 AM

CoH's solution seems nice. If you dont need the information to be so dense, you can use a quadtree instead of a dense grid. That would reduce the memory, and the cost of pathfinding, line-of-sight checks, etc.

Im not sure why your string pulling is so expensive, it should be very cheap to do on a grid, as all you need to do is intersecting a vector with axis-aligned lines. If you are sure your maths are optimal, then there is also the fact that you dont need to smooth the whole path at once. You really only need to smooth up to the next "corner", its useless to smooth a whole path that is likely to change.

In Topic: Efficient Line of Sight Algorithm

20 April 2012 - 06:40 PM

You seem to be in 2d. If you just build a simplified representation of your space (navmesh, or since you seem to be grid-based a quadtree) should make your line of sight checks negligible. There is no reason you shouldnt be able to do hundreds of those every frame.

Also, looking at your original code up there, it seems you're working in polar coordinates (angle/distance). Believe my experience when I say its evil. Work with vector algrebra.

In Topic: How do navMesh work with agents in different sizes?

20 April 2012 - 06:31 PM

Always shrink your navmesh for agent size.

We have tested this problem at work and we found that generating several navmeshes - as JT suggest - is far more efficient (less memory AND less cpu cost) than generating one navmesh that supports several agent radii.

  2. » Viewing Profile: Posts: Steadtler
PARTNERS
Copyright © 1999-2013 GameDev.Net LLC


GameDev.net™, the GameDev.net logo, and GDNet™ are trademarks of GameDev.net, LLC

* Not a moderator

Navigation
Customer Service
Company Info