This 1997 paper introduced an alternative, much cheaper algorithm for rendering (Oriented) LICs
https://www.researchgate.net/publication/220943950_Fast_oriented_line_integral_convolution_for_vector_field_visualization_via_the_Internet
I think it would make perfect sense to have it as an available option, especially because it requires different input data that we could simply pattern-match to select the corresponding algorithm in perfect backward compatitbility and without introducing another keyword argument.
The core idea is to loop over circular "ink dropplets" (which replaces the traditionally noisy "texture" input), and approximate their traces by a finite series of same-size disks. The details require thinking time. Here's my initial take:
So, it seems to me that, without loss of generality, texture could be replaced by an array representing spots centers (x, y), radii, and initial "intensity". Coordinates should be expressed in units of image fraction [0, 1], while radii would feel more natural expressed as a number of pixels (so it stays closer to 1). The number of disks resulting from each spot should be somehow given by the kernel length, but then it's not obvious to me if stream lines should still be integrated one pixel at a time (although we don't want obvious artifacts to pop up when one switches algorithms...).
I think that iterations=0 and iterations=1 make sense, but any other value doesn't and should be forbidden. Boundary conditions can be supported too but would require a different treatment than what is already implemented.
This 1997 paper introduced an alternative, much cheaper algorithm for rendering (Oriented) LICs
https://www.researchgate.net/publication/220943950_Fast_oriented_line_integral_convolution_for_vector_field_visualization_via_the_Internet
I think it would make perfect sense to have it as an available option, especially because it requires different input data that we could simply pattern-match to select the corresponding algorithm in perfect backward compatitbility and without introducing another keyword argument.
The core idea is to loop over circular "ink dropplets" (which replaces the traditionally noisy "texture" input), and approximate their traces by a finite series of same-size disks. The details require thinking time. Here's my initial take:
So, it seems to me that, without loss of generality, texture could be replaced by an array representing spots centers (x, y), radii, and initial "intensity". Coordinates should be expressed in units of image fraction [0, 1], while radii would feel more natural expressed as a number of pixels (so it stays closer to 1). The number of disks resulting from each spot should be somehow given by the kernel length, but then it's not obvious to me if stream lines should still be integrated one pixel at a time (although we don't want obvious artifacts to pop up when one switches algorithms...).
I think that
iterations=0anditerations=1make sense, but any other value doesn't and should be forbidden. Boundary conditions can be supported too but would require a different treatment than what is already implemented.