Thời gian thực năng động tìm đường?


19

Tôi hiện đang thực hiện một số nghiên cứu tìm đường và mô phỏng của tôi như sau: Tôi có một cảnh 3d với điểm bắt đầu và điểm kết thúc, tôi có khả năng tạo các mắt lưới điều hướng, điểm tham chiếu và đa giác để hỗ trợ tìm đường.

Tôi đã thử thuật toán A * và một số biến thể của nó và chúng hoạt động hoàn hảo. Tuy nhiên, bây giờ tôi quan tâm nhiều hơn đến việc tìm đường 'năng động'. Ví dụ, trong khi tìm đường dẫn từ điểm A đến điểm B, nếu một chướng ngại vật mới đột nhiên xuất hiện, tôi muốn thuật toán của mình ngay lập tức có thể lập kế hoạch lại một đường dẫn và không bắt đầu tìm kiếm lại từ đầu.

Tôi đã thực hiện một số cách đọc về thuật toán D * và tự hỏi liệu điều này có phù hợp với những gì tôi cần hay điều này có vẻ như là quá mức cần thiết.

Vì vậy, câu hỏi của tôi về cơ bản là: Thuật toán nào sẽ là tốt nhất cho Tìm đường động động thời gian thực? HOẶC sự kết hợp của các kỹ thuật tôi có thể sử dụng thay thế?


Tôi không chắc họ sử dụng thuật toán nào, vì vậy đây không phải là câu trả lời, nhưng tôi tưởng tượng đây là những gì bạn đang cố gắng mô phỏng: video youtube
MichaelHouse

Còn việc mở rộng A * thì sao? Mở rộng những gì được lưu trữ trong các nút của bộ mở / đóng của nó bằng những gì bạn muốn và mở rộng A * để xem xét nó.
dùng712092

Tôi đang tìm kiếm câu trả lời giống như bạn và tôi đã tìm thấy một bài viết về HPA * và nó có liên quan đến trò chơi video. Tôi vẫn đang tìm kiếm bài viết và có lẽ sẽ thực hiện nó. Cho đến nay nó có ý nghĩa với tôi để cải thiện hiệu suất và nó có thể được sử dụng trong cả môi trường tĩnh và động. Đây là bài viết
NelsonPunch

Câu trả lời:


19

D * khá liên quan - Tôi không khuyên bạn nên thử thực hiện nó. Ngay cả khi các dự án được tài trợ tốt và được phát triển bởi những người thông minh / có kinh nghiệm, D * lite vẫn được sử dụng, bởi vì D * là một nỗi đau để có được quyền.

Bạn có thể quan tâm đến phần trình bày này, bao gồm thảo luận về tìm đường của Left 4 Dead:

http://www.valvesoftware.com/publications/2009/ai_systems_of_l4d_mike_booth.pdf

Một cách tiếp cận là sử dụng tìm kiếm cấp độ A * thô để có đường dẫn chung cho một tác nhân, và sau đó thực hiện tìm kiếm mức độ chi tiết tốt A * cho môi trường địa phương của một đại lý. Bằng cách này, bạn có thể nhanh chóng tính toán lại chi tiết khóa học A * nếu địa hình thay đổi, sau đó nhanh chóng tính toán lại chi tiết tốt A * tìm kiếm một đoạn nhỏ của môi trường. Điều này là không hoàn hảo. Nó hoạt động miễn là các chướng ngại vật của bạn không thể chặn nhiều nút biểu đồ chi tiết khóa học, điều này tốt cho hầu hết các trò chơi. Đây là phương pháp tôi khuyên dùng nếu bạn có ít hơn 100 đại lý.

Nếu bạn muốn hỗ trợ hàng trăm, hoặc hàng ngàn đại lý, thì bạn có thể thực hiện một cái gì đó như đám đông liên tục. Xem nghiên cứu này: http://grail.cs.washington.edu/projects/crowd-flows/ Điều đó thảo luận về một phương pháp hoàn toàn dựa trên CPU có thể hỗ trợ hàng ngàn diễn viên trong môi trường động.

Nếu bạn muốn hỗ trợ hàng chục nghìn hoặc hàng trăm nghìn đại lý, thì bạn có thể thực hiện một số thứ như đám đông liên tục, với sự hỗ trợ GPU. Xem tại đây để biết nghiên cứu có liên quan: https://a248.e.akamai.net/f/674/9206/0/www2.ati.com/misc/siggraph_asia_08/GPUCrowdSimulation_SLIDES.pdf

Dưới đây là video chứng minh đám đông liên tục hoạt động: http://www.youtube.com/watch?v=lGOvYyJ6r1c (Chuyển đến 4:10 để xem các chướng ngại vật lớn như xe hơi và đèn chiếu sáng ảnh hưởng đến hàng trăm người đi bộ quanh thành phố.)


Cảm ơn các liên kết. D * Lite dường như đúng với những gì tôi đã đọc
Andrei

9

Bạn đã xem xét các hành vi lái đơn giản?

http://www.red3d.com/cwr/steer/

Bạn có thể sử dụng chúng để xoay vòng từ con đường A * của mình để tránh chướng ngại vật cục bộ, và sau đó lái xe trở lại con đường của bạn sau khi bạn hoàn thành.

Nó cũng khá dễ dàng để kết hợp nhiều hành vi.


+1. Tôi không chắc tại sao điều đó bị hạ cấp. Mặc dù điều này rất đơn giản và có thể không phải là câu trả lời mà người hỏi đang tìm kiếm, tôi nghĩ nó thuộc chủ đề và tôi thấy nó hữu ích :)
Olhovsky

1
Tôi đã đọc và thực hiện hành vi chỉ đạo này trong trò chơi mới nhất của chúng tôi. Bây giờ chúng tôi sẽ thay thế nó một lần nữa bằng các phương pháp khác. Tôi nghĩ rằng nó không hoạt động tốt cùng với các đường dẫn tối ưu được chuẩn bị trước. "Kết hợp" của nhiều hành vi thường mang lại kết quả xấu. Nếu bạn vẫn có kế hoạch sử dụng nó, đừng cố lái và đi theo con đường của bạn cùng một lúc. Thay vào đó, hãy chuyển sang lái 100% và chuyển 100% trở lại sau khi bạn vượt qua chướng ngại vật.
Imi

4

Vì bài đăng của bạn nằm trong phần "Phát triển trò chơi" trong trao đổi ngăn xếp, đây là điều mà hầu hết các lập trình viên trò chơi sẽ trả lời cho bạn: Không phải là về Tìm kiếm động theo thời gian thực, mà là về Đường dẫn động thời gian thực * sau *!

Một số trường hợp cạnh mà cạnh trên biểu đồ điều hướng của bạn hoàn toàn bị cản trở sẽ yêu cầu đường dẫn tính toán lại một đường khác, nhưng hầu hết thời gian bạn có thể chỉ cần điều khiển các thực thể của mình xung quanh chướng ngại vật, dự đoán vị trí và tránh đi đúng hướng. Đối với hầu hết các trò chơi, sẽ rất nặng nề khi phải dự đoán theo thời gian vị trí của các tác nhân động, đặc biệt là khi bạn không thể dự đoán chính xác hành động của người chơi hoặc quyết định đại lý.

Vì vậy, lời khuyên của tôi sẽ là bắt đầu bằng cách triển khai các Hành vi chỉ đạo (http://red3d.com/cwr/steer/), xử lý các trường hợp đường dẫn trở nên không thể và sau đó thêm một lớp trên đầu trang để xử lý các trường hợp cạnh phát sinh ' t xử lý bởi hai giải pháp trước.

Hi vọng điêu nay co ich


À, không. "Đường dẫn theo sau" giống như tìm đường dẫn. Có nhiều cách tiếp cận cho phép theo dõi thời gian thực của hàng ngàn tác nhân khi những trở ngại đang thay đổi, trên một máy tính để bàn. Chắc chắn nó không quá đắt để tìm một con đường cho một tác nhân duy nhất , khi các chướng ngại vật di chuyển xung quanh. Đây là một trong những cách tiếp cận như vậy, trong số rất nhiều: grail.cs.washington.edu/projects/crowd-flows Phiên bản được tích hợp GPU của đám đông liên tục tồn tại.
Olhovsky

Tôi sẽ không đồng ý về điều này. Bất kỳ động cơ nào cũng sẽ coi việc tìm đường và đường dẫn theo hai vấn đề riêng biệt, trong đó vấn đề đầu tiên là tìm kiếm đồ thị của khu vực có thể điều hướng và cái còn lại dự định tìm kiếm vectơ chuyển động tối ưu trong không gian cục bộ. Tôi đã làm việc trên mô phỏng đám đông như vậy sản xuất phần mềm trung gian được sử dụng bởi các trò chơi AAA mà không cần phải dựa vào GPU. Hầu hết các triển khai sẽ sử dụng một trường dòng chảy (đường dẫn) và chỉ đạo để theo dòng chảy và tránh các tác nhân khác (bộ lọc đường dẫn). Như câu trả lời của tôi đã nêu, đây là một câu trả lời "lập trình trò chơi", không phải là một câu trả lời hàn lâm.
emartel

Tôi biết bạn không cần GPU cho đám đông contiuum, đó là lý do tại sao tôi liên kết phiên bản dựa trên CPU. Mô tả của bạn về đường dẫn sau vẫn là tìm kiếm tìm đường, nó chỉ là tìm kiếm tìm đường ở một mức độ chi tiết khác nhau, trên một tập dữ liệu khác. Vì vậy, những gì bạn thực sự có là một khóa tìm đường chi tiết khóa học, và một đường dẫn tìm đường chi tiết tốt. Cuối cùng, bạn đang cố gắng tìm ra con đường mà một diễn viên nên đi theo. Phát minh các thuật ngữ mới cho điều này chỉ gây nhầm lẫn mọi thứ.
Olhovsky

1
Tôi xin lỗi nhưng "con đường theo sau" không phải là một thuật ngữ được phát minh. Đọc các tài liệu được sản xuất trong ngành và bạn sẽ thấy nó được sử dụng nhiều lần: liên kết hoặc liên kết chỉ để liên kết một vài. Thật không may, tôi không thể liên kết bạn với các tài liệu được bảo vệ bởi NDA về động cơ / phần mềm trung gian được sử dụng rộng rãi trong ngành.
emartel

1
Liên kết đầu tiên của bạn là liên kết mà tôi đã đưa ra trong câu trả lời của mình btw. Được rồi đủ công bằng, có thể công bằng khi mô tả loại tìm đường đó là đường dẫn sau. Cuối cùng, cả hai đều cố gắng tìm ra con đường để đi theo, nhưng tôi nghĩ rằng trong trường hợp này tôi đã sai, và chúng ta nên gọi những gì chúng ta thấy trong liên kết thứ hai của bạn là đường dẫn tiếp theo. Ví dụ: hành động liên kết các điểm đường dẫn thô cùng với các đường cong khối / đường cong biezer / insert-your-method-here. Điều đó nói rằng, tôi vẫn không đồng ý rằng việc triển khai tìm đường xung quanh các chướng ngại vật động là không khả thi, vì câu trả lời của bạn dường như gợi ý.
Olhovsky
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.