|
![](/i/fill.gif) |
In article <3903cb3b@news.povray.org>, "Nathan Kopp" <Nat### [at] Kopp com>
wrote:
> Chris Huff <chr### [at] yahoo com> 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] yahoo com
TAG(Technical Assistance Group) e-mail: chr### [at] tag povray org
Personal Web page: http://chrishuff.dhs.org/
TAG Web page: http://tag.povray.org/
Post a reply to this message
|
![](/i/fill.gif) |