KirkMcDonald
commented
5 years ago As a way of experimenting with large-scale changes to this calculator, I started writing another calculator for the game Satisfactory. The most visible difference between this calculator and that is the use of a Sankey diagram for the visualization.
This was made possible by the d3-sankey library, which does quite a credible job of laying things out, but does not support cycles in a graph. That lack of support means that it will work with Satisfactory (which has no cycles), but not with Factorio (which does).
So I added it. It wasn't as hard as I thought. My little test page, which uses a bit of synthetic data based on the Factorio recipes for running a nuclear reactor, currently looks like this:
The important bit was finding this paper, which outlines an efficient algorithm for choosing a minimal set of links which would need to run backwards when laying out a graph in this way. Slotting that algorithm into d3-sankey turned out to be relatively painless.
Replacing the current visualizer is still a large project, but this was the biggest unknown.
This is a tracking issue for all matters related to a planned overhaul of the visualizer. The goal for the overhaul is to possess the following features (and I may think of more later). Some of these features could be added to the existing implementation, and some would require a significant re-write.
The current visualizer is the result of taking a third-party library and plugging the calculator data into it, with very little configuration. It is a relatively simple hack that I put together in a day or so, although I have modified it in various ways since its inception.
The current features I wish to add are:
Improved display of relative quantities
In other words, larger numbers should use thicker lines. The visualizer already does this to some extent, but this can be taken to a greater extreme. In particular, I would like to take inspiration from this image gallery, although this layout is made more complicated by the existence of recipe cycles.
This could also include the feature requested in #85 and #102, and display belt counts on the edges of the graph. (Although, truthfully, the only thing preventing this in the existing implementation is the additional visual clutter; I should probably add it as an option.)
It is likely that including all of the features that I wish to have will require writing my own layout engine, or at least heavily modifying an existing one.
Color
Nodes and edges of the graph should be assigned colors based on the recipes and items that they represent. Early experiments at automatically extracting the most "meaningful" color from each of the icons in the game have yielded encouraging results. My current approach involves extracting the most common RGB value from each icon, after dropping all pixels below some minimum saturation value. Further experimentation is called for.
Even without this approach, I believe that assigning colors completely arbitrarily would be an improvement over the current situation.
Interactivity
What I have in mind is some ability to tell the visualizer to split some recipe's prerequisites off into its own distinct sub-graph. This would address #53 and #120. The big unknown here is the treatment of oil products and other matrix-solved subgraphs. The multivariate nature of these portions of the graph means that there is no straightforward way of pulling them apart from one another. The visualizer would either need to split apart everything except for these components of the graph, or I would need to think of some clearer way of visually representing this relationship.
Alternatively, the visualizer could simply terminate with the products of these subgraphs when this feature is enabled. However, I consider this solution undesirable for a number of reasons: For one, this would be omitting a substantial portion of the solution. For another, it would make this feature of the visualizer nearly useless for more complex mods.
Less cluttered layout
This is a hard problem. Minimizing the crossing of lines when laying out a graph is NP-complete. However, the Factorio recipe graph is a little more specific than the generalized problem of laying out any digraph. I have a suspicion that a layout algorithm that is specific to this problem could be devised, which would yield results that I would consider more satisfactory than the current visualizer, without performing unacceptably slowly.
The third-party library that I currently use actually does quite a reasonable job at minimizing edge crossings. Coming up with something better would have to rely on details specific to this application. Even if I can't come up with something more clever than this third-party library, I hope that the earlier bullet points in this list (especially the addition of colors) will help with the readability of the graph.
It may also be worthwhile to evaluate other third-party libraries.
Determinism
This is strongly related to the less cluttered layout. I have a vague idea that I want graphs to be rendered in similar orders from one solution to the next. Slight changes to settings should not radically rearrange the visualization. This is another feature which would rely on having my own layout engine, and may therefore be more trouble than it is worth.