You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The multi-sampling option works by multiplying each dimension of the attractor's aggregation buffer, and then downsampling it using a Lanczos kernel in the shader. It also applies the colormap to each pixel right before scalar-multiplying with the kernel, so each pixel is unnecessarily colormapped multiple times.
The problem is that the kernel grows quadratically with the multi-sampling order, making the rendering too slow to run in full real-time for a non-small multisampling value. But the kernel used is actually separable, so we can make the slowdown grow linearly by separating the downsampling into horizontal and vertical passes.
This was not first done, not only because it was easier to implement, but also because I was afraid of using really big intermediate textures (the current approach only uses a single texture for the output, and a u32 array for the input aggregate buffer). But this choice doesn't work well enough, so better to risk the alternative approach. The "too big textures" problem can at least be solved by splitting the rendering into tiles.
The text was updated successfully, but these errors were encountered:
The multi-sampling option works by multiplying each dimension of the attractor's aggregation buffer, and then downsampling it using a Lanczos kernel in the shader. It also applies the colormap to each pixel right before scalar-multiplying with the kernel, so each pixel is unnecessarily colormapped multiple times.
The problem is that the kernel grows quadratically with the multi-sampling order, making the rendering too slow to run in full real-time for a non-small multisampling value. But the kernel used is actually separable, so we can make the slowdown grow linearly by separating the downsampling into horizontal and vertical passes.
This was not first done, not only because it was easier to implement, but also because I was afraid of using really big intermediate textures (the current approach only uses a single texture for the output, and a
u32
array for the input aggregate buffer). But this choice doesn't work well enough, so better to risk the alternative approach. The "too big textures" problem can at least be solved by splitting the rendering into tiles.The text was updated successfully, but these errors were encountered: