Skip to content
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

Open
holtsetio opened this issue Sep 12, 2018 · 16 comments
Open

Layout specific multipliers break layout #49

holtsetio opened this issue Sep 12, 2018 · 16 comments

Comments

@holtsetio
Copy link
Collaborator

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

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.

@holtsetio
Copy link
Collaborator Author

A default weight factor of 10.0 instead of 1.0 seems to recreate the old feel. So I'd suggest that one.

@ggonnella
Copy link
Owner

ggonnella commented Sep 12, 2018 via email

@ggonnella
Copy link
Owner

5fae918 fixes this

@holtsetio
Copy link
Collaborator Author

What about the default value?

@ggonnella
Copy link
Owner

which value would you like to set to 10?

@ggonnella
Copy link
Owner

VIZ_SM_WEIGHTFACTOR? or VIZ_WEIGHTFACTOR?

@ggonnella
Copy link
Owner

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.

@holtsetio
Copy link
Collaborator Author

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

@holtsetio
Copy link
Collaborator Author

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?

@ggonnella
Copy link
Owner

The problem is with FMMM?

@ggonnella
Copy link
Owner

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.

@ggonnella
Copy link
Owner

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 layout specific factors are set to values which should recreate the old values.

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.

@holtsetio
Copy link
Collaborator Author

Newest version works mostly fine, but if the minweight is too low, some edges are not displayed, no idea why:

edgesmissing

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.

@ggonnella
Copy link
Owner

ggonnella commented Sep 13, 2018 via email

@holtsetio
Copy link
Collaborator Author

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.

@ggonnella
Copy link
Owner

ggonnella commented Sep 13, 2018 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants