-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Layout specific multipliers break layout #49
Comments
A default weight factor of 10.0 instead of 1.0 seems to recreate the old feel. So I'd suggest that one. |
Ups. Will be fixed.
Am 12. September 2018 08:30:54 MESZ schrieb niehus <[email protected]>:
…The layout specific multipliers seem to be incorrectly implemented, no?
Since the update, when using SM layout, all segments are very short, no
matter how many subnodes they have. But short segments with too many
subnodes do not look good:
![bildschirmfoto_2018-09-12_08-27-54](https://user-images.githubusercontent.com/22981095/45406207-0618ad00-b666-11e8-8e9a-3ff8945fc7e9.png)
Also this line in viznode.cpp seems wrong;
`vg->GA.doubleWeight(e) = weight;
getOption(VIZ_SM_WEIGHTFACTOR).toDouble();`
However, when replacing the ';' with a '*', all segments become very
elongated.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#49
--
Dr. Giorgio Gonnella
|
5fae918 fixes this |
What about the default value? |
which value would you like to set to 10? |
VIZ_SM_WEIGHTFACTOR? or VIZ_WEIGHTFACTOR? |
I would like to keep VIZ_WEIGHTFACTOR to 1 and set the other so that the segments have a nice length and the same length in the two layouts. |
VIZ_WEIGHTFACTOR to 10, VIZ_SM_WEIGHTFACTOR to 1.5 or VIZ_WEIGHTFACTOR to 15, VIZ_SM_WEIGHTFACTOR to 1.0 recreates the old values for SM/FMMM I think |
Or add a hardcoded multiplier by 10 to the weight calculation so the standard weight-factor can be a convenient 1.0 and set viz_sm_weightfactor between 1.0 and 1.5? |
The problem is with FMMM? |
now is VIZ_WEIGHTFACTOR 1 and VIZ_SM_WEIGHTFACTOR 15 and they are multiplied, so it should not change nothing setting them to 15 and 1. |
The current commit should fix everything. The weightfactor is set to 1, so that the user can think of it as a length magnification factor. The computations are fixed, in that previously the number of nodes (node ends) and not the number of subsegments was used, so that the ratio of lengths of the segments was incorrect. The minimum is now expressed in terms of portion of the subsegment length. The fragment length is now computed from the graphical length of the segment length, so it is correct whatever layout or weight factor is used. |
Newest version works mostly fine, but if the minweight is too low, some edges are not displayed, no idea why: I'd suggest setting the default minweight to 0.2 and the sm-weight-factor to 10, as that most cloely resembles the original settings. Also I'd suggest not making the sm-weight-factor and fmmm-weight-factor user-definable, as there's already the weight-factor setting for the user. Will implement in the next commit. |
Ok. But we should in the future find out why the edges disappear.
Am 12. September 2018 18:26:15 MESZ schrieb niehus <[email protected]>:
…Newest version works mostly fine, but if the minweight is too low, some
edges are not displayed, no idea why:
![edgesmissing](https://user-images.githubusercontent.com/22981095/45438991-f5455700-b6b8-11e8-95b6-5b58b8cfa314.png)
I'd suggest setting the default minweight to 0.2 and the
sm-weight-factor to 10, as that most cloely resembles the original
settings. Also I'd suggest not making the sm-weight-factor and
fmmm-weight-factor user-definable, as there's already the weight-factor
setting for the user.
Will implement in the next commit.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#49 (comment)
--
Dr. Giorgio Gonnella
|
The issue lies with the fmmm layout module which places some nodes on top of each other if their target distance is too low. I fixed the issue in 20ba8d8 by increasing the ogdf node size of segments, because apparently the node size also affects the fmmm layout. Now it seems to work with all minweight-settings of 0.01 and above. |
Great!
Am 13. September 2018 10:27:28 MESZ schrieb niehus <[email protected]>:
…The issue lies with the fmmm layout module which places some nodes on
top of each other if their target distance is too low. I fixed the
issue in 20ba8d8 by increasing the
ogdf node size of segments, because apparently the node size also
affects the fmmm layout. Now it seems to work with all
minweight-settings of 0.01 and above.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#49 (comment)
--
Dr. Giorgio Gonnella
|
The layout specific multipliers seem to be incorrectly implemented, no?
Since the update, when using SM layout, all segments are very short, no matter how many subnodes they have. But short segments with too many subnodes do not look good:
Also this line in viznode.cpp seems wrong;
vg->GA.doubleWeight(e) = weight; getOption(VIZ_SM_WEIGHTFACTOR).toDouble();
However, when replacing the ';' with a '*', all segments become very elongated.
The text was updated successfully, but these errors were encountered: