summaryrefslogtreecommitdiff
path: root/src/libs/ray/ray_render.c
AgeCommit message (Collapse)Author
2022-04-27til_fb: til_fb_fragment_t.{pitch,stride} uint32_t unitsVito Caputo
Originally it seemed sensible to make these units of bytes, for flexibility reasons. But it's advantageous for everything to be able to assume pixels are always 4-byte/32-bit aligned. Having the stride/pitch be in bytes of units made it theoretically possible to produce unaligned rows of pixels, which would break that assumption. I don't think anything was ever actually producing such things, and I've added some asserts to the {sdl,drm}_fb.c page acquisition code to go fatal on such pages. This change required going through all the modules and get rid of their uint32_t vs. void* dances and other such 1-byte vs. 4-byte scaling arithmetic. Code is simpler now, and probably faster in some cases. And now allows future work to just assume things cna always occur 4-bytes at a time without concern for unaligned accesses.
2021-10-01*: librototiller->libtilVito Caputo
Largely mechanical rename of librototiller -> libtil, but introducing a til_ prefix to all librototiller (now libtil) functions and types where a rototiller prefix was absent. This is just a step towards a more libized librototiller, and til is just a nicer to type/read prefix than rototiller_.
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.
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-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