| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
