Generalized Pythagoras Tree #63

JulesCornelissen · 2018-05-05T10:44:26Z

Full implementation of the Generalized Pythagoras Tree, implemented within the visualization framework. This mean it can be called simply using draw(Node, OpenGL). The rendering is done recursively and most of the code was implementing and figuring out the correct formulas. Hopefully the comments in the code help explain some of the steps.

The pull request for some reason shows that the documentaton.md has changes, but I did not change anything within this file. I suspect that it is an artifact of solving the merge conflicts, however when comparing the file locally to the one currently in the develop branch there are no differences to be found. If possible somebody else should double check this.

If you have any questions please let me know.

To-do:

[Generalized Pythagoras Tree] Implement settings #61 Implement settings
[Generalized Pythagoras Tree] Code optimization #62 Optimize code, currently there are a lot of Math.sin and Math.cos calls. There are also some other simple optimizations which I do not believe cost a lot of computational time. If possible I would prefer to tackle some of these at the same time.

Known bugs:

[Generalized Pythagoras Tree] Height scaling does not work properly #60 Changing the weightHeight value currently results in a broken tree. This is probably not too difficult to fix, however I'd prefer to fix it when implementing the settings since it probably will have some overlap with that regardless.

Screenshots:
(A,B,C):

((A,D),(C,B)):

newick_example_phyloviz.nwk:

…ta structure Rough skeleton of the generalized pythagoras tree. The core of the algorithm and its form are there but some functionality should be split in to seperate functions and some functions lack their required logic still. There is also a rough data structure for storing a tree. It's currently inefficient and not fully featured. However, it was required to have one. Can be adapted or exchanged for one that is more suited to the rest of the project.

…ering

…rithm NOT YET TESTED

…ythagoras-tree

…tive to old position

…rge to main branch first

…e the framework

RoanH · 2018-05-05T10:57:52Z

Looks really nice! I'll review it when I have some more time.

Also you might want to implement some better coloring for the squares. If so then I recommend a HSB Gradient since they are really easy to compute and look really good.

The general formula for these gradients would be:

return Color.HSBtoRGB(subTreeSize / 256.0F, 1.0F, subTreeSize / (subTreeSize + 8.0F));

That's in Java of course, but it should be quite easy to translate. Also I took this snippet from my fractal generator so you might have to lower the 256.

In any case, this looks really good.

Edit: Using the height of a node from the root would give better results.

RoanH · 2018-05-05T11:24:40Z

Also a quick question, why does the diff of this PR show the entire OpenGL documentation being removed and added again with seemingly no changes?

bartwesselink

Looks very nice! As @RoanH mentioned, does this still require a gradient?

bartwesselink · 2018-05-05T11:22:06Z

src/visualizations/generalized-pythagoras-tree.ts


+        // Define the base rectangle of the visualized tree, these values can later be determined in settings
+        // Rectangle is an array of 5 numbers, in order: center x, center y, width (X), height (Y), angle
+        let rectangle = [0, -250, 50, 50, 0];


For future PRs, it is good practise to store these values in variables, preferable static, readonly ones, such that they can easily be edited. Considering the fact that settings still have to be implemented, I believe this is not a must now.

Yes I agree with you, but this was indeed left this way because it is going to be changed very soon for the settings anyway. However I will change it now since I am changing some other variables anyway :)

bartwesselink · 2018-05-05T11:22:56Z

src/visualizations/generalized-pythagoras-tree.ts

+
+    weightHeight = 1; // !! Currently broken !! Scaling factor for the height of every rectangle that is not the root


Please place these values (with access modifier public/protected/private) at the top, imo it looks nicer and is cleaner.

Forgot about that! Normally I only quickly place values like these for testing purposes, but it slipped my mind this time.

bartwesselink · 2018-05-05T11:24:26Z

src/visualizations/generalized-pythagoras-tree.ts

