Closed frkbr closed 6 years ago
Thanks for reproducing the problem so nicely. I am not entirely sure what Disco introduces in its animation feature. It seems that it also merges tokens that travel on top of each other to a larger token, which is a feature on my TODO list.
Looking at both animations, I think one cause that the bottleneck is not as visible in processanimateR is that the edge is rendered much shorter than in the Disco model. As mentioned in the disclaimer on the project side the non-equal edge length in process models is a drawback of these token animations. If the edge would be longer, we might see the tokens more spread out and perceive the problem as more severe. Actually, a whole set of problems associated with this and I plan to look at this in the future.
What could maybe work in this case, is to borrow the 'jitter' concept from scatterplots and randomly move tokens a bit from the actual path. Just have to figure out how to do this with the SVG animations I use.
On the other hand, the length of the edges doesn't seem to play a major role, as can be seen in this and in this example. Bottlenecks are visible on short edges too.
In the SVG animation the tokens seem to jump from activity to activity and skip the edges. If several tokens are waiting for the next activity, they also seem to appear as one token. In the Disco animation separate tokens travel along the edges relatively slowly. Besides the merging of tokens that you described, one can also observe faster tokens overtaking slower ones on the edges.
Different vendors seem to use totally different animation algorithms, as can be seen in this example from Lana labs. The one from Disco gives an excellent visual representation of bottlenecks, but might be hard to replicate, if their algorithm is proprietary.
I've just found this: the Disco animation seems to be an advanced version of the ProM plugin "Animate Event Log in Fuzzy Instance", which creates such animations. The co-founder of Fluxicon described an early approach in chapter 8.2 of his thesis.
Another animation where the tokens look more similar to the SVG-animation is produced by the ProM plugin "Mine with Inductive Visual Miner", which creates such animations.
Applying these two ProM plugins to the same data set creates the following results:
Maybe these could be combined or integrated somehow with the SVG-animation?
This is going to take some more time.
I have just added an 'animation_jitter' option to the animate_process
call, which separates the tokens a bit. Another option available now is to reduce the token_opacity
to see through tokens, which might help to see congestion better.
Replicating the approach of Fluxicon's Disco is not as simple since this library uses declarative animations with SVG SMIL. So I cannot simply plug-in to the rendering loop to do stuff like token merging. An interesting option would be pre-clustering the tokens according to their timestamps. If someone wants to give it a try or has an algorithm, please let me know.
Your image above looks good, but I'm not able to replicate your visualization of the congestion. What value did you use for jitter?
When I try this with v 0.2.0 and jitter = 10:
Log %>% animate_process(token_color = "orange",animation_jitter = 10, rankdir = "TB")
... I get this result which looks different from yours: http://rpubs.com/frkbr/421046
Despite the jitter, my tokens seem to stick with the activity "Amend Request for Quotation Requester". When I use higher jitter values, the jitter seems to separate the tokens vertically, but not horizontally.
Could there be something wrong with my setup?
I just tried again and it worked without problem. The separation should follow the shape of the edge and occur orthogonal to the edge. However, I also tried with Firefox and Internet Explorer and found that it is very slow and seems to not render the tokens correctly. Did you use one of these browsers?
I will investigate in a separate issue.
You're right, the browser is the problem. I used Safari. When running the animation in Chrome, it looks just like your image. I think I'll ditch Safari, it's not the first time that this browser causes trouble. Thanks for the hint.
Closing this issue and will continue the bug fixing in #7
Thank you for this package! It's a great addition to the excellent bupaR package. I took a purchasing example dataset from Fluxicon to compare the two animations:
In the Disco animation the bottleneck at the activity “Analyze Request for Quotation” is more obvious. Perhaps there might be a way to show the movement of the tokens along the arrows and keep the different tokens separate from each other in processanimateR? This could make congestions visible as in the Disco animation. What do you think?
Code and dataset of my comparison: https://github.com/frkbr/Purchasing-Example.git