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
Since Fbm's fields are public, I assumed that the correct way of changing them was just to modify them.
This worked for many cases, but then I noticed that I sometimes started getting panics, which I tracked down to me setting octaves to greater than 6, e.g.:
use noise::{NoiseFn, Fbm};
fn main() {
let mut fbm_noise = Fbm::new();
fbm_noise.octaves = 7;
println!("{}", fbm_noise.get([1.0, 1.0]));
}
which panics with
thread 'main' panicked at 'index out of bounds: the len is 6 but the index is 6', /rustc/4fb7144ed159f94491249e86d5bbd033b5d60550/src/libcore/slice/mod.rs:2842:10
After reading the source, I eventually found out that there was a MultiFractal trait which adds a set_octaves function to Fbm - using that avoids the panic.
It took me a while to disover that though, so adding some docs saying that Fbm's fields shouldn't be mutated directly (or maybe making them private), and adding a mention of the MultiFractal train in the Fbm docs could make things clearer.
The text was updated successfully, but these errors were encountered:
Thank you for pointing this out. I'll have to go over Fbm and the other structs, and make sure that they can't end up in an invalid state during construction.
I have a question, which is kind of related:
Why is the field for octaves in Fbm pointer sized, when it is later clamped between 1 and MAX_OCTAVES(32)?
Forgive me, if this is a stupid question, i'm just starting with rust.
Since
Fbm
's fields are public, I assumed that the correct way of changing them was just to modify them.This worked for many cases, but then I noticed that I sometimes started getting panics, which I tracked down to me setting
octaves
to greater than 6, e.g.:which panics with
After reading the source, I eventually found out that there was a
MultiFractal
trait which adds aset_octaves
function toFbm
- using that avoids the panic.It took me a while to disover that though, so adding some docs saying that Fbm's fields shouldn't be mutated directly (or maybe making them private), and adding a mention of the
MultiFractal
train in theFbm
docs could make things clearer.The text was updated successfully, but these errors were encountered: