summaryrefslogtreecommitdiff
path: root/src/libs/ray/ray_gamma.c
diff options
context:
space:
mode:
authorVito Caputo <vcaputo@pengaru.com>2022-09-05 22:02:59 -0700
committerVito Caputo <vcaputo@pengaru.com>2022-09-05 22:43:40 -0700
commit3dc6f1f6eecb9e8f0e91454faf4fe00c61d35dd9 (patch)
treeb25465c7eb8b40ece45e73fa0a3aa3f949370edf /src/libs/ray/ray_gamma.c
parentb4c9935b5d167ca2ef69b5a6a81ae207f462b45c (diff)
til_util: add helper for turning ticks into radians
There's still a handful of modules doing ad-hoc radians accumulation in a static variable by simply adding a small value like .01 every render. This worked OK in the early days when 1. no rototiller instance was ever run long enough for that accumulator to become a large value where floating point precision started rearing its ugly head. and 2. rototiller never really drew the same module multiple times in compositing a frame. Now that rototiller can produce some rather interesting outputs the first assumption isn't really true - I've fixed memory leaks to enable long-running sessions, so these potential precision problems should get dealth with. And with rtv+compose/checkers+fill_module it's quite common to have a module rendering things many times in a single frame. So that previously tolerable laziness of using a static accumulator is no longer acceptable, since every invocation of the module's renderer would bump the accumulator. When you have something like checkers using blinds for the filler, every individual cell is unintentionally advancing the blinds when they're intended to be at the same phase. So this helper is being added to conveniently turn ticks into something you'd pass directly into cosf/sinf without worrying about precision issues. Future commits will start bringing modules over to use this helper instead of whatever they're doing with static variables or in-context accumulators etc. There's also another reason to prefer deriving "T" from ticks on every frame; we can do things like fast-forward/rewind effects on modules by manipulating the ticks input value. If the modules are accumulating this state privately, manipulating ticks won't have the intended effect. Of course not all modules are amenable to this kind of thing, stuff like swarm and sparkler where they do a sort of simulation contain a pile of state that isn't ticks-derived on every frame and can't really be converted to do so.
Diffstat (limited to 'src/libs/ray/ray_gamma.c')
0 files changed, 0 insertions, 0 deletions
© All Rights Reserved