![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
I tried it exactly the way you described (Color 0 is Red in my image, and I am
sure 0 is the index I want.).
Please view the following post to 'Re: Q: Image-Maps in Layered Textures' by Steve
for the original code that does not work.
Thanks,
Hendrik Iben
Bob Hughes wrote:
> You can't get a transparent palette entry which is set in a image program to
> show up as transparent in POV-Ray unless you use the 'transmit' keyword. Such
> as:
>
> #declare t_image=texture{pigment{
> image_map {gif "yourimage.gif" transmit 0,1} // index #0, transmit 1
> }}
>
> my_texture =
> texture { t_ground }
> texture { t_image }
>
> The once keyword is only for non-tiling. Be certain of your palette index
> number/color relation too. Black might not always be 0.
>
> Bob
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
I think you may have found a bug. 'transmit' doesn't work right but 'filter'
does okay.
Bob
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Btw, I tried this with version 3.02.watcom.win32, 3.1g.watcom.win32, and also
MegaPov 0.4. Only MegaPov will render correctly when 'transmit' is used,
'filter' works okay in all 3 versions. I thought maybe it might be
'max_trace_level' dependant but it doesn't help if it's increased to 50 instead
of leaving at default 5. So something got fixed in Nathan's patched pov.
Bob
"Bob Hughes" <omn### [at] hotmail com?subject=PoV-News:> wrote in message
news:38b93247@news.povray.org...
| I think you may have found a bug. 'transmit' doesn't work right but 'filter'
| does okay.
|
| Bob
|
|
|
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Yes, I found out the same thing just before I read this post... :-)
I didn't try filter in the beginning because I thought this would let only the
red component of the ground through,
as Color 0 is Red...
I don't think it is a bug because when I took a very close look I could see the
texture below in the dark... it seems to be scaled down in color or something,
but in the end it's just too dark...
I had the same effect when I just used a simple checker :
texture {
pigment {
checker color rgbt <0,0,1,0>, color rgbt <1,1,1,1>
}
}
But filter works and I'm happy again :-)
Thanks,
Hendrik Iben
Bob Hughes wrote:
> I think you may have found a bug. 'transmit' doesn't work right but 'filter'
> does okay.
>
> Bob
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Well, I guess I should get that patch if I want to make more scenes like the one
I'm creating now...
But this problem did at least restore my faith in myself and my abilities so this
experience was not that bad at all...
;-)
Thanks again for the information,
Hendrik Iben
Bob Hughes wrote:
> Btw, I tried this with version 3.02.watcom.win32, 3.1g.watcom.win32, and also
> MegaPov 0.4. Only MegaPov will render correctly when 'transmit' is used,
> 'filter' works okay in all 3 versions. I thought maybe it might be
> 'max_trace_level' dependant but it doesn't help if it's increased to 50 instead
> of leaving at default 5. So something got fixed in Nathan's patched pov.
>
> Bob
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Yep, I just realized it was actually there too, not blacked out and gone
entirely, just very dark. I turned up the color of the light source to 10.
Something's wrong in the official versions though, I just couldn't say not
knowing anything about the source code workings. Maybe Nathan has an idea.
At the beginning I simply thought the problem might be the layering over a
layered texture, which I expected would make an error show up. Maybe that's
still something to do with it though.
Bob
"Hendrik Iben" <Hen### [at] bigfoot de> wrote in message
news:38B93739.57A3562E@bigfoot.de...
| Yes, I found out the same thing just before I read this post... :-)
| I didn't try filter in the beginning because I thought this would let only the
| red component of the ground through,
| as Color 0 is Red...
| I don't think it is a bug because when I took a very close look I could see
the
| texture below in the dark... it seems to be scaled down in color or something,
| but in the end it's just too dark...
|
| I had the same effect when I just used a simple checker :
| texture {
| pigment {
| checker color rgbt <0,0,1,0>, color rgbt <1,1,1,1>
| }
| }
|
| But filter works and I'm happy again :-)
|
| Thanks,
| Hendrik Iben
|
| Bob Hughes wrote:
|
| > I think you may have found a bug. 'transmit' doesn't work right but
'filter'
| > does okay.
| >
| > Bob
|
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Bob Hughes wrote:
>
> Btw, I tried this with version 3.02.watcom.win32, 3.1g.watcom.win32, and also
> MegaPov 0.4. Only MegaPov will render correctly when 'transmit' is used,
> 'filter' works okay in all 3 versions. I thought maybe it might be
> 'max_trace_level' dependant but it doesn't help if it's increased to 50 instead
> of leaving at default 5. So something got fixed in Nathan's patched pov.
Nathan changed the way that layered filtered textures behave in MegaPov
- been public knowlege for some time now.
--
Ken Tyler - 1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Bob Hughes wrote:
>
> Yep, I just realized it was actually there too, not blacked out and gone
> entirely, just very dark. I turned up the color of the light source to 10.
> Something's wrong in the official versions though, I just couldn't say not
> knowing anything about the source code workings. Maybe Nathan has an idea.
> At the beginning I simply thought the problem might be the layering over a
> layered texture, which I expected would make an error show up. Maybe that's
> still something to do with it though.
In the official version layered textures that use filter or transmit
react the same i.e. they both default to the behavior of filter. In
MegaPov Nathan changed this so that transmit works "correctly" or so
he claims. It's not really a bug as much as it is a dissagreement as
to what the correct behavior should be where layered textures are
concerned. I do not know at this point if this change will be reflected
in POV-Ray v3. or not. It will definately break a lot of pre v3.5
textures if it is implememnted though the #version directive can be
used to compensate for this.
--
Ken Tyler - 1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <38B93A53.83D12556@pacbell.net>, lin### [at] povray org
wrote:
> In the official version layered textures that use filter or transmit
> react the same i.e. they both default to the behavior of filter. In
> MegaPov Nathan changed this so that transmit works "correctly" or so
> he claims. It's not really a bug as much as it is a dissagreement as
> to what the correct behavior should be where layered textures are
> concerned. I do not know at this point if this change will be reflected
> in POV-Ray v3. or not. It will definately break a lot of pre v3.5
> textures if it is implememnted though the #version directive can be
> used to compensate for this.
Actually, it is filter that acts like transmit in layered textures in
the official version. MegaPOV fixes it so filter acts like filter and
transmit like transmit(makes more sense, doesn't it?). Since it is
documented in the manual, it can't really be considered a bug, so I call
it a "documented mis-feature". :-)
And converting older textures is actually quite easy: just set the
filter in the upper layers to 0 and add the value that was there to the
transmit value. This should give the same appearance as it had in the
official version. Or you could use the #version directive...
--
Chris Huff
e-mail: chr### [at] yahoo com
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
No, that can't be the reasoning for the darkness increase. Something else must
be going on. I'd have expected a problem with filter and because I knew about
Nathan's changes I wouldn't have thought transmit would be the thing that is
different from the official versions. Even if you were to consider transmit and
filter behaviour to be switched in the official versions (bear with me please, I
know it isn't) to explain why the darkening occurs I'd still think filtering
should not be such a tremendous change just because one more layer is added.
Seems to be related to layering onto a layered texture that's doing it.
I tested this ought again and if a layers of image maps is declared first then
put in as the base layer of the plane texturing then it's fine, no problems.
However if layering of the usual pigments (pattern, no pattern) is declared and
added in as the base texture to the plane then it breaks down.
Something must be wrong (or never meant to be) in official then, but check for
yourselves. Here's what I was doing:
// #version 3.1;
// unofficial MegaPov 0.4;
global_settings {
max_trace_level 5
}
#include "colors.inc"
#include "stones.inc"
light_source { 10*y color rgb 1}
camera {
location <0,9,9>
angle 67
look_at 0
}
#declare Layer1=
texture { // base
pigment {rgb <1,1,1>
// image_map {gif "test.gif" transmit 0, 1}
// translate -.5 scale 6 rotate 90*x
}
}
texture {
pigment {rgbf <0,1,0,1>
// image_map {gif "test.gif" transmit 0, 1}
// translate 0 scale 6 rotate 90*x rotate 90*y
}
}
plane {y,0
texture {Layer1 // using this instead of the Stone17 texture
// pigment {image_map {gif "test.gif" transmit 0, 1}
// translate 0 scale 6 rotate 90*x rotate 90*y}
// T_Stone17
}
texture {
pigment {image_map {gif "test.gif" transmit 0, 1}
translate -.5 scale 6 rotate 90*x}
}
}
Bob
"Chris Huff" <chr### [at] yahoo com> wrote in message
news:chrishuff_99-6D5671.10202927022000@news.povray.org...
| In article <38B93A53.83D12556@pacbell.net>, lin### [at] povray org
| wrote:
|
| > In the official version layered textures that use filter or transmit
| > react the same i.e. they both default to the behavior of filter. In
| > MegaPov Nathan changed this so that transmit works "correctly" or so
| > he claims. It's not really a bug as much as it is a dissagreement as
| > to what the correct behavior should be where layered textures are
| > concerned. I do not know at this point if this change will be reflected
| > in POV-Ray v3. or not. It will definately break a lot of pre v3.5
| > textures if it is implememnted though the #version directive can be
| > used to compensate for this.
|
| Actually, it is filter that acts like transmit in layered textures in
| the official version. MegaPOV fixes it so filter acts like filter and
| transmit like transmit(makes more sense, doesn't it?). Since it is
| documented in the manual, it can't really be considered a bug, so I call
| it a "documented mis-feature". :-)
|
| And converting older textures is actually quite easy: just set the
| filter in the upper layers to 0 and add the value that was there to the
| transmit value. This should give the same appearance as it had in the
| official version. Or you could use the #version directive...
|
| --
| Chris Huff
| e-mail: chr### [at] yahoo com
| Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |