| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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.
|
|
Trivial optimization eliminates some instructions from the hot path,
no need to maintain a separate index from the current object pointer.
|
|
Previously every fb_fragment_t (and thus thread) was constructing
its own ray_camera_frame_t view into the scene, duplicating some
work.
Instead introduce ray_camera_fragment_t to encapsulate the truly
per-fragment state and make ray_scene_render_fragment() operate
on just this stuff with a reference to a shared
ray_camera_frame_t prepared once per-frame.
Some minor ray_camera.c cleanups sneak in as well (prefer multiply
instead of divide, whitespace cleanups...)
|
|
ray:object intersection coordinates were incorrectly being computed
relative to the ray origin using a subtraction instead of addition, a
silly mistake with surprisingly acceptable results. Those results
were a result of other minor complementary mistakes compensating to
produce reasonable looking results.
In the course of experimenting with an acceleration data structure it
became very apparent that 3d space traversal vectors were not behaving
as intended, leading to review and correction of this code.
|
|
For now, a simple cpu multiplier of 64 is used.
fb_fragment_t needs a tiling fragment divider added...
|
|
To enable prepare to precompute aspects of primary rays which all have a
common origin at the camera, bring the camera to ray_object*_prepare() and
bring the depth to ray_object*_intersects_ray() for primary ray detection.
This is only scaffolding, functionally unchanged.
|
|
This may need to be undone in the future when more sophisticated lights,
like area lights, are implemented. For now I can avoid polluting the
objects list with the lights by strictly separating them.
|
|
Just embed a _prepared struct in the object where precomputed stuff can be
cached. Gets called once before rendering, which ends up calling the
object-specific ray_object_$type_prepare() methods per object.
|
|
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.
|
|
Now that rototiller is generally threaded when a prepare_frame() method is
supplied, and modules/ray has been updated accordingly, discard the now
redundant ray-specific threading code and related stuff.
|
|
The ray tracer was already threaded, so this required little change other
than making some state global like the previous commits, and calling the
underlying non-threaded single-fragment scene renderer function.
A future commit will discard the now vestigial ray_threads related code.
|
|
Adding more context to the name in anticipation of adding a prepare_frame()
method to the module struct.
|
|
Make consistent with the source directory structure naming.
|
|
The highlight on the little green sphere was white-washing
the entire thing due to its high specular reflection value.
This produces more reasonable results...
|
|
Was a constant at 20, this allows it to be specified per-object.
|
|
Make spheres a little more diverse in terms of specular/diffusion,
and minor tweak to the plane color.
|
|
|
|
Make the camera orbit around the origin at a varying radius, with kept aimed
facing the origin, with some vertical sweep+tilt thrown in.
|
|
We should only consider dot products > 0 as intersected, or >= something
very close to 0 (epsilon).
As-is resulted in planes moving with camera movement along the plane normal
axis.
Also fixes plane distance to be non-negative in the current scene.
|
|
Originally I only implemented pitch->yaw->roll, and being new to all this
didn't fully appreciate the limitation that resulted in.
This adds all six permutations of pitch/yaw/roll, the scene must specify
the desired order when setting up the camera with the euler angles, see
the enum in ray_euler.h.
|
|
Restoring some organizational sanity since adopting autotools.
|
