Stability, or Update Function?

[michaschwab]

Hi,
This is excellent work and looks beautiful and I am excited to use this in my projects, thank you!

In my use case, the clip changes, and transitions between a rectangle and an ellipse and back. The problem I'm experiencing is that in order to correctly fill the space in both cases (and in between), I need to update the layout, which, as far as I know, recomputes the layout from scratch and comes up with a completely new layout. This results in jumping between two completely separate layouts, and is even more hectic during the transitions.

Is there any chance for an update function that can try to find a correct layout that starts with the current layout, or maybe the same seed points?
Thank you!

[Kcnarf]

Hi,
you're right: currently, this plugin produces a static, one-shot, Voronoï treemap, and it doesn't take into account neither reproducibility, nor animation/self-update:

• reproducibility is not available because it internally uses Math.random() to place/replace sites ; I guess using a seed-able random function will do the trick.
• self-update is not available because the algorithm does not suit this requirement. The algorithm is recursive (top->down):
  • in order to compute the treemap of sibling data , the parent's polygon must be known ;
  • and at each stage, computing the treemap of siblings considers a non-changing/static polygon ;

Changing the algorithm to one that can handle live-update/simulation will be hard job.

For your information, I'm working on these two requirements (reproducibility, simulation) for the d3-voronoi-map plugin (the 1-level version of this plugin, see the simulation branch of d3-voronoi-map). But I don't yet figure out how to transpose this work to this plugin, because of the nested/recursive aspect of the treemap.

[michaschwab]

That's excellent to know, thanks!

I think if a stable voronoi-map would suffice for me. I'm aware that voronoi-map is used recursively for this plugin.

Do you think it would be a reasonable approach to try to set the same seed points instead of using a random seed function in the update function? If you think this approach could work I might build it in a fork (with pull request if you'd like).

For your work on the improved d3-voronoi-map, what's the approach? And do you have a concrete timeline? I might be able to help out if you're interested and if the abovementioned approach doesn't work.

[Kcnarf]

try to set the same seed points instead of using a random seed function

For reproducibility, that's what must be changed.

The simplest way do provide reproducibility is to replace Math.random() by a seed-able PRNG (https://gist.github.com/blixt/f17b47c62508be59987b).

My preference will be to use (or mimic) d3-voronoi-map's APIs initialPositions and initialWeights. It let the user defines its own initial placement/weight of seeds. This block uses the initialPositions() APIs. Seed points are positioned inside a quasi-circle 60-sides polygon.

The problem is more difficult with the treemap because of nested data: you can not know what is the parent polygon before computation. One way to be sure to position seed points inside the computed polygon will be to find a inner circle of the polygon, and position seed points inside this circle, in a repeatable way.

For your work on the improved d3-voronoi-map, what's the approach?

I use the same approach as d3-force (wihtout heating): an internal d3-timer runs. At each tick, the timer runs 1 iteration of the treemap algorithm

And do you have a concrete timeline?

Sorry, no concrete timeline.
The use-case example is not finished. That's why it is still not merged into master. Furthermore, this will upgrade d3-voronoi-map to version 2 (API break, no backward compatibility).

[Kcnarf]

The d3-voronoi-treemap plugin now provides repeatability/reproducibility through the new prng(...) API.

This API is now available on master branch, and on the new 1.0.0 release.

[Kcnarf]

For transitioning from one shape to another, you can take a look at flubber: 'Tools for smoother shape animations'.

There is even a demo that deals with transitioning from/to a circle shaped Voronoï treemap and a regular rectangular treemap.

[Kcnarf]

Closing as

• stability is available since v1.0.0 through prng(...) API
• the update need (from initial comment: In my use case, the clip changes, and transitions between a rectangle and an ellipse and back.):
  • smoothly transitioning between several clipping polygon has never been intended to be handled
  • even when considering a static clipping polygon, the way the plugin works (recursive computation of inner cells) is not able to smoothly update cells at different levels, and hence is not compatible with the need; it requires a new approach, with is currently out of scope