In article <3903cb3b@news.povray.org>, "Nathan Kopp" <Nat### [at] Koppcom> 
wrote:

> Chris Huff <chr### [at] yahoocom> wrote...
> >   DBL Depth;
> >     The distance the ray went before it hit anything, I guess.
> 
> yes.  Currently if the ray hits a clear object, it will give the 
> distance to the clear object.  This could be changed so that it 
> returns the distance to the first opaque object that is hit (the code 
> exists to allow that, which could be useful for media container 
> objects).

Hmm, I think both could be useful...though maybe there should be two 
versions: one which is the distance to the first object with 
filter/transmit != 1 or with an ior or interior attenuation(these two 
conditions should avoid bumping into media containers), the second would 
be the distance to the first opaque object.


> >   int Object;
> >     An index for the first object hit?
> 
> Currently not fully implemented.  The goal is to eventually allow the 
> user to specify an index for an object, like this:
> ...
> This object_glow effect would then produce a green glow around the 
> object with index 12.  (Of course, you wouldn't be able to 'see' the 
> object through any other object (such as a clear media container), 
> since the post-processing buffer would contain the index to the 
> media-container object instead of the object that was beyond it.

Hmm, it would be nice to have this use the "label" feature, having a new 
"index" feature seems to make for a total of 3 different ways to specify 
an object. The labels could probably be represented internally as an 
index, though...but I have another idea:
Why not just make this an object pointer? You could add some 
post_process flags to the object, maybe including an ID number(or a 
string, light groups style), and having the pointer to the object 
accessible could also come in handy. It would point to the object at 
Depth, not necessarily the first object.


> All of these values currently suffer from the fact that they are not 
> anti-aliased.  Please note that while it would be relatively easy to 
> simply anti-alias the raw values that are stored, it may not produce 
> the desired results.  (I do hope to test that eventually, to see if 
> it would work.)

Again, it could be nice to have anti-aliased as well as non anti-aliased 
versions, although that would double the memory usage...maybe just 
include code that could do that if it is needed in the future, and 
comment it out for now.

-- 
Christopher James Huff - Personal e-mail: chr### [at] yahoocom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://chrishuff.dhs.org/
TAG Web page: http://tag.povray.org/

Post a reply to this message