The function single_cellular is used to compute 'cellular' noise for CellularReturnType::CellValue and CellularReturnType::Distance. However, most of the code in the function is essentially dead - the return value is currently only determined by the input coordinates and the RNG seed (code copied from https://github.com/amethyst/bracket-lib/blob/master/bracket-noise/src/fastnoise.rs#L3857-L3862):
match self.cellular_return_type {
CellularReturnType::CellValue => {
self.val_coord_2d(self.seed as i32, x as i32, y as i32)
}
_ => 0.0,
}
Intuitively, I expect that when writing distance to a new 'minimal' value, also the corresponding coordinates xi and yi should be remembered and passed to val_coord_2d. Something entirely different from return 0.0 is likely necessary for other values of CellularReturnType. Looking at the original source in https://github.com/Auburn/FastNoiseLite/blob/master/C/FastNoiseLite.h#L1402 seems to confirm this.
The function
single_cellularis used to compute 'cellular' noise forCellularReturnType::CellValueandCellularReturnType::Distance. However, most of the code in the function is essentially dead - the return value is currently only determined by the input coordinates and the RNG seed (code copied from https://github.com/amethyst/bracket-lib/blob/master/bracket-noise/src/fastnoise.rs#L3857-L3862):Intuitively, I expect that when writing
distanceto a new 'minimal' value, also the corresponding coordinatesxiandyishould be remembered and passed toval_coord_2d. Something entirely different fromreturn 0.0is likely necessary for other values ofCellularReturnType. Looking at the original source in https://github.com/Auburn/FastNoiseLite/blob/master/C/FastNoiseLite.h#L1402 seems to confirm this.