summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-01-23stars: mess with the starfieldPhilip J Freeman
This commit adds some fun features to the starfield: - normalize aspect ratio to fragment size - rolling viewport - rotating viewport (with rate option)
2020-01-12libs/ray: decouple film and frame dimensionsVito Caputo
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.
2020-01-08modules/flui2d: static-ify flui2d_setup()Vito Caputo
2020-01-08README: add drizzle to modules listVito Caputo
2020-01-08modules/drizzle: add a classic 2D raindrops visVito Caputo
Using the new puddle lib throw some raindrops on the framebuffer
2020-01-08libs/puddle: add a classic 2D raindrop sim libVito Caputo
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.
2020-01-06rtv: rework randomized module selectionVito Caputo
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.
2020-01-06README: add spiro to modules listVito Caputo
2020-01-06stars: fat starsPhilip J Freeman
draw stars as circles that get larger as the approach the camera
2020-01-06spiro: spirograph emulatorPhilip J Freeman
This commit adds a module that emulates a spirograph
2020-01-03montage: bump Y tiles when root has large fractionVito Caputo
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.
2019-12-30montage: re-enable stars and pixbouncePhilip J Freeman
2019-12-30pixbounce: fix bugs, refactor for resizingPhilip J Freeman
- fix bug for square fragments - use create and destroy context hooks instead of globals - refactor to allow fragment resizing - handle extremely small fragments gracefully
2019-12-30stars: fix bugs, big refactor for resizingPhilip J Freeman
- use a context not globals - use floats and a "unit cube" to simulate the starfield
2019-12-18modules/rtv: remove stale random settings commentVito Caputo
Since 7a77cc1a landed this is no longer true, the .random member will be used to support randomizing non multiple-choice settings.
2019-12-18libs/din: fix scaling overflow, add assertsVito Caputo
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.
2019-11-26montage: add (threaded) to descriptionVito Caputo
While the montage doesn't deeply thread the per-tile/module rendering, the per-frame rendering is threaded with a work unit granularity of every module's tile. Meaning every module renders its tile in a single thread, but the tiles are all rendered in parallel. For the most part this works, and will only work better as more modules are added to rototiller increasing the granularity. In the mean time it's a bit coarse and some modules can be a lot more costly to render than others, and there can be a shortage of modules to schedule on idle CPUs. It would be an interesting task to try make each module's tile get subfragmented elastically. I didn't make any attempt to do that, but it might even be worthwhile on hidpi screens where even those small tiles may have a whole lot of pixels, especially on manycore CPUs.
2019-11-25meta2d: add a classic 2D metaballs moduleVito Caputo
2019-11-25din: scale resultVito Caputo
I'd like the output to fill the range -1..+1, but it's not doing that and I'm uncertain on what exactly the scaling factor should be here. In one reference a factor of 1/sqrt(.75) is specified, but in my tests that doesn't seem to quite fill the range but it doesn't seem to blow it out so it seems safe for now.
2019-11-25din: drop .f from integer additions in din()Vito Caputo
2019-11-25din: don't include v3f.h in din.hVito Caputo
This requires a forward declaration of v3f_t and changing din() to take a v3f_t *. The swab module needed updating to supply a pointer type and a v3f_t definition. This is being done so din.h users can have their own v3f implementations. I might consolidate all the duplicated vector code scattered throughout the libs and modules, but for now I'm carrying on with the original intention of having modules be largely self-contained. Though the introduction of libs like ray and din has certainly violated that a bit already.
2019-11-24TODO: remove autotools entryVito Caputo
This TODO is very stale and needs to be revisited.
2019-11-24snow: only create n_cpus fragmentsVito Caputo
Since snow_context_t needs another member anyways, stick n_cpus in there to inform the fragmenter of precisely how many fragments to make. This renderer doesn't benefit from tiling or any such locality, so it uses the slice fragmenter and really only benefits from as many fragments as there are CPUs. Any additional fragments is just wasted fragmenting overhead.
2019-11-24snow: per-cpu rand_r() seed stateVito Caputo
Snow was already threaded, but used a global seed with rand_r() meaning the CPUs were hammering on the same address. There wasn't any locking or atomics, as it isn't terribly critical when generating white noise if the seed access is racy. But the writes still caused cache lines to ping-pong. This commit gives a ~15.5% speedup in my measurements on an i7-2640M. Note without the padded union, using just an array of ints, zero gain is realized. I used a padding of 256 just to have some headroom, x86 is 64 but other CPUs vary, POWER9 is 128 for example.
2019-11-24montage: rework fragmenterVito Caputo
This repurposes the generic fb_fragment_tile_single() to better fit the montage use case. Partially covered areas are simply skipped, and tiles no longer need to be square. In determining the tile width and height, I'm just using the sqrt of the number of modules and dividing the frame width and height. But when the sqrt has a fraction, it's rounded up on the width divide and rounded down on the height divide. So the width gets the extra column of tiles, and the height just throws away the fraction. I think it's OK for now, until someone gets a bug up their ass and wants to avoid having vacant tiles in the bottom right corner when the number of modules doesn't cooperate. One problem with the just skipping partially covered areas is they don't get zeroed out - no fragment is ever generated for them. To fix that there will prolly have to be a fb_fragment_zero() of the frame @ prepare :(. I guess it wouldn't be the end of the world if the fragmenter itself zeroed out skipped regions. It's kind of an ugly layering violation but this is a private montage- specific fragmenter.
2019-11-24montage: rework module skippingVito Caputo
The old approach was just to get things working, it's preferable to not have empty tiles on-screen where modules were skipped and have all tiles be smaller to accomodate vacancies. Now the modules list gets pruned @ context create, so the skipping only happens once and everywhere else is looking at a modules list and count of only the keepers. I also added stars to the skipped modules, for now, since both stars and pixbounce malfunction when the fragment size changes.
2019-11-24README: alphabetize modules and add montageVito Caputo
2019-11-24montage: zero skipped fragmentsVito Caputo
Not doing this produces especially visible artifacts when shown by rtv.
2019-11-24montage: skip pixbounceVito Caputo
Segfaults were observed when montage came up in rtv, since pixbounce doesn't seem to be rendering properly at all just skip it for now. I suspect what's happening is rtv ran pixbounce before running montage, and pixbounce caches fragment knowledge @ initialization. So when montage ran pixbounce in a tile, that stale fragment knowledge was used and caused scribbling. Stars probably has similar problems actually.
2019-11-24montage: add montage moduleVito Caputo
This is somewhat unfinished as it uses the generic tiled fragmenter that's not interested in appearances but prioritizes total coverage and simplicity. Montage should have its own tiler that can produce non-square and even non-uniform tile dimensions, prioritizing filling the screen with mostly-uniform tiles. But that's a TODO item, this is good enough for now and exercises some fragment details previously irrelevant and often ignored/broken in modules. The pixbounce module in particular seems completely broken with small fragment sizes.
2019-11-24rototiller: rototiller_fragmenter_t s/num/number/Vito Caputo
Mechanical change removing abbreviation for consistency
2019-11-24fb: add number to fb_fragment_tVito Caputo
This introduces a stricter coupling and requirement for modules supplying a fragmenter in their prepare_frame() to only receive fragments produced by *their* fragmenter at their render_fragment(). When modules don't explicitly perform any fragmenting they can't really make much use of this number as it will reflect an arbitrary fragmenting pass's perspective. But when modules do perform their own frame fragmenting, they can assume any fragment supplied to their render function will have been generated by it. This needs to be enforced a bit in the code. The current use case is montage using a fragmenter for tiling the montage in a threaded render. The fragment numbers map to the modules to be rendered in the tiles. As long as modules can assume their fragmenter will always be what produces their fragments, this is perfectly fine.
2019-11-24fb: add pitch to fb_fragment_tVito Caputo
The put_pixel helpers really needed reworking to properly handle subframe fragments modules like montage will utilize. I had the stride present as it's convenient for a number of modules that maintain a buf pointer as they progress down a row, but the pitch is more applicable to put_pixel for scaling the y coordinate. Now there's both pitch and stride so everyone's happy with what's most convenient for their needs.
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-20julia: vary divergent thresholdVito Caputo
This makes the visualization more interesting by adding more variety.
2019-11-20settings: add setting_desc_t.random() methodVito Caputo
To facilitate random setting of these flexible string-oriented settings, support a random helper supplied with the description. This helper would return a valid random string to be used with the respective setting being described. Immediate use case is the rtv module, which also gets fixed up to use it in this commit.
2019-11-19rtv: randomize module settingsVito Caputo
This is just a quick stab at randomizing settings, only multiple choice setings are randomized currently. For modules with settings, a new Settings: field is added to the caption showing the settings as the arguments one would pass to rototiller's module argument.
2019-11-18swab: add a perlin noise visualizationVito Caputo
This maps a different Z-slice through the noise field to each color channel. The slices are moved up and down through the field over time, and the size of the area each color samples is tweaked a bit to make them less coherent with the noise field cells. It could be improved, but I think the output is already neat enough to be worth sharing.
2019-11-18libs/din: add a perlin noise implementationVito Caputo
This is a 3D noise field addressed as a unit cube. The caller supplies the resolution of the noise field in three dimensions. I've just pulled in my v3f.h here, but it probably makes sense to later on move vector headers into libs/ and share them. Later. It's called din as in noise, because it's shorter than perlin and noise.
2019-11-16threads: remove vestigial include from threads.hVito Caputo
2019-11-16rototiller: add missing pthread.h includeVito Caputo
2019-11-16modules/rtv: conslidate time() callsVito Caputo
Consolidate the time() calls in setup_next_module() by using a now variable.
2019-11-16modules/rtv: fix repeat preventionVito Caputo
This broke when snow was added.
2019-11-16modules/rtv: add captionsVito Caputo
The idea is to have captions similar to how MTV did back in the 80s. It'd be nice to make the text resolution independent, but this is a good first stab for an afternoon of tooling around.
2019-11-16libs/txt: add minimal ascii text rendererVito Caputo
This is as basic as it gets, the only fanciness is it recognizes newlines and supports horizontal and vertical justification. As this is intended to be run from potentially threaded fragmenter renderers, it receives a fragment and *frame* coordinates for the text to be rendered. If the text doesn't land in the given fragment, nothing gets drawn. Currently this is not optimized at all. There's a stubbed out rect overlap test function which could be used to avoid entering the text rendering loop for fragments with zero overlap, that's an obvious low-hanging fruit optimization. After that, skipping characters that don't overlap would be another obvious thing. As-is the text render loop is always entered and the bounds-checked put pixel helper is used. So every fragment will incur the cost of rendering the full string, even when it's not visible. For the rtv captions this isn't a particularly huge deal, but stuff to improve upon in the future.
2019-11-16libs/ascii: add a basic mono bitmap ascii charsetVito Caputo
The rtv module needs to show some captions, so I'm adding a minimal bitmap ascii text renderer.
2019-11-16rototiller: make rtv the default moduleVito Caputo
Also sort the modules alphabetically. Now that the major memory leaks are addressed (sparkler), make the rtv module the default since it gives the user an automated tour of all the modules. Explicit module use is more aimed at tinkerers playing with a specific module's code either creating their own or modifying an existing one, but isn't really desirable as the default flow.
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.
© All Rights Reserved