I'm using Graphviz and cgraph to layout some graphs and, for some cases, I already know the positions I want my nodes to be at (as they form a subgraph of a bigger graph).
Using the dot command line tool, you can add the -Knop layout option, but if try gvLayout(context, graph, "nop") in my code, or call gvParseArgs for dot -Knop arguments, the resulting graph has no edge routing, even though I have agset(graph, (char*)"splines", (char*)"true") in my code.
Is there any way I can achieve such edge routing for fixed node positions in cgraph?
Related
I am trying to add reflective floors to my scene. The built in floor node is perfect in terms of looks. It does exactly what I want. The issue arises because I don't want it to be infinite. I want to give my scene multiple floors with gaps in-between them. I think the word platform better describes them.
Anyways I am looking for one of two solutions:
A) a way to make the standard floor node non infinite
Or
B) a way to make the standard box node have the material/reflective properties of a the standard floor node
Any help is appreciated, Thanks!!
Starting iOS 10 and macOS 10.12 the SCNFloor class has width and length properties that allow for non-infinite floors.
I want to divide my map in clusters and implement HPA*. Where do I start, each time I try this I run into problems. I need to implement this on a random and dynamically changing map.
I am unsure how to write an algorithm that places these "nodes", to connect the parts, in between sections/clusters of the map and update them. I guess every time open tiles lie in between closed tiles on the edge of a cluster/section there should be a node since inside the cluster it could be that multiple openings into the cluster do not connect to each other within this section.
Normally I would just have a big Tile[,] map. I guess I could just leave this be and create a cluster/section class that holds all the paths and nodes. And have a node class/struct that holds the 2 tiles that are connected between sections. I have read several articles about HPA* but I just can not wrap my head around implementing this correctly on a random and dynamical map. I hope to get some good pointers here although the question is not very clear.
-edit-
What i am trying to do is making cluster class that holds 10x10 tiles/nodes with on each side an entry point (several if there is a obstruction on the edge). The entries link to the next cluster.
I'd like to input my own graphs for use with the Stanford GraphBase CWEB library. I found this example of a graph on the SGB webpage, and understand it for the most part. What I don't understand is why there are four zero-rows ("", 0\n) in the vertex list and so many zero-rows (0,0,0) in the edge-list. Graphs seem to compile fine without them, and I don't see their purpose.
The extra zero-lines are not strictly necessary. They're included so that when the graph is loaded, memory is preallocated for vertexes and arcs that might be added to the graph later on (for example, in some algorithm being run on the graph). This is as an alternative to dynamically allocating memory for the new vertexes and edges. It just so happens that the graph in that link is supposed to be used in conjunction with an algorithm that needs space for extra nodes and arcs on the graph.
The prof gave us an assigment to finish in the next couple of months, we have to write a web app that is basically a mapping system for a floor of a building. Like a very very simple version of google maps, people need to be able to look up a room and be able to get directions from one part of the floor to another. I have never done any major web programming and don't even know how to start. Is there a google maps or mapquest API that I can use or do I have to start it from scratch? I'm not asking anyone to solve it for me, just nudge me in the right direction so as where to start.
I would suggest thinking of the task as three parts:
Displaying the image of the map
(probably, for best efficiency, as
lazily-loaded tiles like Google Maps
does)
Representing the rooms and the
connections between them, probably
as a graph. Using a graph
allows you to easily use a
well-documented algorithm like
A* or Dijkstra's to find
the shortest route from point A to
point B.
Converting from a click on the image
to a node on the graph, and from a
node on the graph to a point in the
image. Probably each node should
just store a pair of (x,y)
coordinates.
With an arrangement like this, all your code has to do is:
The first time the user clicks
{
Identify the nearest node to their click as node A;
}
The second time the user clicks
{
Identify the nearest node to their click as node B;
Use Dijkstras Algorithm or A* to find the shortest route from node A to node B;
For each edge in the resulting route
{
Add a line to the image of the map;
}
Mark node A with a green dot and node B with a red dot (or something);
}
I've got a manually created NavGraph in a 3D environment. I understand (and have implemented previously) an A* routine to find my way through the graph once you've 'got on the graph'.
What I'm interested in, is the most optimal way to get onto and 'off' the Graph.
Ex:
So the routine go's something like this:
Shoot a ray from the source to the destination, if theres nothing in the way, go ahead and just walk it.
if theres something in the way, we need to use the graph, so to get onto the graph, we need to find the closest visible node on the graph. (to do this, I previously sorted the graph based on the distance from the source, then fired rays from closet to furthest till i found one that didn't have an obstacle. )
Then run the standard A*...
Then 'exit' the graph, through the same method as we got on the graph (used to calculate the endpoint for the above A*) so I take and fire rays from the endpoint to the closest navgraph node.
so by the time this is all said and done, unless my navgraph is very dense, I've spent more time getting on/off the graph than I have calculating the path...
There has to be a better/faster way? (is there some kind of spacial subdivision trick?)
You could build a Quadtree of all the nodes, to quickly find the closest node from a given position.
It is very common to have a spatial subdivision of the world. Something like a quadtree or octree is common in 3D worlds, although you could overlay a grid too, or track arbitrary regions, etc. Basically it's a simple data-structures problem of giving yourself some sort of access to N navgraph nodes without needing an O(N) search to find where you are, and your choices tend to come down to some sort of tree or some sort of hash table.