| Age | Commit message (Collapse) | Author |
|---|
|
Just stubbed out for now, wanting to restore some octree overlays like
the old standalone sparkler had. Those can be wired up to settings so
rtv can occasionally show the spatial partition and matched particles.
|
|
This seems unnecessary and doesn't always read well in combination
with a given setting name string.
Just get rid of it for now.
|
|
My current version of mingw in debian 9.11 doesn't seem to have
rand_r(), so let's just use plain rand() and lose the improved
parallelization on win builds.
|
|
Using strlen on the input string isn't safe; it may be unterminated
|
|
Added a triangle wave
|
|
This builds minimally upon the existing sine wave code,
just use the sign to drive the signal high or low.
Wikipedia shows a third state for 0 values, but that's for a -1..+1
signal. I'm producing all 0-1 signals as it's more convenient for
this application, but it seems like it would be awkward to return
.5f for the 0 case. So 0 is being treated as just another positive
value; high.
|
|
Provides improved ergonomics when using the bulitin ops, and much
appreciated arity and type checking.
|
|
Added some rudimentary refcounting so sig_t's can be readily shared
by multiple sig_t's.
|
|
Seems broken, fix it correctly later.
|
|
off by one order of magnitude
|
|
map 0-1 inputs to their inverse 1-0
|
|
Rename inv->neg, preparation for a new sig_ops_inv for inverting
0..1 to 1..0
|
|
Included a little hack to defend against divide by zero, seems
reasonable given the intended use cases.
|
|
|
|
This is a specialized version of sig_ops_scale which assumes a
min..max range of -1..+1
nvidia register combiners docs describe this operation as "expand
normal", and they have several variants, but I don't want to go
too crazy here right now. Plain expand it is.
|
|
This assumes the input value is always 0-1, but may be used to produce
values in any signed range, mapped linearly to the input.
|
|
aka negation
|
|
The whole idea was to produce values 0-1, except of course
sig_ops_{mult,const} where one could deliberately get out of
these bounds.
Everything else should stay within 0-1 as it makes everything
much more composable.
|
|
Supply two sig_t *'s: a, b
|
|
Supply three sig_t *'s: value, min, max
|
|
Added a simple test exercising pow and round
|
|
The flexible array of void *'s would just align to a pointer,
which may not be safe for all members of whatever gets shoved in
here.
In an effort to make it more robust, make it an array of a junk
drawer union of types.
|
|
Comment was vestigial from ops_mult.c which ops_lerp.c was derived
from.
|
|
(Ab)uses rand_r by feeding ticks_ms as seedp for pseudo-random
numbers deterministically derived from ticks_ms.
|
|
|
|
Make sig_ops_t.destroy functions consistently after init, no
functional changes.
|
|
This takes three signals; a, b, and t
t controls the weight interpolating between a and b, they all key
off the same time ticks_ms.
|
|
Now hz can vary with time as well...
|
|
The simplest of signals: a constant value.
The immediate need for this is to convert ops_sin_ctxt_t.hz to
another sig_t enabling varying hz with time, while still being
able to have a fixed hz as well.
|
|
This adds a small framework of sorts for creating and composing signal
generators.
Two generators are implemented at this time; sig_ops_sin and sig_ops_mult
sig_ops_sin accepts a hz variable and will produce a sine wave of that
frequency.
sig_ops_mult accepts two sig_t generators and multiplies their outputs
Callers may construct their own sig_ops_t ops structs and supply them to
sig_new(), but it's expected that libs/sig will grow a collection of
commonly used generators which can then be used by simply passing their
sig_ops_$foo to sig_new().
See the test code at the bottom of libs/sig/sig.c for some contrived
sample usage. Note by composing multiple sig_ops_sin generators with
a sig_ops_mult generator, one can already easily construct a synth-like
LFO generator.
Some obvious todos are to add triangle/sawtooth/square wave generators.
More compositional generators may be interesting as well, like additive
and subtractive for example. Those will need to implement clipping, as
it's expected that the generators *always* stay within unity (0-1).
No modules use this yet, but I expect to wire this up to rtv for driving
knobs.
|
|
This is intended for modules to expose bindings for floats affecting
rendering output that may be varied at runtime frame-to-frame.
See the comment in knobs.h for more information.
This commit only introduces the concept, no modules utilize it yet.
|
|
Cosmetic change, put setup with the other function pointers.
|
|
Modulo ticks by 2*M_PI to preserve precision by constraining the float
to 2*M_PI radians.
|
|
Missed this!
|
|
Make naming consistent
|
|
Most modules find themselves wanting some kind of "t" value increasing
with time or frames rendered. It's common for them to create and
maintain this variable locally, incrementing it with every frame
rendered.
It may be interesting to introduce a global notion of ticks since
rototiller started, and have all modules derive their "t" value from
this instead of having their own private versions of it.
In future modules and general innovations it seems likely that playing
with time, like jumping it forwards and backwards to achieve some
visual effects, will be desirable. This isn't applicable to all
modules, but for many their entire visible state is derived from their
"t" value, making them entirely reversible.
This commit doesn't change any modules functionally, it only adds the
plumbing to pull a ticks value down to the modules from the core.
A ticks offset has also been introduced in preparation for supporting
dynamic shifting of the ticks value, though no API is added for doing
so yet.
It also seems likely an API will be needed for disabling the
time-based ticks advancement, with functions for explicitly setting
its value. If modules are created for incorporating external
sequencers and music coordination, they will almost certainly need to
manage the ticks value explicitly. When a sequencer jumps
forwards/backwards in the creative process, the module glue
responsible will need to keep ticks synchronized with the
sequencer/editor tool.
Before any of this can happen, we need ticks as a first-class core
thing shared by all modules.
Future commits will have to modify existing modules to use the ticks
appropriately, replacing their bespoke variants.
|
|
This commit adds some fun features to the starfield:
- normalize aspect ratio to fragment size
- rolling viewport
- rotating viewport (with rate option)
|
|
The existing code conflated the rendered frame dimensions with
what's essentially the virtual camera's film dimensions. That
resulted in a viewing frustum depending on the rendered frame
dimensions. Smaller frames (like in the montage module) would
show a smaller viewport into the same scene.
Now the view into the scene always shows the same viewport in
terms of the frustum dimensions for a given combination of
focal_length and film_{width,height}.
The rendered frame is essentially a sampling of the 2D plane
(the virtual film) intersecting the frustum.
Nothing is done to try enforce a specific aspect ratio or any
such magic. The caller is expected to manage this for now, or
just ignore it and let the output be stretched when the aspect
ratio of the output doesn't match the virtual film's aspect
ratio.
In the future it might be interesting to support letter boxing or
such things for preserving the film's aspect ratio.
For now the ray module just lets things be stretched, with
hard-coded film dimensions of something approximately consistent
with the past viewport.
The ray module could make some effort to fit the hard-coded film
dimensions to the runtime aspect ratio for the frame to be
rendered, tweaking things as needed but generally preserving the
general hard-coded dimensions. Allowing the frustum to be
minimally adjusted to fit the circumstances... that might also be
worth shoving into libray. Something of a automatic fitting
mode for the camera.
|
|
|
|
Using the new puddle lib throw some raindrops on the framebuffer
|
|
These were commonish in the 90s demo days, done as a library to encourage
use by different modules.
You can simply render this directly onto a frame buffer like the old days,
or sample it as a height map or density field for more complex compositions.
|
|
Switch to working through the set of modules in a random order,
randomizing the order once per cycle.
This way no modules get starved for display, which was pretty common
in the old method.
|
|
draw stars as circles that get larger as the approach the camera
|
|
This commit adds a module that emulates a spirograph
|
|
Ideally the number of modules can tile without leaving gaps, but
as rototiller evolves over time modules are added piecemeal so
try accomodate those awkward layouts.
|
|
|
|
- fix bug for square fragments
- use create and destroy context hooks instead of globals
- refactor to allow fragment resizing
- handle extremely small fragments gracefully
|
|
- use a context not globals
- use floats and a "unit cube" to simulate the starfield
|
|
Since 7a77cc1a landed this is no longer true, the .random member
will be used to support randomizing non multiple-choice settings.
|
|
Phil reported a crash in swab, illuminating an overflow in how the unit
cube was being scaled to the noise field dimensions.
Added some asserts enforcing critical assumptions as well, though it
will probably cost some FPS in din-heavy modules like swab.
|
