summaryrefslogtreecommitdiff
path: root/src/modules/sparkler
AgeCommit message (Collapse)Author
2020-09-11module/sparkler: implement some BSP drawing settingsVito Caputo
This commit adds a few settings for visualizing the octree BSP: show_bsp_leafs (on/off): Draw wireframe cubes around octree leaf nodes show_bsp_leafs_min_depth (0,4,6,8,10): Set minimum octree depth for leaf nodes displayed show_bsp_matches (on/off): Draw lines connecting BSP search matches show_bsp_matches_affected_only (on/off): Limit drawn BSP search matches to only matches actually affected by the simulation The code implementing this stuff is a bit crufty, fb_fragment_t had to be pulled down to the sim ops for example and whether that actually results in drawing occurring during the sim phase depends on the config used and how the particle implementations react to the config... it's just gross. This matters because the caller used to know only the draw phase touched fb_fragment_t, and because of that the fragment was zeroed after sim and before draw in parallel. But now the caller needs to know if the config would make sim do some drawing, and do the fragment zeroing before sim instead, and skip the zero before draw to not lose what sim drew. It's icky, but I'll leave it for now, at least it's isolated to the sparkler.
2020-09-11modules/sparkler: wire up particles_conf_t settingsVito Caputo
These don't actually do anything yet
2020-09-11modules/sparkler: add particles conf parameterVito Caputo
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.
2020-01-25rototiller: introduce ticks and wire up to modulesVito Caputo
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.
2019-11-24rototiller: rototiller_fragmenter_t s/num/number/Vito Caputo
Mechanical change removing abbreviation for consistency
2019-11-23rototiller: pass cpu to .render_fragment()Vito Caputo
Mostly mechanical change, though threads.c needed some jiggering to make the logical cpu id available to the worker threads. Now render_fragment() can easily addresss per-cpu data created by create_context().
2019-11-23rototiller: pass num_cpus to .create_context()Vito Caputo
Back in the day, there was no {create,destroy}_context(), so passing num_cpus to just prepare_frame made sense. Modules then would implicitly initialize themselves on the first prepare_frame() call using a static initialized variable. Since then things have been decomposed a bit for more sophisticated (and cleaner) modules. It can be necessary to allocate per-cpu data structures and the natural place to do that is @ create_context(). So this commit wires that up. A later commit will probably have to plumb a "current cpu" identifier into the render_fragment() function. Because a per-cpu data structure isn't particularly useful if you can't easily address it from within your execution context.
2019-11-16sparkler: use chunker in bspVito Caputo
This simplifies the bsp code while addressing cleanup
2019-11-16sparkler: remove assert from chunker_free_chunker()Vito Caputo
This assert prevents using the chunker for efficient freeing, maybe in the future add a flag for toggling this but for now it can just be commented out.
2019-11-16sparkler: plug some memory leaksVito Caputo
particles_free() didn't do all the necessary cleanup. bsp_free() remains mostly unimplemented. I think this wasn't done at the time because I was thinking bsp.c should use the chunker, then cleanup is just a matter of freeing the chunker instead of traversing the bsp.
2018-02-27autotools: remove vestigial ROTOTILLER_* varsVito Caputo
Fixes silly cosmetic error in configure output for checking libdrm...
2017-09-14fb: s/fb_fragment_divide_single/fb_fragment_slice_single/Vito Caputo
Mechanical cosmetic change
2017-09-14*: use fragment generatorVito Caputo
Rather than laying out all fragments in a frame up-front in ray_module_t.prepare_frame(), return a fragment generator (rototiller_fragmenter_t) which produces the numbered fragment as needed. This removes complexity from the serially-executed prepare_frame() and allows the individual fragments to be computed in parallel by the different threads. It also eliminates the need for a fragments array in the rototiller_frame_t, indeed rototiller_frame_t is eliminated altogether.
2017-04-27*: remove vestigial module/${module}/${module}.hVito Caputo
Prior to rototiller_module_t these headers were included and the module-specific render functions called directly. That's no longer the case, these files are irrelevant today.
2017-04-27sparkler: enable rudimentary threaded renderingVito Caputo
This moves most of the particle system maintenance into the serially executed sparkler_prepare_frame(), divides the frame into ncpus fragments, and leaves the draw to occur concurrently. The drawing must still currently process all particles and simply skips drawing those falling outside the fragment. Moving more of the computation out of prepare_frame() and into render_fragment() is left for future improvements, as it's a bit complex to do gainfully.
2017-04-27sparkler: respect fragment->frame_{width,height}Vito Caputo
should_draw_expire_if_oob() assumed the fragment represented the entire frame. Instead, return 0 if the coordinates are outside the fragment, but only reset longevity if outside of the frame. If sparkler goes threaded in the drawing, this would result in threads simply skipping particles outside the fragment. The longevity reset occurring in all threads appears suspicious but should be benign since they all write the same thing - 0.
2017-04-26sparkler: utilize context struct for module stateVito Caputo
2017-04-26sparkler: add virtual flag to particle_props_tVito Caputo
The burst particle abused a zero mass to circumvent the effects of aging. Instead use an explicit virtual flag to suppress aging, change busrt_cb to ignore all virtual particles instead of only its center. Previously burst_cb would thrust other bursts like any other particle, and this was incorrect. Now burst centers are always stationary, even when they overlap other bursts.
2017-04-22*: add module context machineryVito Caputo
introduces create_context() and destroy_context() methods, and adds a 'void *context' first parameter to the module methods. If a module doesn't supply create_context() then NULL is simply passed around as the context, so trivial modules can continue to only implement render_fragment(). A subsequent commit will update the modules to encapsulate their global state in module-specific contexts.
2017-04-22*: /render/render_fragment/ in rototiller_module_tVito Caputo
Adding more context to the name in anticipation of adding a prepare_frame() method to the module struct.
2017-04-21*: s/renderer/module/gVito Caputo
Make consistent with the source directory structure naming.
2017-04-21sparkler: remove vestigial draw.h from Makefile.amVito Caputo
2017-02-03*: use fb_fragment_zero() instead of memset()Vito Caputo
2017-02-03sparkler: drop draw.hVito Caputo
2017-02-03sparkler: use fb.h put_pixel helpersVito Caputo
discards draw_pixel(), introduces helpers.h and a convenience function for bounds checking and oob extermination. Move makergb to helpers.h, draw.h gets removed in a later commit.
2017-02-03rototiller: extricate draw_pixel() bounds checkingVito Caputo
If a z-buffer is added these checks will need to be done independent from and prior to drawing. Also it's silly to makergb() pixels which can't be drawn.
2017-01-18autotools: s#../../#@top_srcdir@/src#Vito Caputo
The relative path broke out-of-tree builds. Previously the following: $ mkdir /tmp/foo $ cd /tmp/foo $ ~/src/rototiller/configure $ make Would fail to compile unable to locate the headers in ~/rototiller/src This fixes it.
2017-01-18*: move source into src/ subdirVito Caputo
Restoring some organizational sanity since adopting autotools.
© All Rights Reserved