|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] studentmurdocheduau> 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
|
|
| |
| |
|
|
|
|
| |
|
|