I can't figure out how to control edge placement with dot. I have created a small example to show my question. This may or may not be a MCVE; in the process of making it Minimal and Verifiable, I may have dropped the Complete. Anyway:
digraph stuff {
rankdir=LR;
a->b->c->b->a
}
$ dot -V
dot - graphviz version 2.38.0 (20140413.2041)
dot barfu.dot -Tpng > barfu.png
gives me this:
But I'd like to have the left-to-right arrows consistently on top, to reflect the normal state transitions. (Actually, it would be preferable to have them be straight lines in the middle, and have the right-to-left ones always curve below.)
I tried changing the line weight, the length, adding groups, setting connector directions, etc. Nothing seems to help, at least in the bigger graph this comes from.
This doesn't work in my larger diagram, so other answers are still most welcome, but it appears that, since graphviz starts with a default top-down graph, with the most important (downward pointing edges) on the left, they do a simple rotation when you make the graph go left to right, which rotates the top of the graph to the left, and thus the most important edges from the left to the bottom. So, of course, this really simple test case can be fixed by making the graph go right-to-left instead of left-to-right.
digraph stuff {
rankdir=RL;
c->b->a->b->c;
}
Related
I would like to increase the border width of my nodes, but I find that the arrow heads in digraph edges do not respect the added width. Instead, they sink into the border. Here's my simple graph.
strict digraph {
a [penwidth="10.0"];
b [penwidth="10.0"];
a -> b;
}
How could I either increase the node width safely, or distance the edges further back? Reading through the attribute list, I didn't find a way. The closest was peripheries, but it makes multiple narrow peripheries instead of a thick one, but the edges do stick to the outermost periphery.
This is a known bug: https://forum.graphviz.org/t/allign-nodes-stroke-with-end-of-the-arrows-path-width/462
The only work-around I know is to "move" node b or shorten the edge - described in the bug report.
I'm developing a game similar to Pacman: consider this maze:
Each white square is a node from the maze where an object located at P, say X, is moving towards node A in the right-to-left direction. X cannot switch to its opposite direction unless it encounters a dead-end such as A. Thus the shortest path joining P and B goes through A because X cannot reverse its direction towards the rightmost-bottom node (call it C). A common A* algorithm would output:
to get to B from P first go rightward, then go upward;
which is wrong. So I thought: well, I can set the C's visited attribute to true before running A* and let the algorithm find the path. Obviously this method doesn't work for the linked maze, unless I allow it to rediscover some nodes (the question is: which nodes? How to discriminate from useless nodes?). The first thinking that crossed my mind was: use the previous method always keeping track of the last-visited cell; if the resulting path isn't empty, you are done. Otherwise, when you get to the last-visited dead-end, say Y, (this step is followed by the failing of A*) go to Y, then use standard A* to get to the goal (I'm assuming the maze is connected). My questions are: is this guaranteed to work always? Is there a more efficient algorithm, such as an A*-derived algorithm modified to this purpose? How would you tackle this problem? I would greatly appreciate an answer explaining both optimal and non-optimal search techniques (actually I don't need the shortest path, a slightly long path is good, but I'm curious if such an optimal algorithm running as efficiently as Dijkstra's algorithm exists; if it does, what is its running time compared to a non-optimal algorithm?)
EDIT For Valdo: I added 3 cells in order to generalize a bit: please tell me if I got the idea:
Good question. I can suggest the following approach.
Use Dijkstra (or A*) algorithm on a directed graph. Each cell in your maze should be represented by multiple (up to 4) graph nodes, each node denoting the visited cell in a specific state.
That is, in your example you may be in the cell denoted by P in one of 2 states: while going left, and while going right. Each of them is represented by a separate graph node (though spatially it's the same cell). There's also no direct link between those 2 nodes, since you can't switch your direction in this specific cell.
According to your rules you may only switch direction when you encounter an obstacle, this is where you put links between the nodes denoting the same cell in different states.
You may also think of your graph as your maze copied into 4 layers, each layer representing the state of your pacman. In the layer that represents movement to the right you put only links to the right, also w.r.t. to the geometry of your maze. In the cells with obstacles where moving right is not possible you put links to the same cells at different layers.
Update:
Regarding the scenario that you described in your sketch. It's actually correct, you've got the idea right, but it looks complicated because you decided to put links between different cells AND states.
I suggest the following diagram:
The idea is to split your inter-cell AND inter-state links. There are now 2 kinds of edges: inter-cell, marked by blue, and inter-state, marked by red.
Blue edges always connect nodes of the same state (arrow direction) between adjacent cells, whereas red edges connect different states within the same cell.
According to your rules the state change is possible where the obstacle is encountered, hence every state node is the source of either blue edges if no obstacle, or red if it encounters an obstacle (i.e. can't emit a blue edge). Hence I also painted the state nodes in blue and red.
If according to your rules state transition happens instantly, without delay/penalty, then red edges have weight 0. Otherwise you may assign a non-zero weight for them, the weight ratio between red/blue edges should correspond to the time period ratio of turn/travel.
I used word to make this graph, how to make it in dot language? The line style is perpendicular. Thanks very much!
You can use the 'pos' attribute to place your nodes on an imaginary grid:
graph X
{
a [pos="1,1"]
b [pos="2,2"]
c [pos="2,3"]
d [pos="2,4"]
}
and then use the appropriate flag to the layout program to override neato's desire to place your nodes (you may also need to fiddle with the size of your nodes). You probably end up with edges which are not straight. In that case, define invisible nodes for the junction points on your imaginary grid and draw edges from your top node to the invisible ones and from the invisible ones to RIL_Init and so on. If your graphs are big, this will get pretty tedious..still straightforward...and you still get all the output options of graphviz. The need for pos="1,1!" usually comes up too, the bang meaning 'put it exactly there'.
I've made a tree in the dot language, similar to the one here.
Is there any way I could get the tree to expand to the right, instead of downwards (so the root node is on the left and children go along to the right).
it's very easy, as long as you stick to basic layout: place rankdir="LR" near top definition. Something like
digraph unix {
size="6,6";
rankdir="LR";
...
}
I would like to use graphviz for a project and am unable to get the behaviour I want. I have a graph that I can draw with graphviz just fine, but I also have a version of the same graph that has some extra edges. I would like the second graph to be drawn with the nodes in the same positions as the first one and the edges in the same positions, but the new edges to be drawn without avoiding any overlap with nodes.
To get a better idea of what I want, imagine a Powerpoint slide with a graph and then on the next slide the same graph with these extra edges that appear on top of the first graph, wihtout modifying the look of the old parts of the graph. That is the effect I want.
I think the effect could be achieved by having some edges ignore any overlapping constraints. I could not figure out how to control the overlap between edges and nodes for particular edges (or even for all edges).
Any ideas?
You can get dot to output another .dot file, with positions assigned to all elements, via dot -Tdot (or maybe dot -Txdot). Add your additional edges to that file, and run it through dot again to produce your second graph.