|
 |
On 2026-04-02 4:23 a.m., Mr wrote:
> David Buck <dav### [at] simberon com> wrote:
>> On 2026-03-27 11:51 a.m., Bald Eagle wrote:
>>> Were there things that you've always wanted to implement, but never did?
>>
>> I thought it would be interesting to add octree subdivision to the
>> raytracer. The main raytrace loop goes:
>>
>> For each ray
>> For each object in the scene
>> If the ray intersects the object
>> Collect the intersection point
>> End
>> End
>>
>> Find the closest intersection point and calculate the lighting
>>
>> With an octree, you divide the space into large cubes and subdivide
>> those cubes that contain something. The algorithm, then, becomes
>>
>> For each ray
>> Traverse empty cubes until you find a non-empty one
>> Calculate intersections with the small number of objects in
>> that cube.
>>
>> I always thought that it would dramatically speed up the rendering by
>> eliminating the vast majority of the ray/object intersection calculations.
>
> Does that mean the BSP and BVH are currently not doing this? that would be a
> major bottleneck! (or did you mean you wish you had implemented it yourself?)
>
> https://www.povray.org/documentation/3.7.0/r3_2.html#r3_2_8_6
>
> THANKS for all of this of course ! :-) (we all hope that when you retire you get
> back to more poving!)
>
I like the elegance of an octree solution. I can't say whether it's
better or worse than BSP or BVH. With octrees, however, the ray can be
traced using a simple variation of a line drawing algorithm. It might
even be possible to do it with integer arithmetic until you hit an
object. I simply find it an elegant algorithm and was curious if it
would speed up POV-Ray. It has the same problem as BSP's where you need
to build up the model before you can do the raytracing itself. I just
find it interesting.
Post retirement, I think it's unlikely I'll get back into the POV-Ray
code itself, but I may create software that can create models that
POV-Ray can render.
David Buck
Post a reply to this message
|
|
