Chris Huff <chr### [at] maccom> wrote:
: I would think so...but you still don't have intersection point, 

  AFAIK the sky_sphere works like if it was a sphere of radius 1 with its
center in the source of the ray.
  A "fake" intersection point could be created from this information.

  Of course if this information is used to create a normal vector and thus
shading, the result will not be the expected.
  But why limit it anyways?

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <3a2cca6b@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   AFAIK the sky_sphere works like if it was a sphere of radius 1 with its
> center in the source of the ray.

Actually, the pigment is calculated as if it was on a radius 1 sphere, 
but sky_sphere behaves mostly like a sphere with infinite radius. Since 
it isn't an object, there are some other odd things about it, like it 
can't have a texture, only a pigment, doesn't have an interior, doesn't 
have a surface, etc...it is just an extended "background" feature.


>   A "fake" intersection point could be created from this information.

That's what I said...


>   Of course if this information is used to create a normal vector and thus
> shading, the result will not be the expected.
>   But why limit it anyways?

Why go through a bunch of trouble to get it to partially work, and 
probably slow it down noticeably, when there is already a way to do what 
you want and get correct results? Just put a big hollow sphere, a real 
sphere, around the scene.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Chris Huff <chr### [at] maccom> wrote:
: Just put a big hollow sphere, a real 
: sphere, around the scene.

  Why hollow and not inverted?

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Warp wrote:
> 
> Chris Huff <chr### [at] maccom> wrote:
> : Just put a big hollow sphere, a real
> : sphere, around the scene.
> 
>   Why hollow and not inverted?

He said it just to bother you, Warp :)

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

Ken <tyl### [at] pacbellnet> wrote:
: He said it just to bother you, Warp :)

  Warp, the non-hollow man!

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Paul Wise wrote:
> 
> Vahur Krouverk wrote:
> 
> > Sky sphere is not usual object and its shading
> > calculation lacks number of parameters (most notably normal of surface),
> > which are needed for anisotropic shader.
> 
> Could the normal of the skysphere be considered to be -1 times the ray direction
> ?

One possibility of course is to pass along as much information as
possible in each case: in case of sky sphere find normal and pass it
along (btw, such approach, proposed above, will work only in special
case, generally normals are transformed differently from points or
vectors), etc. But will it be sound solution? In such case shader writer
should know beforehand, which variables are available and which are not
in each particular case. Of course available variables for each type of
non-object could be specified in documentation, but this will be too
implementation-dependent and its use will become cumbersome and awkward.
Additionally, normal is used for lighting calculation, but sky sphere
(and other non-objects) have nothing to do with lighting, they have only
pigment.

Much better solution would be to create other shader type (lets call it
pigment shader).
This shader could be used with such non-objects, it will have clearly
defined subset of built-in variables (e.g. shading point (or better yet,
evaluation point) P, output color Ci, output opacity Oi etc.) and
built-in functions, which are guaranteed to work with this limited set
(e.g. shading and lighting functions have no meaningful implementation
and should be disabled, math and geometric functions could be used).
But such approach will require quite big rewriting and I'm not sure,
whether I want to do this right now (although I'm thinking about
implementing displacement shaders sometimes in future and such work
could become handy in this case, for displacement shaders have limited
set of functionality as well).

Easiest solution for now would is to issue warning, when shader is used
with non-object and shader writer should ensure, that shader will work
correctly. Of course this implies, that it should be documented, which
functions and built-in variables are available and could be used without
problems (from built-in variables only shading (or evaluation) point,
resulting color and opacity are available, possible functions are math
and geometry, etc.).

Post a reply to this message

In article <3a2d03c3@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   Why hollow and not inverted?

So you can put media in it. :-)

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Vahur Krouverk wrote in message <3A2C8EFE.8619FB3F@aetec.ee>...
>P.S. Mark, out of curiosity, what was the reason to try anisotropic
>shader with sky_sphere? Was it attempt to break things or attempt to
>perform something nice? Sky sphere is not usual object and its shading
>calculation lacks number of parameters (most notably normal of surface),
>which are needed for anisotropic shader.

Originally, I was applying a "clouds" shader to the sky_sphere, but after
POV-Man crashed when using it, I tried a few other shaders to see if the
problem was with the specific shader, or with POV-Man, and the anisotropic
shader just happened to be the last one I tested.

--
Mark

"The derivative of sin(2x) is cos(2x)"  - Matt Giwer
"I never said that" - Matt Giwer

Post a reply to this message

Mark Wagner wrote:
> 
> Originally, I was applying a "clouds" shader to the sky_sphere, but after
> POV-Man crashed when using it, I tried a few other shaders to see if the
> problem was with the specific shader, or with POV-Man, and the anisotropic
> shader just happened to be the last one I tested.

Do you mean clouds shader from my homepage? I'm not sure, whether it
will work with sky_sphere even with the fixed version: in order to have
something, that resembles cloud, several spheres (or other objects)
should be used; with one surface it doesn't look like cloud at all.

Post a reply to this message

Vahur Krouverk wrote in message <3A2DE67A.12BC1C37@aetec.ee>...
>Do you mean clouds shader from my homepage? I'm not sure, whether it
>will work with sky_sphere even with the fixed version: in order to have
>something, that resembles cloud, several spheres (or other objects)
>should be used; with one surface it doesn't look like cloud at all.

No, it's one I found on the Internet.  It uses only the evaluation point as
input.
--
Mark

"The derivative of sin(2x) is cos(2x)"  - Matt Giwer
"I never said that" - Matt Giwer

Post a reply to this message