In Trace() in render.cpp (around line 1913, probably a bit higher up as
I have added code) there is a section to test if all contained objects
are hollow by looping around Ray->Interiors thus:
>>>
  if (Ray->Index > -1)
  {
    for (i = 0; i <= Ray->Index; i++)
    {
      if (!Ray->Interiors[i]->hollow)
      {
        all_hollow = false;

        break;
      }
    }
  }
<<<
Would it be OK to move this code a bit further up in the function
(specifically, above Determine_Apparent_Colour())? From what I can see,
it should be fine as all the functions that call Ray_Enter() and
Ray_Exit() in Determine_Apparent_Colour() do so on the spawned ray, not
the original ray, so the data in Interiors should already be valid for
the segment between Ray->Initial and the intersection point. I am not
very confident in this assessment, though, so it would be nice to have
someone who already knows the code confirm or refute my hunch.

On the subject of Ray->Interiors, would this not be better as a linked
list than an array? It seems a bit wasteful to have
MAX_CONTAINED_OBJECTS pointers in every ray, and to move array entries
down when removing an interior from the list (in Ray_Exit()).

Daniel

-- 
A church is more than just timber and stone   .oO( surreal.istic.org )
And freedom is a dark road when you're walking it alone   -Paul Simon,
But the future is now, and it's time to take a stand       'A Church 
So the lost bells of freedom can ring out in my land.      is Burning'

Post a reply to this message

In article <200### [at] dh286pemcamacuk> , Daniel Hulme 
<pho### [at] isticorg>  wrote:

> On the subject of Ray->Interiors, would this not be better as a linked
> list than an array?

Iterating a list is (slightly for each access) slower than iterating an
array.  If the array is small, copying likely does not cost as much as the
overhead introduced by using a linked list.  The smartest thing might well
be to actually have a start index and instead of moving list elements, to
increment the start index instead and only move if really necessary (which
could guaranteed to be never if the array would be used as a ring-buffer).

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message