rototiller/.git - Collection of software-rendered graphics hacks supporting libdrm and SDL2

Age	Commit message (Collapse)	Author
2018-02-28	ray: implement distance-based light brightness	Vito Caputo

2017-12-23	ray: constify input scene and camera parameters	Vito Caputo
	also const the ray_euler_t basis
2017-12-23	ray: split object render from object description	Vito Caputo
	This moves the per-object _prepared state into ray_render_object_$type structs with all the rendering-related object methods switched to operate on the new render structs. Since the current rendering code just makes all these assumptions about light objects being point lights, I've just dropped all the stuff associated with rendering light objects for now. I think it will be refactored a bit later on when the rendering code stops hard-coding the point light stuff. These changes open up the possibility of constifying the scene and constituent objects, now that rendering doesn't shove the prepared state into the embedded _prepared object substructs.
2017-12-10	ray: split scene data from render state	Vito Caputo
	This introduces ray_render_t, and ray_render.[ch]. The _prepared member of ray_scene_t has been moved to ray_render_t, and the other _prepared members (e.g. objects) will follow. Up until now I've just been sticking the precomputed state under _prepared members of their associated structures, and simply using convention to enforce anything resembling an api boundary. It's been convenient without being inefficient, but I'd like to move the ray code into more of a reusable library and this wart needs to be addressed. The render state is also where any spatial indexes will be built and maintained, another thing I've been experimenting with. Note most of the churn here is just renaming ray_scene.c to ray_render.c. A nearly global s/ray_scene/ray_render/ has occurred, now that ray_scene_t really only serves as glue to bind objects, lights, and scene-global properties into a cohesive unit.