In the media code, what exactly is the difference between the
global_light_list and the local_light_list? At first I thought the
global_light_list contained all the lights defined at top-level in the
soure (i.e. the lights that affect all objects), and the
local_light_list contained all the lights that only affect the given
object. But if this is the case, why is it the same local_light_list?
When it is simulating several media (associated with different objects)
at once, how does it deal with different objects having different sets
of lights they are affected by?
Maybe my understanding of multiple objects is flawed. As I understand
it, Simulate_Media is called once for each 'segment' of homogenous ray,
(where by segment I mean a length of ray bounded at either end by
entering or leaving a medium), and it passes the sample_media functions
a list of all the media covering this segment, even if the media are
inside different objects. Is this correct or am I completely mixed up?

When POV 4 is released, I hope it is better commented. :~-(
Daniel

-- 
  ,^--^.      ,-----.      Never meddle in the affairs of angry cats,
 ( +  + )-----   ---'      for they are well-armed and quick to bite.
 /  --          )       me> http://surreal.istic.org/ key> 885b170d
|_,-|_/--,_|-\_|  fun> www.google.com/search?q=%22tasteful+inspection%22

Post a reply to this message

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

> When POV 4 is released, I hope it is better commented. :~-(

In article <200### [at] dh286pemcamacuk> , Daniel Hulme
<pho### [at] isticorg>  wrote:
> The comments for Test_Shadow (line 666ish) indicate that Eye_Ray is an
> output from the function: this is clearly incorrect as Eye_Ray is an
> input.
> Would it be more helpful if I instead mailed these 'documentation bug'
> reports to someone or posted them in p.bug-reports?

If you just want to rant about the comments in the source code, please do so
at home, not here.  Finding and reporting bugs or asking specific questions
is fine, however, the rest is just annoying.

As far as you question is concerned, look into the 3.1 source code, it does
not use those caches and is probably easier to understand.  Either way, the
light code will be replaced sooner rather than later anyway, so looking at
the clearer 3.1 code won't hurt much.

    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

> If you just want to rant about the comments in the source code, please
> do so at home, not here.  Finding and reporting bugs or asking
Well, while ranting is a release, I'd rather help to improve them.
Perhaps my question was not clear. What I meant was: as typos in
comments are not really 'bugs', is it reasonable to put them in p.b-r,
or would it be helpful to report them by email to someone in particular,
or would everyone prefer if I just didn't bother? Posting here seemed
the obvious thing to do at first, but I would like a bit of
clarification.

> As far as you question is concerned, look into the 3.1 source code, it
Thanks for the hint, I will look into it.

Daniel

-- 
  ,^--^.      ,-----.      Never meddle in the affairs of angry cats,
 ( +  + )-----   ---'      for they are well-armed and quick to bite.
 /  --          )       me> http://surreal.istic.org/ key> 885b170d
|_,-|_/--,_|-\_|  fun> www.google.com/search?q=%22tasteful+inspection%22

Post a reply to this message

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

> or would it be helpful to report them by email to someone in particular,
> or would everyone prefer if I just didn't bother

Don't bother.  I could make an almost endless list of source code comment
oddities.  There are just so many that accumulated over the decades.  If a
piece of code gets written, the comments are fixed.  Otherwise they will
remain as it would be a pain to fix them all, and nobody will do something
like that for a hobby ;-)

    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

> As far as you question is concerned, look into the 3.1 source code, it
> does not use those caches and is probably easier to understand. 
> Either way, the light code will be replaced sooner rather than later
> anyway, so looking at the clearer 3.1 code won't hurt much.

Yes, you are correct that it is easier to understand. It also doesn't
have lightgroups, so it is easier to see what is going on as a whole.

However, I am still puzzled about update_light_list_entry. In it, about
80% of the way down (I can't give you the exact line number, sorry)
there is a line:
//    if (insert)

Why was this if commented out? It seems to me as if it should not be.
With it left in, if the ray fails the intersection tests above, the
light source is left as inactive. Without it, the light source is always
marked as active, even if it does not affect the ray, and both s0 and s1
are marked as zero.

Having it commented out would seem to me to give the same results but
a performance decrease, so does anyone know why it was done? Does it fix
some problem I haven't thought of?

Thanks again for any help you can give,
Daniel

-- 
  ,^--^.      ,-----.      Never meddle in the affairs of angry cats,
 ( +  + )-----   ---'      for they are well-armed and quick to bite.
 /  --          )       me> http://surreal.istic.org/ key> 885b170d
|_,-|_/--,_|-\_|     http://www.xcom2002.com/doh/index.php?s=04113018oth

Post a reply to this message