inter yasin I don't think so. In GTA 5, the GPU is busy enough, I assume. They have just a very good LOD system, which is why they never need to process so many agents every frame. My video demonstrates an edge case, where every agent recalculates its path every frame (to be able to compare the performance in a stress test), which is generally not needed in a game.
Hey Roman Shirokov, in general I would say the use of such a GPU implementation is very limited in video games. It's very fast as it's basically just a lookup of precomputed results. The problem is the amount of memory needed to store those results. It's useful if you really need thousands of agents that need to request a path every frame. A more realistic setting in video games probably only requires a few agents, which don't need to request a path that often. In those cases I would rather use A* as it doesn't use that much memory and is just fast enough. I hope that answers your question :)
Hey! This is pretty interesting shader usage! I love the possibilities that GPUGPU opens up. Could you tell me where did you learn to use compute buffers in Unity? I am pretty good at writing regular vertex/fragment shaders and working with RT's but I can't get myself to learn dx11 stuff. Thanks!
Hi +Michał Piątek, you should really have a look at compute shaders as vertex/fragment shaders are more or less an exploit of the graphics pipeline to get GPGPU. It can be a pain to map computational problems to the graphics context using RTs.This blog helped getting me started with compute shaders in Unity (Scrawkblog DirectCompute tutorial for Unity introduction _Edit: Unfortunately the blog was taken offline and the link was broken, so it was removed_). Also have a look at Aras' sample project, which is a bit hidden in the forums (forum.unity3d.com/threads/compute-shaders.148874/#post-1021130) where he basically shows the DX11 API. This is especially useful when you want to output the results (like drawing procedurally, which I used extensively in my videos). Compute shaders are badly documented but some bits of useful information actually reside on MSDN (here msdn.microsoft.com/en-us/library/windows/desktop/ff476331(v=vs.85).aspx and here msdn.microsoft.com/en-us/library/windows/desktop/ff476405(v=vs.85).aspx ). Let me know if this helped!
@@SnakeEngine Thanks a lot for letting me know! The blog was taken offline a while ago and now it apparently redirects to some other sites. I removed the link.
I didn't really use Unity's navmesh on the GPU. I converted the navmesh to vertex and index buffers as triangles and used that data on the GPU. All possible paths then got precalculated. In real-time, I only had to find the right start and end triangle, look up the shortest path, and straighten the path with a funnel algorithm. See the video description for more details.
I don't know if you are going to read this, but scrawkblog.com is down do you have any resources to learn about compute shader? How does a shader like this that you implented looks in big steps? How does a very simple random procedural mesh generator looks like that gets a mesh or a vector3 array as an input and returns the changes?
Noaman Khalil No, sorry, it's not open source, I'm afraid. What especially are you interested in? Edit: Oh, you mean a build. No, there isn't. Maybe in the future. :)
I just want to try it myself . I dont want code , i can write that myself . I just think its cool and wanted to know if you would build a windows build so people could try it .
Seeing this kind of ComputeShaders usage makes me thinking, that in future games won't use CPU any more. Everything will be computed in GPU. Is this true?
I doubt it. The GPU is quite busy in modern games already and it doesn't have much processing time to spare. It's very good at calculating loads of data in parallel and can be much faster in those cases than the CPU (in some of my experiments around 100x faster). However, a game is more than pure data. In a single-player game, for example, you have a lot of processing needed for the player. That processing is usually not suitable for the GPU, because it's just lacking the amount of data. It needs a lot of processing, but it doesn't do the same thing over and over again many times per frame. That's why it rather needs really fast processing for a single data set, which is best suited for the CPU.
Hi Christian, since the GPU implementation uses a completely different algorithm, it depends on the input data. The better the resolution of the nav mesh, the better the result. However, the resolution is limited by memory. So, yes, you could say it's less accurate but still faster.
your work is very interesting and very inspirational.
Thank you!
inter yasin I don't think so. In GTA 5, the GPU is busy enough, I assume. They have just a very good LOD system, which is why they never need to process so many agents every frame. My video demonstrates an edge case, where every agent recalculates its path every frame (to be able to compare the performance in a stress test), which is generally not needed in a game.
Very interesting! Would be nice to hear from you a conclusion of the experiment. Which pathfinding solutions would you use in different circumstances.
Hey Roman Shirokov, in general I would say the use of such a GPU implementation is very limited in video games. It's very fast as it's basically just a lookup of precomputed results. The problem is the amount of memory needed to store those results. It's useful if you really need thousands of agents that need to request a path every frame.
A more realistic setting in video games probably only requires a few agents, which don't need to request a path that often. In those cases I would rather use A* as it doesn't use that much memory and is just fast enough.
I hope that answers your question :)
Hey! This is pretty interesting shader usage! I love the possibilities that GPUGPU opens up.
Could you tell me where did you learn to use compute buffers in Unity? I am pretty good at writing regular vertex/fragment shaders and working with RT's but I can't get myself to learn dx11 stuff. Thanks!
Hi +Michał Piątek, you should really have a look at compute shaders as vertex/fragment shaders are more or less an exploit of the graphics pipeline to get GPGPU. It can be a pain to map computational problems to the graphics context using RTs.This blog helped getting me started with compute shaders in Unity (Scrawkblog DirectCompute tutorial for Unity introduction _Edit: Unfortunately the blog was taken offline and the link was broken, so it was removed_).
Also have a look at Aras' sample project, which is a bit hidden in the forums (forum.unity3d.com/threads/compute-shaders.148874/#post-1021130) where he basically shows the DX11 API. This is especially useful when you want to output the results (like drawing procedurally, which I used extensively in my videos).
Compute shaders are badly documented but some bits of useful information actually reside on MSDN (here msdn.microsoft.com/en-us/library/windows/desktop/ff476331(v=vs.85).aspx and here msdn.microsoft.com/en-us/library/windows/desktop/ff476405(v=vs.85).aspx ).
Let me know if this helped!
@@MalteBennewitz Clicking on the first Link: Windows defender kicks in an says the page is virus infected.
@@SnakeEngine Thanks a lot for letting me know! The blog was taken offline a while ago and now it apparently redirects to some other sites. I removed the link.
Any write up on your implementation or something? Not sure i understand how you used unity navmesh on GPU with the algorithm..
I didn't really use Unity's navmesh on the GPU. I converted the navmesh to vertex and index buffers as triangles and used that data on the GPU.
All possible paths then got precalculated. In real-time, I only had to find the right start and end triangle, look up the shortest path, and straighten the path with a funnel algorithm.
See the video description for more details.
will you ever do tutorial how you made this?
Delaunay those triangles. ;w;
I don't know if you are going to read this, but scrawkblog.com is down do you have any resources to learn about compute shader? How does a shader like this that you implented looks in big steps?
How does a very simple random procedural mesh generator looks like that gets a mesh or a vector3 array as an input and returns the changes?
Is there a built project i can download and see for myself ?
Noaman Khalil No, sorry, it's not open source, I'm afraid. What especially are you interested in?
Edit: Oh, you mean a build. No, there isn't. Maybe in the future. :)
I just want to try it myself . I dont want code , i can write that myself . I just think its cool and wanted to know if you would build a windows build so people could try it .
Wow is any of you code available?
Hi, sorry for the late response! No, the code is not available, I'm afraid. Maybe at some point in the future :)
You should really share code, great job!
@@fisslewine1222 why dont you learn what you need to do this and share it instead? I'm sure it would be such a wonderful experience! hugs!!
@@jfa3dwizard257 just learn it :4head:
Seeing this kind of ComputeShaders usage makes me thinking, that in future games won't use CPU any more. Everything will be computed in GPU. Is this true?
I doubt it. The GPU is quite busy in modern games already and it doesn't have much processing time to spare.
It's very good at calculating loads of data in parallel and can be much faster in those cases than the CPU (in some of my experiments around 100x faster). However, a game is more than pure data. In a single-player game, for example, you have a lot of processing needed for the player. That processing is usually not suitable for the GPU, because it's just lacking the amount of data. It needs a lot of processing, but it doesn't do the same thing over and over again many times per frame. That's why it rather needs really fast processing for a single data set, which is best suited for the CPU.
GPU faster but lower accurate(?
Hi Christian, since the GPU implementation uses a completely different algorithm, it depends on the input data. The better the resolution of the nav mesh, the better the result. However, the resolution is limited by memory. So, yes, you could say it's less accurate but still faster.
It's still good enough for most cases I think
the a* just goes to show why yandere simulator runs so poorly