+    private generate(tree: Node, rectangle: number[], gl: OpenGL): void {
+        // Draw the previously calculated rectangle
+        gl.fillRotatedQuad(rectangle[0], rectangle[1], rectangle[2], rectangle[3], rectangle[4] * 57.295779513082320876798154814105, this.color);


Please modify this number to 180/Math.pi . I think that's cleaner. If this is because of performance, then please create a value radToDegreeConstant or something like that.

Will do. I try to have the least amount of "magic numbers" as possible, but forgot to change this one in to a constant.

bartwesselink · 2018-05-05T11:25:09Z

src/visualizations/generalized-pythagoras-tree.ts

+                let rectangleChild = [center[0], center[1], width, height, rotation];
+                // Finally we recurse using all the previously calculated values
+                this.generate(element, rectangleChild, gl);


Is it possible to check whether the current value of the size is +- 1, and then just stop?

Sorry, I don't understand what you mean by this. What size and where? And stop what? The loop or the recursion?

On line 34 I already check to see if the node has any children. Is that what you mean?

Ah, I admit it is a bit vague. I mean that a certain depth there is no point in rendering a square because the size of it will be between 0 - 1 pixels. This is not visible to the human eye, so maybe it is good to check whether it makes sense to continue the recursion.

Great remark! This slipped my mind somehow since thinking about it a couple days ago. Something like this should probably be implemented, but I'm not sure how that would interact with regards to zooming. Similarly for the future it might also be a good idea to not render outside the viewport, but then there is perhaps a similar problem with panning.

Also we currently view the canvas as having a size of 1600x900, but as @RoanH mentioned in actuality it is not drawn on a pixel grid.

I feel like the complexity of this issue is above the current PR and would require more thinking and discussion about the implementation, inner workings of OpenGL and future requirements.

So I could implement a simple check (width < 1, height < 1 for example) but this might end up causing other issues which I can not for see right now.

If you ask me performance is actually preatty good. I could visualise the NCBI dataset in it's entirety in well under 10 seconds on the TU/e laptop. It's also worth noting that OpenGL already ignores vertices that are not visible and that OpenGL shaders run per pixel (and therefore don't run at all if the size is under a pixel or they only run for a single pixel).

One thing that we can do though is tell the OpenGL layer to ignore drawing shapes with no width/height all together. We need to have them computed for zooming and panning purposes though. I also have a few OpenGL optimizations in mind that when successful will reduce memory usage by over 16 times.

bartwesselink · 2018-05-05T11:26:36Z

@RoanH possibly line endings?

JulesCornelissen · 2018-05-05T11:34:42Z

I have no clue why the OpenGL documentation shows as being added and removed. As mentioned I even compared it to the one in develop and could not find any differences. Git also does not detect any changes when exchanging the file from develop in to this branch.

Edit:
The plan was indeed to implement a gradient, but I have not looked in to that yet. I'd prefer to tackle that separately. However if preferred I will implement it in this branch. For now I've created #65

RoanH · 2018-05-05T21:08:12Z

I'm assuming that something is wrong for me since Eclipse shows no errors, but loading the web page gives this error message:

Going to try again later, but for now it means that I can't review this :/

restarts don't solve it

JulesCornelissen · 2018-05-05T21:12:13Z

The error looks like there is no data uploaded yet, and I get a similar error if I try to create a render without uploading the data first. Is the tree view on the right showing the data correctly?

RoanH · 2018-05-05T21:36:01Z

Yeah that is indeed the case. The things was that I was expecting the default view to update when I uploaded a data set, but that's not how it works. I had to create a new tab. Everything seems to work now though so I'll do a full review in a bit.

RoanH

Looks good and performance is also quite good already.
The NCBI dataset also works just fine and response times are acceptable, 3.8GB of total memory usage is also acceptable for now in my opinion (tested on a TU/e laptop).

I'd say that this can be merged, especially so since enhancement issues have already been created and can be addressed at a later date (so we can focus on more important things first).

RoanH · 2018-05-05T21:43:03Z

src/visualizations/generalized-pythagoras-tree.ts

+                let rectangleChild = [center[0], center[1], width, height, rotation];
+                // Finally we recurse using all the previously calculated values
+                this.generate(element, rectangleChild, gl);


If you ask me performance is actually preatty good. I could visualise the NCBI dataset in it's entirety in well under 10 seconds on the TU/e laptop. It's also worth noting that OpenGL already ignores vertices that are not visible and that OpenGL shaders run per pixel (and therefore don't run at all if the size is under a pixel or they only run for a single pixel).

RoanH · 2018-05-05T21:46:00Z

src/visualizations/generalized-pythagoras-tree.ts

+                let rectangleChild = [center[0], center[1], width, height, rotation];
+                // Finally we recurse using all the previously calculated values
+                this.generate(element, rectangleChild, gl);


One thing that we can do though is tell the OpenGL layer to ignore drawing shapes with no width/height all together. We need to have them computed for zooming and panning purposes though. I also have a few OpenGL optimizations in mind that when successful will reduce memory usage by over 16 times.

NicoKNL

Looks good, is documented, and performance is very reasonable. Further changes/enhancements to this could be handled in future issues, especially due to the modular nature of visualizations.

I discussed and the items mentioned in the review are either handled, or part of optimization. The latter shall be handled in a possible future issue if it is still relevant then. Additionaly, the visualizations are modular in nature, and hence this merge only adds functionality, without impacting other facets of the tool. Hence I dismiss this review for now so the PR can be merged.

teards added 11 commits May 1, 2018 16:19

Changed angle calculation, preperation for use with rotated quad rend…

a1af670

…ering

Finished first implementation of the generalized pythagoras tree algo…

fcb2e70

…rithm NOT YET TESTED

merge in to local test

a75fd86

Starting to get there, small alignment issues left

f4249d6

Merge branch 'localtestbranchshouldnotbecommitted' into generalized-p…

e474618

…ythagoras-tree

Tree now correctly visualizes the first tier, need to fix offset rela…

ab358c3

…tive to old position

Generalized pythagoras tree visualization done, cleanup needed but me…

fb35d9f

…rge to main branch first

Merge branch 'develop' into generalized-pythagoras-tree

f001526

Code cleanup and some additional comments/documentation

4225b49

Remove old generalized pythagoras tree component, artifact from befor…

3b2ca41

…e the framework

JulesCornelissen changed the title ~~Generalized pythagoras tree~~ Generalized Pythagoras Tree May 5, 2018

RoanH assigned JulesCornelissen May 5, 2018

RoanH self-requested a review May 5, 2018 10:47

bartwesselink self-requested a review May 5, 2018 11:20

bartwesselink previously requested changes May 5, 2018

View reviewed changes

JulesCornelissen mentioned this pull request May 5, 2018

[Generalized Pythagoras Tree] Implement gradient #65

Closed

Implemented requested changes

dda09fa

RoanH approved these changes May 5, 2018

View reviewed changes

NicoKNL approved these changes May 5, 2018

View reviewed changes

NicoKNL merged commit 750b548 into develop May 5, 2018

JulesCornelissen mentioned this pull request May 5, 2018

[Visualization] Generalized Pythagoras Tree - Implementation #44

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Generalized Pythagoras Tree #63

Generalized Pythagoras Tree #63

JulesCornelissen commented May 5, 2018

RoanH commented May 5, 2018 •

edited

Loading

RoanH commented May 5, 2018 •

edited

Loading

bartwesselink left a comment

bartwesselink May 5, 2018 •

edited

Loading

JulesCornelissen May 5, 2018

bartwesselink May 5, 2018

JulesCornelissen May 5, 2018

bartwesselink May 5, 2018

JulesCornelissen May 5, 2018

bartwesselink May 5, 2018

JulesCornelissen May 5, 2018

bartwesselink May 5, 2018

JulesCornelissen May 5, 2018

RoanH May 5, 2018

RoanH May 5, 2018

bartwesselink commented May 5, 2018

JulesCornelissen commented May 5, 2018 •

edited

Loading

RoanH commented May 5, 2018

JulesCornelissen commented May 5, 2018

RoanH commented May 5, 2018

RoanH left a comment

RoanH May 5, 2018

RoanH May 5, 2018

NicoKNL left a comment


		weightHeight = 1; // !! Currently broken !! Scaling factor for the height of every rectangle that is not the root

Generalized Pythagoras Tree #63

Generalized Pythagoras Tree #63

Conversation

JulesCornelissen commented May 5, 2018

RoanH commented May 5, 2018 • edited Loading

RoanH commented May 5, 2018 • edited Loading

bartwesselink left a comment

Choose a reason for hiding this comment

bartwesselink May 5, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bartwesselink commented May 5, 2018

JulesCornelissen commented May 5, 2018 • edited Loading

RoanH commented May 5, 2018

JulesCornelissen commented May 5, 2018

RoanH commented May 5, 2018

RoanH left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

NicoKNL left a comment

Choose a reason for hiding this comment

RoanH commented May 5, 2018 •

edited

Loading

RoanH commented May 5, 2018 •

edited

Loading

bartwesselink May 5, 2018 •

edited

Loading

JulesCornelissen commented May 5, 2018 •

edited

Loading