 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
tahoma wrote:
>
> E.g. the modulation of an image_map color with a constant color:
> pigment = <image_map[u,v].red * color.red, image_map[u,v].green *
> color.green, image_map[u,v].blue * color.blue>
If you want to change the colors in an image map this should be done
with an imaging program. Mike also explained how you can do this
internally (which is a good example for how POV-SDL can be used to do
things it was never intended for).
> Furthermore i wondered why it is possible to define an ambient "reflection"
> as rgb but a diffuse and specular reflection just as scalar.
The ambient finish component in POV-Ray is a color, diffuse and specular
are scalar. This is explained in the manual. So you can use:
finish {
ambient <0.1, 0.2, 0.3>
}
to 'modulate' the ambient finish. Note the color of specular highlights
can be influenced with the 'metallic' keyword. Apart from that you can
also use layered textures to have more detailed control.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 03 May. 2005 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
tahoma wrote:
> I tried it and it works great but only with non uv mapped image_maps. When
> using "uv_mapping" povray complains with "The 'uv_mapping' pattern cannot
> be used as part of a pigment function!".
You can apply uv-mapping to the average pigment without problems.
> Is there another way or do i have to wait for a new povray version? Is this
> a features already put on the roadmap of development?
No (at least not in the form you suggested).
> This little feature seems so easy to implement and i wonder if nobody else
> needed it in the past 10 years :o
The motivation for adding/changing something in POV-Ray is not if it is
easy to implement.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 03 May. 2005 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 11 May 2005 18:59:41 +0100, Mike Williams
<nos### [at] econym demoncouk> wrote:
> Wasn't it tahoma who wrote:
>> Mike Williams <nos### [at] econymdemoncouk> wrote:
>>> Wasn't it tahoma who wrote:
>>> >I started with povray some days ago to convert some realtime scenes
to
>>> >povray files. After reading the documentation again and again i
>>> wondered if
>>> >it would be possible to define materials or textures just like in
>>> OpenGL,
>>> >3dsMax and so on.
>>> >
>>> >E.g. the modulation of an image_map color with a constant color:
>>> >pigment = <image_map[u,v].red * color.red, image_map[u,v].green *
>>> >color.green, image_map[u,v].blue * color.blue>
>>>
>>> This can be achieved with pigment functions, but it's a bit tricky.
>>>
>>> Let there be a colour "C".
>>>
>>> We first have to split the colour into its components, because the
>>> parser
>>> doesn't like the syntax "C.red" in the next stage.
>>>
>>> #declare Cr = C.red;
>>> #declare Cg = C.green;
>>> #declare Cb = C.blue;
>>>
>>> Now define a pigment function from the image_map.
>>>
>>> #declare IM = function {pigment {image_map {jpeg "tex.jpg" interpo
late
>>> 2}}}
>>>
>>> Then calculate three pigments that will be the components of the
>>> modulated
>>> pigment. In this case the calculation is IM.red * C.red, which gives
>>> you the
>>> pattern of the pigment. The pattern is then colour_mapped to the ran
ge
>>> black-
>>> to-red (otherwise it ends up greyscale).
>>>
>>> #declare R = pigment {function {IM(x,y,z).red * Cr}
>>> colour_map {[0 rgb 0][1 rgb <1,0,0>]}}
>>> #declare G = pigment {function {IM(x,y,z).green * Cg}
>>> colour_map {[0 rgb 0][1 rgb <0,1,0>]}}
>>> #declare B = pigment {function {IM(x,y,z).blue * Cb}
>>> colour_map {[0 rgb 0][1 rgb <0,0,1>]}}
>>>
>>> Then assemble the three components using an average pigment_map
>>>
>>> sphere {0,1
>>> pigment {average
>>> pigment_map {
>>> [1 R]
>>> [1 G]
>>> [1 B]
>>> }
>>> }
>>> }
>>
>> Whoa, pretty nice :)
>>
>> I tried it and it works great but only with non uv mapped image_maps.
>> When
>> using "uv_mapping" povray complains with "The 'uv_mapping' pattern
>> cannot
>> be used as part of a pigment function!". Nevertheless, I never was so
>> close
>> to the solution, thank you so far.
>
> You're probably just putting the "uv_mapping" keyword in the wrong
> place. Don't do the uv_mapping when you define the pigment functions,
do
> it when you apply the complete texture to the object.
>
> sphere {0,1
> texture {uv_mapping
> pigment {average
> pigment_map {
> [1 R]
> [1 G]
> [1 B]
> }
> }
> }
> }
That did the trick. Thanks.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> I tried it and it works great but only with non uv mapped image_maps.
>> When
>> using "uv_mapping" povray complains with "The 'uv_mapping' pattern
>> cannot
>> be used as part of a pigment function!".
>
> You can apply uv-mapping to the average pigment without problems.
>
>> Is there another way or do i have to wait for a new povray version? I
s
>> this
>> a features already put on the roadmap of development?
>
> No (at least not in the form you suggested).
>
>> This little feature seems so easy to implement and i wonder if nobody
>> else
>> needed it in the past 10 years :o
>
> The motivation for adding/changing something in POV-Ray is not if it i
s
> easy to implement.
Ok, it was just a thought about this problem because it is important for
me
at the moment. I know i am just a sandcorn in the desert :)
I come from the realtime part of the rendering world and all kind of 3D
API's,
renderers and so on i worked with use that kind of material model:
define a diffuse color and modulate it by a diffuse image map or
procedural map
optionally, define a specular color and modulate it by a specular image
map
and so on.
So i would like to know what is the whole concept behind the povray
material
model to avoid such questions.
If you have some links, documents or even the answer, i'm interested.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> #declare R = pigment {function {IM(x,y,z).red * Cr}
> colour_map {[0 rgb 0][1 rgb <1,0,0>]}}
> #declare G = pigment {function {IM(x,y,z).green * Cg}
> colour_map {[0 rgb 0][1 rgb <0,1,0>]}}
> #declare B = pigment {function {IM(x,y,z).blue * Cb}
> colour_map {[0 rgb 0][1 rgb <0,0,1>]}}
>
> Then assemble the three components using an average pigment_map
>
> sphere {0,1
> pigment {average
> pigment_map {
> [1 R]
> [1 G]
> [1 B]
> }
> }
> }
The assembled colors are just 1/3 of the intensity as the original
one's. I replaced Cr/Cg/Cb by 1/1/1. The average function
calculates (1*<1,0,0> + 1*<0,1,0> + 1*<0,0,1>)/3 = <1/3,1/3,1/3>.
If i could use 'add' instead of 'average' of disable the division
by the weight sum ... any ideas?
I think, i understand the colour_map now :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wasn't it tahoma who wrote:
>> #declare R = pigment {function {IM(x,y,z).red * Cr}
>> colour_map {[0 rgb 0][1 rgb <1,0,0>]}}
>> #declare G = pigment {function {IM(x,y,z).green * Cg}
>> colour_map {[0 rgb 0][1 rgb <0,1,0>]}}
>> #declare B = pigment {function {IM(x,y,z).blue * Cb}
>> colour_map {[0 rgb 0][1 rgb <0,0,1>]}}
>>
>> Then assemble the three components using an average pigment_map
>>
>> sphere {0,1
>> pigment {average
>> pigment_map {
>> [1 R]
>> [1 G]
>> [1 B]
>> }
>> }
>> }
>
>The assembled colors are just 1/3 of the intensity as the original
>one's. I replaced Cr/Cg/Cb by 1/1/1. The average function
>calculates (1*<1,0,0> + 1*<0,1,0> + 1*<0,0,1>)/3 = <1/3,1/3,1/3>.
>If i could use 'add' instead of 'average' of disable the division
>by the weight sum ... any ideas?
A safe place to multiply by 3 is in the colour_map, so that it
calculates (1*<3,0,0> + 1*<0,3,0> + 1*<0,0,3>)/3.
#declare R = pigment {function {IM(x,y,z).red * Cr}
colour_map {[0 rgb 0][1 rgb <3,0,0>]}}
#declare G = pigment {function {IM(x,y,z).green * Cg}
colour_map {[0 rgb 0][1 rgb <0,3,0>]}}
#declare B = pigment {function {IM(x,y,z).blue * Cb}
colour_map {[0 rgb 0][1 rgb <0,0,3>]}}
(If you multiply Cr, Cb and Cg by 3 it almost works, but, since it's
used in the pattern calculation, when the pattern calculation gives 1.0
it gets truncated down to 0.0 which is not what we want.
--
Mike Williams
Gentleman of Leisure
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I got it. After some time of twaeking i come up with my first macro in
povray :)
Here it is:
#macro pigment_from_image_map(TextureName, r,g,b)
#local imageMap =
function {
pigment {
image_map {
jpeg TextureName
transmit all 0
interpolate 2
}
}
}
#local R = pigment {
function {imageMap(x,y,z).red*r}
colour_map {
[0 rgb 0]
[1 rgb <3,0,0>]
}
}
#local G = pigment {
function {imageMap(x,y,z).green*g}
colour_map {
[0 rgb 0]
[1 rgb <0,3,0>]
}
}
#local B = pigment {
function {imageMap(x,y,z).blue*b}
colour_map {
[0 rgb 0]
[1 rgb <0,0,3>]
}
}
pigment {
uv_mapping
average
pigment_map {
[1 R]
[1 G]
[1 B]
}
}
#end
The usage is quite nice for my purpose:
#declare MY_TEXTURE =
texture {
pigment_from_image_map("texture01.jpg",1,0,0)
finish {
diffuse 1 ambient 0.2
}
}
But when i want to use another imageformat (e.g. png), how can i send it
as a parameter to the macro?
Does anyone from the experienced users has some advices to make it even
more flexible?
Regards,
Jan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> Loki <nomail@nomail> wrote:
> > I know what you're getting at. In fact I suggested a similar change in
> > implementation a while ago and was roundly accused of trolling for
> > mentioning it.
>
> People don't get accused of trolling because of posting a suggestion.
> People get accused of trolling if they use a certain tone of voice, a
> certain attitude. It's not what is said but how.
> Please don't twist the facts.
>
> --
> - Warp
Oh please. I got accused of trolling by numerous people in one of my first
ever posts here for nothing more than asking basically the same thing as
above: why are properties like 'specular' and 'diffuse' limited to a
non-mappable scalar value? It's a simple enough question and I had good
reason to ask it.
L
-
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> But when i want to use another imageformat (e.g. png), how can i send it
> as a parameter to the macro?
> Does anyone from the experienced users has some advices to make it even
> more flexible?
You could use some of the string-functionality to clip off everything until
the "." in the filename. Note that you can't just clip to the last 3, as
some might save with "JPEG" instead of plain, 3-digit "JPG". Then again, you
could tell that someone did that if the remaining 3 digits showed "PEG"...
Anyways, once you have the last three digits, use
strcmp(One_String,Another_String) and check if they're equal (if they are,
strcmp returns the value 0). Use the proper format according to the results.
(e.g. #if (strcmp(TestThis,"png")) png #end).
Of course, this won't work when somebody doesn't supply an ending for their
images, but shame on those that do that! :-)
--
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
tahoma wrote:
>
> But when i want to use another imageformat (e.g. png), how can i send it
> as a parameter to the macro?
For a convenient way to do this have a look at the
IC_ImageFName_Function() macro in IsoCSG:
http://www.tu-bs.de/%7Ey0013390/pov/ic/index.html
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 03 May. 2005 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
