"jr" <cre### [at] gmailcom> wrote:
> > Your after the textures (and lighting... +AM3 best bet for that) at the
> > edges - others have warned in posts about the complications thereof.
> > What eval_pigment does is what can somewhat simply and reliably be done.
> > For the rest angles of rays camera, shadow, slightly adjacent rays, etc
> > play a part in the resultant pixel color.
> yes, for my purposes, 'eval_pigment' doesn't do. as I wrote in reply to BE, a
> variant of 'trace' would be nice; perhaps reversing the normal and use it as a
> camera ray to get the colour. it would be useful, even given the provisos you
> mention, because it would work on an in-situ object as is.
Well, we've played with locating 3D points in space based on 2D screen
coordinates, and I and at least one other have played with analyzing the color
maps of existing images - so you could render your frames, and then use
eval_pigment to scan the final rendered/lit/textured/shadowed, etc result in a
2-stage process using the rendered frames as image_maps in Step 2.
So perhaps you could use trace in Step 1 to compile a list of pixels to analyze
and store, and then use eval_pigment in Step 2 to only look at those pixels in
an image map of the rendered frames...
With regard to the slicing problem:
I'm wondering if you can use/abuse the orthographic camera itself to get what
I came across this when Ton posted a link to FL's site.
Maybe with some sort of no_shadow or double_illuminate keywords, you could get
it to light the surface of that interior "slice".
Post a reply to this message