POV-Ray : Newsgroups : povray.bugreports : sphere slicing problem : Re: sphere slicing problem Server Time
19 Oct 2021 12:52:12 EDT (-0400)
  Re: sphere slicing problem  
From: Bald Eagle
Date: 15 Oct 2019 14:45:00
Message: <web.5da6133b401c58094eec112d0@news.povray.org>
"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
you want.
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

Copyright 2003-2021 Persistence of Vision Raytracer Pty. Ltd.