summaryrefslogtreecommitdiff
path: root/src/til.c
AgeCommit message (Collapse)Author
2023-09-02til: verify module and setup creator matchVito Caputo
til_module_create_contexts() currently supplies the til_module_t* independent from the til_setup_t*, but since the addition of til_setup_t.creator, we actually get the module from the setup as well. So let's at least assert that they match, since it'd be a real problem if a setup from a foreign creator somehow got here. It's tempting to refactor to just derive the module from the setup altogether and stop passing that around separately, but that kind of sucks as-is because til_setup_t is used by more than just rendering modules. It makes me lean towards deprecating til_setup_t.creator and instead having the various til_setup_t users subclass it with their own types like til_fb_setup_t and til_module_setup_t which each get typed creators, then pass those around. It's starting to smell like over-engineering, let's just roll with the assert.
2023-09-02flow: implement a 3D flow field moduleVito Caputo
This is kind of a particle system, where the particles are pushed around through a 3D vector space treated as a flow field. No physics are being simulated here, it's just treating the flow field as direction vectors that are trilinearly interpolated when sampled to produce a single direction vector. That direction vector gets applied to particles near it. To keep things interesting the flow field evolves by having two distinct flow fields which the simulation progressively alternates sampling from. For every frame, both flow fields are sampled for every particle, but how much weight is given to the influence of one vs. the other varies by a triangle wave over time. When the weight is biased enough to one of the flow fields near a peak/valley in the triangle wave, the other gets re-populated while its influence is negligible, also interpolating its new values with 25% influence from the active field. The current flow field population routine is completely random. Yet there's a surprising amount of emergent order despite being totally randomized direction vectors. Currently supported settings include: size= the width of the 3D flow field cube in direction vectors (the number of vectors is size*size*size) count= the number of particles/elements speed= how far a particle is moved along the current sample's direction vector This was first implemented in 2017, but sat unfinished in a topic branch for myriad reasons. Now that rototiller has much more robust settings infrastructure, among other things, it seemed worth finishing this up and merging.
2023-08-29til: s/til_module_setup_finalize/til_module_settings_finalize/Vito Caputo
Mechanical rename for clarity reasons, primarily to better differentiate from the setup_func style til_module_setup()/til_module_setup_full() functions.
2023-08-29til: s/til_module_setup_randomize/til_module_settings_randomize/Vito Caputo
Mechanical rename for clarity reasons, primarily to better differentiate from the setup_func style til_module_setup()/til_module_setup_full() functions.
2023-08-05til: fix til_module_setup_full() exclusionsVito Caputo
Stupid bug in untested/unused exclusions handling
2023-08-05til: use set_raw_value() in randomize_setup() overridesVito Caputo
Missed this in the last round of moving things to the new raw_value() setter/getter api This snippet of copy-n-pasta the few setup front-ends continue to have should really be factored out into a libtil helper
2023-08-05til_builtins: add "none" builtinVito Caputo
Sometimes nested modules are optional, in those cases I've usually been using the "none" module name to indicate this and the ad-hoc setup stuff can easily bypass module setup on that. This commit is a step towards having a "none" builtin that provides a til_module_t.setup() which succeeds but only produces a NULL res_setup when asked to finalize. So if callers just handle a successful finalize case that writes NULL at res_setup equivalent to "disabled", this all Just Works. Currently that's not an expected thing, but future commits will bring everything else on the same page. For callers who want to require the module and not offer "none", they can just put "none" in the explicit exclusions list passed to til_module_setup_full().
2023-08-05til: make builtins first-class modules w/new flagVito Caputo
Also move builtins to a separate listing while at it For now this results in the builtins showing up in the modules list alongside the actual rendering modules. Future work must refine this UX, maybe by adding some metadata to the spec.values for categorizing/prioritizing what's shown always vs. what's present but hidden without asking to be shown hidden stuff or whatever. Just consolidating some junk and working towards every nested module setup going through the same machinery, and always being able to access the builtins.
2023-08-05til_setup,*: add til_setup_t.creator pointerVito Caputo
Particularly with nested modules it's annoying to have to stow the module separate from the setup during the setup process. If the baked setup included the module pointer in the non-module-specific-setup part of the setup, then nested settings could finalize using the generic module setup wrapper and just rely on this til_setup_t.creator pointer to contain the appropriate module. Which should enable tossing out a bunch of copy-n-pasta surrounding nested modules setup. Note this has to be a void* since til_setup_t is a generic thing used equally by both the fb code and the module code. Hence why this is called "creator" and not "module", as well as the void* as opposed to til_module_t*. Also if rototiller ever grows a sound backend, the setup machinery will be reused there as well, and it'll be yet another creator handle that isn't an til_fb_ops_t or a til_module_t. It's assumed that the callers producing these setups won't be trying to pass them to the wrong places i.e. a module setup getting passed to an fb backend and vice versa. I'm mildly annoyed about having to move the various til_module_t blocks to above the module's foo_setup(), but it seemed like the least annoying option. This may be revisited.
2023-08-03*: nested settings should get the raw valueVito Caputo
When creating nested setting instances, just pass down the full raw value so if there's any prefix on the value it can be realized as a prefix for the first entry in the nested instance.
2023-08-03til: til_module_setup_randomize() raw value for spec.preferredVito Caputo
Now whenever a setting value/preferred input is derived from a setting, it'll want to get the raw value to preserve any prefix.
2023-08-03til: always apply filters in til_module_setup_full()Vito Caputo
The filter bypass was kind of a hack and resulted in unfiltered module lists in rkt_scener edits. Now that there's an explicit syntax for bypassing checks, the user can just do that to access what's filtered. So get back to appropriately consistent filtered results.
2023-07-31modules/signals: experimental signals moduleVito Caputo
Playing with libs/sig in 2D, this isn't really an interesting module by itself in terms of visual output. But it might have utility as a diagnostic thing if libs/sig becomes a more used thing. At the very least, for now, it's useful for observing affects of and iterating on libs/sig development. So I'm merging this, just gated behind TIL_MODULE_EXPERIMENTAL so it's not in rtv rotation or presented as something in the usual modules list.
2023-07-28til: add til_fragmenter_slice_per_cpu_x16() variantVito Caputo
This restores the original til_fragmenter_slice_per_cpu() while adding an explicit x16 variant for what til_fragmenter_slice_per_cpu() had become. The impetus for this is realizing the x16 multiplier is terrible for sparkler's crappy threading, and it really need strictly n_cpus slices for the threading to be beneficial. So I'm just getting rid of the hidden x16 in favor of making it explicit in an _x16 variant. Subsequent commit will pivot all the non-sparkler callers to til_fragmenter_slice_per_cpu_x16().
2023-07-28til: use til_module_render_limited() in "ref" builtinVito Caputo
Since "ref" renders using arbitrary foreign contexts, it must explicitly limit their rendering concurrency to its own.
2023-07-28til: introduce til_module_render_limited() variantVito Caputo
With the introduction of discoverable on-stream contexts, with the intention of modules finding them at runtime for nested rendering, relying exclusively on limiting n_cpus @ til_module_create_context() is no longer adequate. When the nested rendering makes use of a context created elsewhere, it can't make any assumptions about what its n_cpus is, nor should it be attempting to change that value for its use. So this variant just adds a max_cpus parameter for setting an upper bound to whatever is found in the context's n_cpus. The impetus for this is to fix the ref builtin, which you can currently trick into deadlock by performing a nested threaded render within a threaded render. What the ref module should be doing is propagating its own context's n_cpus down as the upper bound, via this new render variant.
2023-07-10til: introduce "noop" builtinVito Caputo
When profiling compositions it's convenient to suppress some modules in the settings to see how their omission affects the FPS. There's already a "blank" builtin which clears the fragment, but there's no way to turn the cost to ~zero. This "noop" builtin does just that, absolutely nothing - it won't even trigger the implicit "til_fb_fragment_t.cleared = 1" update so whatever rendering follows will still find an uncleared fragment if that's what came into the noop.
2023-07-09til: introduce til_module_setup_full()Vito Caputo
This moves the core til_module_setup() functionality out into a more composable helper with an eye towards all meta-modules using it for doing their module setup instead of all the ad-hoc stuff occurring presently. Since til_module_setup_full() needs more paramaters to influence its behavior, it's not directly usable as a "setup_func". But is trivially wrapped into one, which is what til_module_setup() has now become. It's in the wrapper that users are expected to do specify what's necessary for influencing til_module_setup_full() to do what's appropriate for their needs.
2023-07-08til: add timersub macro for __WIN32__Vito Caputo
just quick and nasty hacking to make win32 build again
2023-07-08til: measure til_module_render() durationsVito Caputo
This stows the duration (in ticks (which are ms for now)) of a given module context's most recent, as well as tracking the max, in til_module_context_t. For now it's also added to --print-module-contexts output, but this is still rather primitive and nearly inscrutible in practice... that output is a flickery and unsorted mess during playback. But this is just a start. Ticks may need to move up to microseconds if it'll also be the units for measuring timings. Right now things are slow enough that the low-hanging fruit stand out as multiple if not dozens of milliseconds so it's still useful for now.
2023-07-07til: introduce til_ticks_now()Vito Caputo
Thin wrapper around gettimeofday(), prolly change the main ticks stuff over to this too.
2023-07-05til: more strictly filter til_module_setup()Vito Caputo
It was too coarse a condition filtering the list on !name. This change actually looks up non-NULL names to verify it's a resolvable module name before producing the unfiltered list. Mostly just to prevent fat-fingered manual module inputs from resulting in unexpectedly larger and potentially dangerous module lists in interactive "invalid input" retries. Observed in the WIP rkt_scener stuff...
2023-07-05til: describe module name in til_module_setup_randomize()Vito Caputo
It just happened to be tolerable that the first setting in these randomized settings instances wasn't ever getting described... due to the ad-hoc nature of how rtv used them. But in preparation for rkt_scener which will have "randomize scene" functionality, as well as interactive (re)configuring of the scenes, these settings instances need to be more correct to not break things. It seems awkward to be duplicating this "Renderer module" desc here however. But I just want to make progress on the scene editor for rkt, I suspect this will be revisited in the future. On a high-level it feels like til_module_setup() should be the thing producing that desc, and the randomizer just picking the random settings through that setup func.
2023-07-04til: make til_modlue_setup() nested usage awareVito Caputo
When setting up a nested module, the HERMETIC modules shouldn't be considered as eligible nor should one be the preffered option (rtv). This uses the presence of a parent on the settings as a heuristic for if it's a nested scenario (no parent == root). When nested the default changes to "compose" from "rtv", and HERMETIC modules are omitted from the listed values.
2023-07-04til: optionally finalize in til_module_setup()Vito Caputo
This was assuming non-NULL res_setup which would assert in til_module_setup_finalize() which doesn't expect a NULL res_setup since that's its entire purpose. It's not a bug that was actually triggered by any callers (yet)
2023-06-19til: use 16 * n_cpus in til_fragmenter_slice_per_cpu()Vito Caputo
Slight improvement of CPU utilization for fragmenters using this strategy... I noticed tile64 would give better FPS in some scenarios where it seemed obvious slice_per_cpu() was the appropriate option. And that turned out to just be by virtue of being able to give idle threads something to do while busy ones finished what was on their plate. So just make the slices a bit more granular than n_cpus... this may have to be revisited in the future to find the sweet spot, and may need to be more sophisticated than just multiplying by a constant factor.
2023-06-15til_module_context: s/ticks/last_ticks/ in contextVito Caputo
And just maintain it as the last ticks value after rendering with the context... A couple modules were already doing this manually in an ad-hoc fashion, just make it a general thing. Updated those modules to reflect the new situation Especially in a rkt world with modules::mixer doing fades, it becomes common to render the same context twice in the same frame for the blending. We need to prevent accelerated animations in such situations. For now let's just rely on ticks in a delta-T fashion to prevent animating the context when ticks is the same. modules::stars in particular needs this fixed up, upcoming commit
2023-06-13til: til_module_setup() needs to finalize when no .setup()Vito Caputo
Commit 24911280 made til_setup_t required, and most setup code has already adopted til_module_setup_finalize() added in c94e4683 for this purpose. But til_module_setup()'s fall-through case when there's no til_module_t.setup() on the module being setup was missed. This broke running simple modules without a .setup() directly like --module=roto, oops. Fix is simple.
2023-06-13*: smattering of random small fixes to silence -WallVito Caputo
I thought the build was already using -Wall but that seems to not be the case, maybe got lost somewhere along the line or messed up in configure.ac After forcing a build with -Wall -Werror, these showed up. Fixed up in the obvious way, nothing too scary.
2023-06-12til: register contexts on-stream @ create timeVito Caputo
Module contexts are now discoverable via the stream a la til_stream_find_module_contexts(). The current architecture has the stream adding a reference to all the contexts registered. So even if they get unreferenced by their creators, they will linger on-stream. There's a gc mechanism til_stream_gc_module_contexts() which can be used to trigger a cleanup of contexts _only_ referenced by the stream. It's unclear as of yet if this is the way to go long-term, but it lets things work for now and allows some iterating and experimentation to see where to go next.
2023-06-12til: introduce "ref" built-in moduleVito Caputo
This opens up the possibility of referencing contexts on-stream by-path anywhere a module may be used: ref,path=/path/to/existing/context Currently the path lookup is performed @ render time, and a reference is taken on the context found there on the first time it's located. That reference is then held in the ref's context until its context is destroyed. There are more details to flesh out, and what probably needs to happen is some til_stream API for maintaining the reference in the event that the context at that path gets replaced. Due to refcounting, the referenced context will persist even if the stream-resident instance goes away, but there should probably be a way for that replacement to invalidate the existing references so they replace theirs with a fresh lookup at the path... Either way this is a good start. With this addition you can effectively implement scene transitions in rkt, via the mixer module, something like (sans proper escaping): mixer,a_module=ref\,path=/foo/previous/ctxt,b_module=ref\,path=/foo/next/ctxt
2023-06-11til: drop open_memstream() in til_get_module_names()Vito Caputo
open_memstream() isn't implemented by windows (not even mingw)
2023-06-11modules/mixer: add rudimentary mixer meta moduleVito Caputo
this is very early/unfinished, hence experimental flag
2023-06-05til: introduce til_module_create_contexts() variantVito Caputo
checkers::fill_module is presently implemented via creating n_cpus identical module contexts, each having n_cpus=1. Establishing a set of cloned per-cpu contexts, allowing threaded rendering using any fill_module, regardless of if that module internally implements threaded rendering. This works fine, but creates some awkwardness for a future where contexts are registered and discoverable within the stream at their respective setup's path. In the checkers::fill_module case, there would be n_cpus contexts at the same path since they share the same til_setup_t. Those need to be dealt with gracefully, ideally making the clones available to another potentially clone-needing module (imagine a checkers::fill_module transitionining to another checkers::fill_module situation, where the transitioned-to fill_module refers to the context by path, it should get all the contexts out of the stream as-is) In this commit I'm adding a more formalized method of creating multiple contexts from the same set of parameters, in preparation for a future where module contexts get registered on the stream at their til_setup_t.path. By putting the cloned creates behind the til API it should at least be relatively trivial to get the on-stream context registration to capture the multiple contexts.
2023-06-03til,modules/rtv: supply settings to til_module_setup_randomize()Vito Caputo
Rather than creating an orphaned settings instance private to til_module_setup_randomize(), the function now requires the settings instance be provided. The one remaining caller of this function is modules::rtv. Now that rtv is responsible for creating the settings beforehand, and the settings may be created with a path prefix, rtv gets its til_module_context_t->setup.path prefixed for all the channel settings. Another improvement is now the channel settings instance gets created from the module name as the settings string. So while it's not yet possible to sparsely specify settings with others being randomized, at least now when log_channels=on is in effect, the printed args include the top-level channel module. Having proper complete paths for the rtv channel modules is especially visible in --print-paths output FYI. An interesting test for exercising all this is: ``` $ src/rototiller --module=rtv,duration=0,context_duration=0,snow_module=none,channels=all,log_channels=on --print-pipes --defaults --go 2>/tmp/channels in another terminal: $ tail -F /tmp/channels ``` watch the chaos unfold
2023-06-03til: fix spurious empty res_arg in til_module_setup_randomize()Vito Caputo
r variable is checked for zero(success) before writing to *res_arg, but could be left uninitialized (especially in a future scenario where an incoming til_settings_t is fully populated and described).
2023-06-03til_settings: add an optional til_settings_t.prefixVito Caputo
Preparatory commit for bridging the gap separating a baked til_setup_t from a runtime-populated descendant til_settings_t like modules::rtv produces for its channels via til_module_setup_randomize(). For these currently orphaned til_settings_t instances we don't readily have access to the logical ancestor til_settings_t that was used to produce the module_context's bound til_setup_t. But we don't really need the ancestor til_settings_t, all we _really_ want is the ancestral path to prefix the orphan til_settings_t instances. So this commit introduces supplying a prefix which gets prepended to paths printed via the settings instance. A later commit will make use of this in modules::rtv when producing the settings instance passed to til_module_setup_randomize()
2023-06-03til: skip described settings in til_module_setup_randomize()Vito Caputo
Preparatory commit for when settings are supplied by caller, potentially populated and described.
2023-06-03til_settings: drop desc from til_settings_add_value()Vito Caputo
In a world where "describing" settings is an iterative process, especially post-nested-settings which are realized via the desc-applying process, it's better to not even offer desc-setting while adding a new setting. This commit just gets rid of that. The one caller that was passing a non-NULL desc to til_settings_add_value(), til_module_setup_randomize(), was redundantly doing so since the subsequent desc-processing was assigning it again anyways. Future commits will likely change til_module_setup_randomize() use a non-NULL desc for skipping desc-applying, which wouldn't even work if it was always setting the desc @ add time. That becomes necessary for partially randomizing sparsely-populated settings.
2023-06-03til: add exclusions to til_get_module_names()Vito Caputo
There's often a need to exclude specific modules, though it's often a hacky kludge. It's something relied upon currently for preventing dangerous recursion scenarios, which will likely get fixed up more robustly in the future.
2023-06-03til_settings,setup: introduce til_setting_spec_t.override()Vito Caputo
In situations where modules wish to alias setting values like expanding "all" -> "mod0,mod1,mod2,mod3" they need a way to intercept the value-acceptance @ desc-assignment time in the front-end. This optional override() function does just that when present in the spec. The current setting's value is passed to the override, and if what's returned differs from what was passed (by pointer value), then the current value is freed and the override takes its place. The override function is expected to _always_ return non-NULL; either the value provided, or a newly allocated value override. The override function must never free the supplied value, that's the front-end's job in applying the override. The override() must return NULL on errors, which are assumed to be limited to ENOMEM failures.
2023-06-03til: add til_get_module_names() helperVito Caputo
Composite modules that want to provide "all" aliases for modules like rtv have to construct a comma-separated string of all module names, usually filtered by some flags. This helper does just that, but it does add yet another open_memstream() user to revisit when those all get fixed up.
2023-05-30til: s/til_module_randomize_setup/til_module_setup_randomize/Vito Caputo
Mechanical rename just to make this consistent with til_module_setup()/til_module_setup_finalize() I should probably do a cleanup pass throughout the til APIs to standardize on a subject-verb-object or subject-object-verb order... Things have become a little inconsistent organically over time
2023-05-30til,*: pivot to til_setup_t for context pathsVito Caputo
This changes til_setup_t* from optional to required for til_module_context_t creation, while dropping the separate path parameter construction and passing throughout.
2023-05-30til: make til_module_randomize_setup() always produce a setupVito Caputo
Preparatory for required til_setup_t @ til_module_create_context() This basically brings til_module_randomize_setup() inline with til_module_setup_finalize() in that it will still produce a minimal til_setup_t even if there is no til_module_t.setup() method. A future commit will do something about the orphaned til_settings_t within til_module_randomize_setup() to get a full path on the produced setup - which will likely simultaneously bring us into a world where one can influence the randomized settings externally as well. Influenced in the sense of potentialy making some of those settings statically configured while leaving others to be (re)randomized at the time of til_module_randomize_setup() executing.
2023-05-30til: add til_module_setup_finalize() helperVito Caputo
Preparatory commit for til_module_create_context() requiring setups even when there's no til_module_t.setup() method. This helper will produce the minimal til_setup_t in such cases, or hand off the task to til_module_t.setup() when present. Note the need for passing res_setting and res_desc to til_module_t.setup() despite not being a settings-construction scenario. This is because of how modules using nested settings tend to use res_setting for storing the current setting in accessing the nested instance, which must still occur even when just baking the complete setup. It's expected that any composite/meta modules utilizing other modules will use this helper to produce the baked setups, instead of the ad-hoc direct calling of til_module_t.setup() they do presently.
2023-05-30til: find explicitly set experimental modulesVito Caputo
b9123bbb added describing incoming preexisting settings, but the spec's returned values omitted experimental modules. This resulted in breaking the ability to say things like --module=rkt to access the experimental rkt module despite it not showing in the interactive setup list of values. This commit includes experimental modules in the spec's values when being produced for a preexisting, undescribed setting. Restoring one's ability to access experimental modules via the CLI.
2023-05-26til_settings: add til_setting_spec_t.as_labelVito Caputo
Currently settings instances get labels from three sources: 1. explicitly labeled by a root-level til_settings_new() call, like main.c::til_settings_new(NULL, "video", args->video); 2. implicitly labeled in a spec.as_nested_settings w/spec.key 3. positionally labeled in a spec.as_nested_settings w/o spec.key But when constructing setting/desc paths, using strictly these settings instance labels as the "directory name path component" equivalent, leaves something to be desired. Take this hypothetical module setting path for example: /module/layers/[0]/viscosity Strictly using settings instance labels as-is, the above is what you'd get for the drizzle::viscosity setting in something like: --module=compose,layers=drizzle Which is really awkward. What's really desired is more like: /module/compose/layers/[0]/drizzle/viscosity Now one way to achieve that is to just create more settings instances to hold these module names as labels and things would Just Work more or less. But that would be rather annoying and heavyweight, when what's _really_ wanted is a way to turn the first entry's value of a given setting instance into a sort of synthetic directory component in the path. So that's what this commit does. When a spec has .as_label specified, it's saying that path construction should treat this setting's value as if it were a label on a settings instance. But it's special cased to only apply to descs hanging off the first entry of a settings instance, as that's the only scenario we're making use of, and it avoids having to do crazy things like search all the entries for specs w/.as_label set. It feels a bit janky but it does achieve what's needed with little pain/churn.
2023-05-26til: more setup desc handling fixupsVito Caputo
7ff8ef94 switched things to always describe relevant settings, but left some loose ends. Obvious fixups for those
2023-05-26setup,til: assert(desc) if setup_func() wants more settingsVito Caputo
In this "all settings require descs" world, when setup_func forgets to return a res_desc for a setting it wants, we can end up in an infinite loop situation. It's better to abort immediately on the assert to catch such a program error.
© All Rights Reserved