summaryrefslogtreecommitdiff
path: root/src/libs
AgeCommit message (Collapse)Author
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-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.
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-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-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-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-13ray: add rudimentary gamma correctionVito Caputo
color banding has been quite visible, and somewhat expected with a direct conversion from the linear float color space to the 8-bit integral rgb color components. A simple lookup table is used here to non-linearly map the values, table generation is taken from Greg Ward's REAL PIXELS gem in Graphics Gems II.
2019-05-19libs/ray: fix off by one error in prepared objectsVito Caputo
Missed the sentinel, oops
2019-05-18libs/ray: trivial indentation fixupVito Caputo
2018-12-31libs/grid: fix grid_ops_t.taken player typeVito Caputo
Just making things consistent, also dropping unnecessary player assert from submit module. Future libs/grid may explore using the "unassigned" zero player in taken calls for unassigning cells like in simultaneously taken collision scenarios.
2018-12-30libs/grid: add grid cellular automata componentVito Caputo
Prep for adding a new module displaying a cellular automata based on the grid component from a multiplayer game I'm working on.
2018-04-03libs: commit missing Makefile.am filesVito Caputo
Oops! This should have made it into b5bc96, been sitting in my tree.
2018-03-19ray: libize raytracer core, introduces src/libsVito Caputo
This is the first step of breaking out all the core rendering stuffs into reusable libraries and making modules purely compositional, consumers of various included rendering/effects libraries. Expect multiple modules leveraging libray for a variety of scenes and such. Also expect compositions mixing the various libraries for more interesting visuals.
© All Rights Reserved