 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
When a shader is used as the pigment for a sky_sphere, POV-Man for Windows
crashes with an invalid page fault.
Example scene:
sky_sphere{
pigment{
shader{shader_file "aniso.slp"}
}
}
plane{y, -1 pigment{rgb <0,1,0>}}
--
Mark
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mark Wagner wrote:
>
> When a shader is used as the pigment for a sky_sphere, POV-Man for Windows
> crashes with an invalid page fault.
>
Such an idea didn't occurred to me: use shader as pigment for
sky-spehere, but it shouldn't crash anyway. I'll look at it. I intended
to release service version with some other fixes, but now I try to
correct this bug as well and then release version.
> Example scene:
> sky_sphere{
> pigment{
> shader{shader_file "aniso.slp"}
> }
> }
>
> plane{y, -1 pigment{rgb <0,1,0>}}
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mark Wagner wrote:
>
> When a shader is used as the pigment for a sky_sphere, POV-Man for Windows
> crashes with an invalid page fault.
>
As I suspected, the problem was in the fact, that sky_sphere is not
usual object, but something else: in this case intersection information
is not available (NULL pointer is passed instead), but shader relies
heavily on intersection information and uses passed pointer without
checking. This is omission from my part, as there is number of places,
where instead of pointer to intersection NULL pointer is passed along.
First I thought, that I should disable shader use in such cases, as only
information, which is available, is pigment evaluation point and pigment
itself: shader would have very limited use.
But then I imagined, that shader might come in handy even in these cases
and provide possibility to customize sky_sphere, media density etc.
calculation. So I made it work with such semi-objects: warning from
renderer is issued cases:
"shader is used with non-object, intersection information incomplete"
but shading calculation is performed anyway.
(I try to enhance this warning displaying and display it only in such
cases, when information, which is not available, such as normal or uv
coordinates, is really used in shader. But this may be difficult to
implement it in this manner, that all such cases are caught, so perhaps
I stick with easy solution and issue warning just every time).
Hopefully within couple of days new patch will be available.
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.
If first reason was real one, then you succeeded :o) and I failed :o(
On second case, if you have some idea in mind and haven't succeeded in
its implementation, then perhaps you could describe it and i'll try to
help.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
?
--
Bye
Pabs
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3A2C9E68.A926BC2A@student.murdoch.edu.au>, Paul Wise
<p.w### [at] student murdocheduau> wrote:
> Could the normal of the skysphere be considered to be -1 times the ray
> direction?
I would think so...but you still don't have intersection point,
etc...and that information is passed around in one big chunk containing
intersection point, depth, raw normal, perturbed normal, which is why
you can't simply pass the normal. You could probably fake the surface as
direction*MAX_DISTANCE...but it might not be worth it, since a shader
with that faked information probably still won't work as expected...
--
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:
: 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
|
|
| |
| |
|
|
|
|
| |
|
|
