POV-Ray : Newsgroups : povray.unofficial.patches : POV-Man sky_sphere problem : Re: POV-Man sky_sphere problem Server Time
2 Sep 2024 02:14:35 EDT (-0400)
  Re: POV-Man sky_sphere problem  
From: Vahur Krouverk
Date: 5 Dec 2000 10:38:16
Message: <3A2D0C66.C0BB0DDB@aetec.ee>
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

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