Open parasyte opened 2 years ago
The scaling function is the cause. The discussion in #23 seems to hint at that being the case.
If I replace generate_scaled()
with generate
and do my own scaling, I can generate seamless textures. The trouble is that I need to know the full range for every possible input to scale every possible output to [0, 255]
. Given the settings I am using, the min and max are 0.0
and 255.0
. Scaling with this expectation produces a result that is close to the first expected
image, just a little darker (because the actual max value seen is about 202.07
).
I am going to tentatively say this issue can be resolved by doing your own scaling. But since #27, the generate_scaled()
methods can just use a closed form expression to compute min/max instead of iterating the samples seen. It seems like that would "do the right thing" and prevent the issue that I stumbled upon.
Hey,
I had a similar problem that is related to the generate_scaled()
method. I was trying to generate 3d chunks using ridge_3d_offset
with generate_scaled(-1.0, 1.0)
and it resulted in offsets in neighbouring chunks
Applying my own scaling did not work because the min/max values for each chunks are different, so the scaling is never the same between. The only thing that works for me now is using the generate()
method, and apply an offset, without scaling.
I think it would be great to have a way to get the theoretical min/max of the noise function, so that I could apply the same scaling across chunks. Maybe I'm missing something.
I'm trying to create seamless textures using offsets, and even a naive attempt is failing when I combine a low frequency (like the default value 0.02) with a high number of octaves (like 8).
To make the issue even more obvious, I'm using a frequency of 0.125 in the images below, which gives it enough structure to verify the bug is not in the offsets I'm using or how the image is created.
Dimensionality doesn't matter. The seam appears with 2d, 3d, and 4d.
The code
Change the comments on lines 48 and 49 to swap between the expected result (`get_buffer_1`) and the actual result (`get_buffer_2`). ```rust use minifb::{Key, Window, WindowOptions}; const WIDTH: usize = 2048; const HEIGHT: usize = 1024; const HWIDTH: usize = WIDTH / 2; const FREQ: f32 = 0.125; const OCTAVES: u8 = 8; #[allow(dead_code)] fn get_buffer_1() -> VecExpected:
Actual:
The more I play around with various settings, the more I am convinced that there is some contribution from neighboring nodes that affects the output. For instance, if you put both images into layers and apply a difference operator, you'll see that they are roughly the same, but the left side is a bit brighter in the second image (where the seam appears) and the right side is slightly darker.
Increasing the frequency beyond 1.0 or lowering the octaves below 5 makes the seam incredibly difficult to notice. But I would be surprised if it ever goes away completely.