I'm trying to optimize the performance of my Dijkstra map generation shader.
Currently I'm using the traditional method I've learned from
http://www.roguebasin.com/index.php/Dijkstra_Maps_Visualized
Is it possible the use the jump flood algorithm to generate Dijkstra map? Since JFA is the most efficient algorithm to generate SDF in shader.
Any suggestion will be appreciated!
Related
I want an algorithm to be able to find an optimal path between two vertices on a graph (with positive int weights).The thing is my graph is relatively big (up to 100 vertices). I have considered the dijkstra algorithm but as I searched the net most implementions use the adjacency matrix which in my case will be 100x100.
If you could recommend me a certain source to read and learn from , or even better provide me with a c++ implementaion it will be great.
PS: The algorithm needs to output the required route and not just the shortest distance between two points.
Thank you for your time.
Have you looked into A*?
Here's a good article to start reading: http://www.redblobgames.com/pathfinding/a-star/introduction.html
I'm testing various TSP models/algorithms. Right now I'm using a full adjacency matrix, filled with random values from 1 to 100, which represents a complete directed graph.
I'm searching for a more rigorous approach that would allow me to try different kinds of random graphs, like Erdos-Renyi, small world networks and scale free networks.
I know I may have to switch to adjacency lists for the new graphs.
My approach would be generating a random graph and then ensuring there is the Hamiltonian path necessary for the problem to be a valid TSP instance. Is it possible, or is it cheaper to just try and solve the unsolvable instance (assuming all methods will terminate on such instance)?
BTW I was thinking of using the Boost Graph Library, but I'm not familiar with it, and maybe there's something more appropriate. Suggestions for alternatives are welcome, but should not be considered the main scope of this question.
I don't need a TSP solver, I need something to aid in the generation of acceptable problems.
Thanks.
You can try a monotone gray code, a.k.a a hilbert curve. It can help find a hamiltonian path:http://en.m.wikipedia.org/wiki/Gray_code.
I'm searching for a more rigorous approach that would allow me to try
different kinds of random graphs,
Check Mathematica. It has a built-in predicate to test whether a given graph has hamiltonian path or not. It also, has a predicate to generate random Hamiltonian Graphs.
In addition, If you have not try it yet, TSBLIB contains (hard and easy) instances that you may find them useful.
I'll be taking a look at some C++ code that utilizes OpenGL to render some information. I've been told that they are using distance matrices to accomplish part of the rendering and that it currently runs in N^2 time.
I don't have the code just yet, but do you all know of any common problems or coding mistakes that would cause this to run in N^2? Do you all know of any ways to reduce this, perhaps down to NlogN?
recently I'm trying to implement an algorithm to generate vine in real time. I kinda know how to do it on cpu, but I want to use GPU to accomplish this. I was thinking of geometry shader, but it looks like geometry shader executes in primitive scale, meaning it will perform the exact same functionality on every primitive, which is not what I expect.
Here is conceptually how my vine growing algorithm works. pick any point on an object mesh as the root point, the vine growing algorithm generates a series of points(representing the vine) according to previous points produced. Positions of points are influenced by such factors as gravity, adhesion and distance to triangle faces. Every point must be in the same side as the normal of triangle face.
How can I do this on GPU? Thanks a lot.
If you want to do something like this, that doesn't map well to the regular rendering pipeline, in glsl; your best bet is to use compute shaders (if you don't need to implement this in glsl, you may also want to take a look at OpenCL or CUDA as possible alternatives, though note that CUDA in vendor-locked to NVIDIA GPUs) in this case you can use it to generate the vine geometry using whatever method you had planned; then render the vines as normal in a second pass.
Note that this is only a good idea if your vine generation algorithm maps well to the massively parallel nature of a GPU. If your algorithm is inherently serial, then using the CPU to generate the geometry will likely yield better results.
Given a huge collection of points (float64) in 2d space...
Is there a way to determine the nearest neighbour using a feature of OpenGL or DirectX?
I've implemented a kd-tree, which is still not fast enough.
A kd-tree should work just fine. But here's some hints.
I implemented a kd-tree once for a million point data set once. Here's what I learned out of it:
Did you try profiling your code? You might find that there are easy optimizations to make such as common helper functions needing to be forced inline.
Did you actually test your code to validate that it was culling out tree branches for partitions that are easily identified as "too far away". If you aren't careful, you can easily have a bug that does needless distance computations on points too far away.
Easiest thing: Where comparing linear distance between points, you don't need to take the SQRT of (x2-x1)*(y2-y1).
Most of the time spent in my code was just building the tree from the original data set, including multiple full sorts on each iteration deciding which axis was the best to partition on. An easier algorithm would be to just alternate between partitioning on the x and y axis for each tree branch and to cache the sorting order for each axis. It may not build the most optimal search tree, but the overall savings can be enormous.