 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
HDRI reflections go horribly wrong when I render with Alpha output, in
MegaPOV. The HDRI image has a no_image tag on it and I'm rendering with
saved radiosity data. Is this a known issue? Are there workarounds or
fixes that I should know about?
Skip
Post a reply to this message
Attachments:
Download 'eye.jpg' (129 KB)
Preview of image 'eye.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> HDRI reflections go horribly wrong when I render with Alpha output, in
> MegaPOV. The HDRI image has a no_image tag on it and I'm rendering with
> saved radiosity data. Is this a known issue? Are there workarounds or
> fixes that I should know about?
It's been pointed out by myself and at least a couple other people in the
past. The workaround is to use POV-Ray 3.5, but that's probably not an
option if you're using HDRI... =\
Still no word from the developers on this issue, unless I've missed it. I
took a brief look at the source code in 3.5 and 3.6 and didn't see any
differences in the places that I would have thought were relevant.
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Take alpha channel from bad image and add to good image using GIMP or
Photoshop?
On Thu, 17 Mar 2005 22:55:58 -0600, Skip Talbot <Ski### [at] aol com> wrote:
> HDRI reflections go horribly wrong when I render with Alpha output, in
> MegaPOV. The HDRI image has a no_image tag on it and I'm rendering with
> saved radiosity data. Is this a known issue? Are there workarounds or
> fixes that I should know about?
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Daniel S. Matthews" <dan### [at] 3-enet> wrote in message
news:ops### [at] beastiemshomenet...
> Take alpha channel from bad image and add to good image using GIMP or
> Photoshop?
won't do. With alpha-output, the background is transparent, so anti-aliasing
will work on any background you put behind it. With your combined method,
anti-aliased pixels will be a blend of the background color (probably black) and
the background-color, resulting in an annoying black (or other colored) edge
around your scene.
cu!
--
camera{location-z*3}#macro G(b,e)b+(e-b)*(C/50)#end#macro L(b,e,k,l)#local C=0
;#while(C<50)sphere{G(b,e),.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1
;#end#end L(y-x,y,x,x+y)L(y,-x-y,x+y,y)L(-x-y,-y,y,y+z)L(-y,y,y+z,x+y)L(0,x+y,
<.5,1,.5>,x)L(0,x-y,<.5,1,.5>,x) // ZK http://www.povplace.be.tf
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Slime wrote:
>
> It's been pointed out by myself and at least a couple other people in the
> past. The workaround is to use POV-Ray 3.5, but that's probably not an
> option if you're using HDRI... =\
>
> Still no word from the developers on this issue, unless I've missed it. I
> took a brief look at the source code in 3.5 and 3.6 and didn't see any
> differences in the places that I would have thought were relevant.
You mean this is not a MegaPOV problem but also exists in official POV-Ray?
In any case could you point me to where the problem is clearly described
including a minimal test scene?
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 27 Feb. 2005 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> You mean this is not a MegaPOV problem but also exists in official
POV-Ray?
Yes.
> In any case could you point me to where the problem is clearly described
> including a minimal test scene?
The minimal test scene would be any object with a bright pigment (rgb
<1,2,3> for instance) plus a light source. I believe the problem is that
POV-Ray is "normalizing" the colors before outputting them; that is,
dividing every color by its brightest component if any component is greater
than 1.
I think the last message to talk about this was "Problem with option +ua" in
this group on January 11, and my response to that message referenced two
earlier messages: "alpha output color problem" on 1/1/05, and "possible
bug?" on 11/28/04. Or just search for messages from me in this group
containing the word "alpha."
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Slime wrote:
>
> I think the last message to talk about this was "Problem with option +ua" in
> this group on January 11, and my response to that message referenced two
> earlier messages: "alpha output color problem" on 1/1/05, and "possible
> bug?" on 11/28/04. Or just search for messages from me in this group
> containing the word "alpha."
Thanks, the sample scene from Nicolas was very useful. I am not yet
completely sure what is the best solution but the source of the problem
is identified.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 27 Feb. 2005 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Thanks, the sample scene from Nicolas was very useful. I am not yet
> completely sure what is the best solution but the source of the problem
> is identified.
Noticed you posted a bug report in povray.bugreports. I'm just curious why
you think that Compensate_For_Alpha_AA is the source of the problem? I had
also suspected that it was the source, but then I noticed that it didn't
change from POV-Ray 3.5 to 3.6.
Do you think that it worked wrong in 3.5 also, but it never caused a problem
because color clipping occured earlier in the process?
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Slime schrieb:
>
> > Thanks, the sample scene from Nicolas was very useful. I am not yet
> > completely sure what is the best solution but the source of the problem
> > is identified.
>
> Noticed you posted a bug report in povray.bugreports. I'm just curious why
> you think that Compensate_For_Alpha_AA is the source of the problem?
I tested it...
> I had
> also suspected that it was the source, but then I noticed that it didn't
> change from POV-Ray 3.5 to 3.6.
>
> Do you think that it worked wrong in 3.5 also, but it never caused a problem
> because color clipping occured earlier in the process?
What's done in Compensate_For_Alpha_AA() is not really accurate
scientific method and therefore it is not working properly for all kind
of input values. It is not yet decided what will ultimately be the
solution but of course there will be one.
-- Christoph
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I tested it...
Ah. How clever of you. =)
> What's done in Compensate_For_Alpha_AA() is not really accurate
> scientific method and therefore it is not working properly for all kind
> of input values. It is not yet decided what will ultimately be the
> solution but of course there will be one.
It seems to me that the correct thing to do is (a) treat the background as
rgb <0,0,0> (which I believe is already done) and (b) at the end, divide the
color by one minus the amount of transparency (if zero then just leave the
color as is). Are there cases where that doesn't work? The hardest thing, I
would think, is determining what the transparency value really is in the
case of things like emission media, but that seems to be handled already.
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
