Jaged/spiky edges with edgeRouting = SPLINES
basveeling opened this issue · comments
When using the SPLINES edgeRouting option in a big graph with ports, some of the edges take spiky detours, and get a seemingly unnecessary number of bendPoints. This makes the edges appear jagged with spikes in the opposite direction:
If I remove the first two cubic instructions (i.e. the first 6 bendPoints) for these particular examples, the lines appear more smooth.
I've been using the plainjslinker nightly, and I follow the instructions from here to render the lines. Are these still up to date with the latest version?
Actually, you shouldn't use the library you linked anymore. Just use the klay.js file directly.
I'm not really sure what causes your spikes though. It may be a bug or a configuration issue. Would it be possible to share a minimal json input where spikes occur? The spline routing code in the library should be up-to-date.
@uruuru Thanks for the speedy reply, I'll try to get extract a small reproducible json string soon.
I started off with the klay.js file you linked, but there seem to be some options missing in there. If I replace the nightly version with the github one I get the following error:
"Unsupported layout option 'portAlignment' ("JUSTIFIED")."
Is the version on github outdated or are some options left out for a reason?
Ah, you're right. I wanted to wait for some tests before I published our last (java) release as js. I'll update it soon (however, beforehand we should check if we find a fix to your problem).
I've extracted an example in which this issue arises, you can find the KJSON here:
https://gist.github.com/basveeling/55dec501aaef9fc9ec33
Notice how the edge from shop to oven has a weird spike (the other edges have the same problem, but less noticably).
The result from the layouter for this edge can be found here:
https://gist.github.com/basveeling/efba08661030d63f5820
Which is then rendered with SVG like this:
<path class="link" d="M108 176 C 108 181, 108 183, 108 196 C 108 209, 108 232, 133 244 C 157 256, 206 256, 108 256 L 211 256"></path>(See: https://developer.mozilla.org/en-US/docs/Web/SVG/Tutorial/Paths#Bezier_Curves )
Hope this helps with reproducing the error. For this case I can fix the problem by removing the last bendPoint before running the algorithm, but there are other cases where there are more unnecesary/wrong bendpoints.
Off-topic: is there a way to call the edge routing phase separately? I'm experimenting with a drag and drop option, and I'd like for the edges to re-route in real time.
Can you please try running it with intCoordinates: false. I could imagine that rounding to integers produces the spike (since we internally calculate floats for all coordinates and only round them in the end). I believe svg paths should be able to handle floats.
Regarding your edge routing question: We get that request quite frequently but it's not possible at this point.
I've had the same problem with intcoordinates:false, just set it here to true
make everything a bit more readable. The line looks the same this without it set:
<path class="link" d="M103.79687488079071 175 C 103.79687488079071 180, 103.79687488079071 182.5, 103.79687488079071 195.33333333333331 C 103.7968748807907 208.16666666666669, 103.79687488079072 231.33333333333331, 126.99609357118608 242.91666666666666 C 150.19531226158142 254.5, 196.59374964237213 254.5, 103.79687488079071 254.5 L 201.59374964237213 254.5"></path>On Wed, 18 Nov 2015 00:49 Ulf notifications@github.com wrote:
Can you please try running it with intCoordinates: false. I could imagine
that rounding to integers produces the spike (since we internally calculate
floats for all coordinates and only round them in the end). I believe svg
paths should be able to handle floats.Regarding your edge routing question: We get that request quite frequently
but it's not possible at this point.—
Reply to this email directly or view it on GitHub
#5 (comment).
Ok ok, looking at the bendpoints, the last one definitely looks wrong. We'll check it.
Thanks, I really appreciate the help :).
Figured you might be interested in another thing I've noticed since you're checking the edge routing anyway:
If I take a graph that has been layouted normally, and then change the nodePlacement to INTERACTIVE and rerun the layouter, the edges take unnecessary detours. This doesn't happen if I leave nodePlacement as is.
Before:
After:
KJSON here:
https://gist.github.com/basveeling/2faeb7167b94ab2036da
Regarding the spikes: We believe it was a bug that has already been fixed in the java code. Could you try the latest nightly build (plainjslinker) and let me know if that fixes your issue?
Regarding the interactive node placement: This is kind of expected behavior. That strategy has it's limitations and at this point is only implemented for certain (quite specific) graphs.
Hi uruuru. Thanks! This does indeed fix the issues I had with the cookie example above, which is a great improvement already. Some spikes still appear in more complicated graphs, like this:
<path class="link" d="M532 466 C 532 471, 532 468, 532 470 C 532 473, 532 480, 557 484 C 583 488, 633 488, 609 488 C 585 488, 487 488, 438 493 C 389 499, 389 510, 389 520 C 389 530, 389 538, 389 546 C 389 554, 389 562, 389 572 C 389 582, 389 593, 381 599 C 373 605, 358 605, 351 608 C 343 612, 343 619, 343 622 C 343 624, 343 622, 343 627" style="
stroke: red;
"></path>Re: interactive node placement. I understand that this is a harder problem, but the nodes don't move at all in this example, only the edges are routed differently between them. The change only happens the first time I re-layout with interactive nodePlacement, if I run it again, e.g. with a changed edge, the edges stay roughly the same. Could you explain how this option interferes with the edge routing?
Could you explain how this option interferes with the edge routing?
As you know, your nodes are assigned to so-called layers: all nodes placed along a horizontal line are in the same layer. Edges can either connect nodes in adjacent layers, or span a number of layers. To handle the latter case, our algorithm internally inserts dummy nodes to reduce it to the case where all nodes only connect nodes in adjacent layers.
Interactive node placement computes node positions based on their previous positions. The problem is that the dummy nodes used to split long edges don't really exist and thus don't have previous positions, so we have to do some computations to find out where they should be placed. Those computations are based on the bend points, and assume that edges are orthogonal polylines, not splines. The spline bend points probably cause the interactive node placer to panic...
I added another fix to the latest nightly. If your problem persists, please send me the example. Even if it's a larger one.
By the way, in your example are some sections where several splines "criss-cross". We already have an open ticket for that problem.
@le-cds: Thanks for clear explanation! Does this mean that I should implement my own edge routing if I want to add any interactive node movement after layouting?
@uruuru Thanks, I've tried it, but the problem seems to persist. Please find the ksjon here from the last example under the new nightly here:
https://gist.github.com/basveeling/2d04f25e7a06657178ef
And great to hear you're working on the edge criss-crossing as well :)!
Does this mean that I should implement my own edge routing if I want to add any interactive node movement after layouting?
Yep, that's right. Sorry. ;)
@basveeling thanks for the example. I'm able to reproduce the problem on the Java side as well. We'll look into it.
Thanks, let me know if you need more KJSON examples :).
Should finally be fixed in the Java code base.