news:e5g2dus0aba0hkpnr001t2eojq9nap68de@4ax.com...
> On Thu, 02 May 2002 10:31:05 -0300, Valdemir Carrara <val### [at] deminpebr> wrote:
> > Hi,
>
> >1 - I'd like to see the "tiles" keyword back to Pov
> >    textures, but with the sense of tiles and not the
> >    sense of checkboard. Tiles are a mixture of checboard
> >    with brick. It has a mortar, and resembles a checboard.
> >    Pov 3.x can't generate a texture where a brick is
> >    exatly bellow other. Instead, one brick extends two
> >    halves of the bricks above and bellow. I think that
> >    one tile should be placed exatly bellow other in
> >    the tile texture.
>
> I really don't understand this wish. What you mean as "below" ? under in
> leyers of texture or descending coordinates in some direction ? As Pov 3.x you
> mean also 3.5 ? Have you know function possibilities ? Have you know warp{} ?
>

I think Valdemir means a tile-like pattern, just as brick is a brick-like
pattern. Easy enough to do with a function in 3.5 - hmm, I wonder if quilted
would do.

Post a reply to this message

> 
> On Thu, 02 May 2002 10:31:05 -0300, Valdemir Carrara <val### [at] deminpebr> wrote:
> > Hi,
> 
> Hi
> 
> > That's my first intro in the pov newsgroup, so I hope
> > you guys be patient.
> 
> there is special group for people like you: povray.newusers
> 
> > I have two questions, and I
> > didn't find the answer in the FAQ area (though is
> > almost impossible to find something in this huge
> > place).
> 
> You mean povray.announce.frequently-asked-questions or
> http://www.students.tut.fi/~warp/povQandT/
> 
> >1 - I'd like to see the "tiles" keyword back to Pov
> >    textures, but with the sense of tiles and not the
> >    sense of checkboard. Tiles are a mixture of checboard
> >    with brick. It has a mortar, and resembles a checboard.
> >    Pov 3.x can't generate a texture where a brick is
> >    exatly bellow other. Instead, one brick extends two
> >    halves of the bricks above and bellow. I think that
> >    one tile should be placed exatly bellow other in
> >    the tile texture.
> 
> I really don't understand this wish. What you mean as "below" ? under in
> leyers of texture or descending coordinates in some direction ? As Pov 3.x you
> mean also 3.5 ? Have you know function possibilities ? Have you know warp{} ?
> 

I mean descending in coordinates. I knew warp but I didn't
know
exactly what I could do with it. I just made some tests, and
now I

texture
in such a way to make it a perfect tile. So living and
learning...

> > 2 - There's something strange in the way that light
> >     intensity is calculated.
> 
> I'm sure Kari Kivisalo or somebody similiar will answer you :-)
> 
> ABX

Post a reply to this message

Attachments:
Download 'us-ascii' (1 KB)

> 2 - There's something strange in the way that light
>   intensity is calculated. Real lights have intensity
>   decreasing proportionally to the inverse of the
>   squared distance:
>
>    I  = K / d^2

I'm not sure this is 100% true. Because if it were, that would mean that as
you approached the light source, the light intensity would approach
infinity. So if you put your eye an inch or so away from a candle, it would
probably be like looking directly at the sun and you'd go blind. So this
can't really be 100% true.

The equation 1/(1+d^2), after about two or three units from the origin, is
extremely similar to 1/d^2. (graph the two functions in a program and you'll
see why.) The only difference is that near the origin, 1/(1+d^2) has the
value of one (not infinity). I think this is a lot closer to the real life
model, and it still has the property that light intensity is *almost*
proportional to the inverse of the distance squared.

As for the checker pattern you were talking about, you may be interested in
this function that I came up with recently for my "traditional raytracing
desktop" image:

#declare smoothcheckerbasis = function (x,y,z,allfloors,xv,yv,zv) {
 select(allfloors-floor(allfloors/2)*2,
  0,
  max(xv-.5,yv-.5,zv-.5, .5-xv,.5-yv,.5-zv),
  min(xv+.5,yv+.5,zv+.5, 1.5-xv,1.5-yv,1.5-zv)
 )
}
#declare smoothchecker = function (x,y,z) {

smoothcheckerbasis(x,y,z,floor(x)+floor(y)+floor(z),x-floor(x),y-floor(y),z-
floor(z))
}



functions only work with POV-Ray 3.5 (which is still in beta), but if you're
using that, this should help you. It's best used as:

pigment {
    function{smoothchecker(x,y+.5,z)}
    // a color map similar to this will be most effective:
    color_map {
        [.4 rgb 0]
        [.6 rgb 1]
    }
}

I use "y+.5" instead of just "y" since the function is only interesting
halfway through a unit. It has a solid value of .5 at all integer values.

- Slime
[ http://www.slimeland.com/ ]
[ http://www.slimeland.com/images/ ]

Post a reply to this message

> 1 - I'd like to see the "tiles" keyword back to Pov
>   textures, but with the sense of tiles and not the
>   sense of checkboard. Tiles are a mixture of checboard
>   with brick. It has a mortar, and resembles a checboard.
>   Pov 3.x can't generate a texture where a brick is
>   exatly bellow other. Instead, one brick extends two
>   halves of the bricks above and bellow. I think that
>   one tile should be placed exatly bellow other in
>   the tile texture.

If you look at the 'brick' pattern, it looks like bricks on the x znd z
planes, but on the y plane you get the 'tile' look you want.  You just need
to rotate it appropriately to the surface you use.

-tgq

Post a reply to this message

You're right! I didn't notice this feature.
Thank you

Val

TinCanMan wrote:
> 
> > 1 - I'd like to see the "tiles" keyword back to Pov
> >   textures, but with the sense of tiles and not the
> >   sense of checkboard. Tiles are a mixture of checboard
> >   with brick. It has a mortar, and resembles a checboard.
> >   Pov 3.x can't generate a texture where a brick is
> >   exatly bellow other. Instead, one brick extends two
> >   halves of the bricks above and bellow. I think that
> >   one tile should be placed exatly bellow other in
> >   the tile texture.
> 
> If you look at the 'brick' pattern, it looks like bricks on the x znd z
> planes, but on the y plane you get the 'tile' look you want.  You just need
> to rotate it appropriately to the surface you use.
> 
> -tgq

Post a reply to this message

Attachments:
Download 'us-ascii' (1 KB)

Slime wrote:
> 
> I'm not sure this is 100% true. Because if it were, that would mean that as
> you approached the light source, the light intensity would approach
> infinity. So if you put your eye an inch or so away from a candle, it would
> probably be like looking directly at the sun and you'd go blind. So this
> can't really be 100% true.
> 
> The equation 1/(1+d^2), after about two or three units from the origin, is
> extremely similar to 1/d^2. (graph the two functions in a program and you'll
> see why.) The only difference is that near the origin, 1/(1+d^2) has the
> value of one (not infinity). I think this is a lot closer to the real life
> model, and it still has the property that light intensity is *almost*
> proportional to the inverse of the distance squared.
> 

This is 100% true! It's a physical phenomenon and not a mere
guess.
If you come very close of a bulbe light you go blind!

I agree with the similarity of both functions. I had already
drew 
the curves. They are "almost" equal for large distances but
they 
are very different at small distances. But that means that
the light 
intensity depends on the scale you use in the scene! That's
nonsense.
The only way one have to compensate the scale influence is
to choose
a fade_distance equals to infinitesimal value (a very small
value)
and to increase the light intensity by a factor of
1/fade_distance^2:

#declare eps = 0.0001
light_source {  <12., 10., 40.>
  color rgb <1.000, 1.000, 1.000>/eps/eps
  fade_distance eps fade_power 2
}

> As for the checker pattern you were talking about, you may be interested in
> this function that I came up with recently for my "traditional raytracing
> desktop" image:
> 
> #declare smoothcheckerbasis = function (x,y,z,allfloors,xv,yv,zv) {
>  select(allfloors-floor(allfloors/2)*2,
>   0,
>   max(xv-.5,yv-.5,zv-.5, .5-xv,.5-yv,.5-zv),
>   min(xv+.5,yv+.5,zv+.5, 1.5-xv,1.5-yv,1.5-zv)
>  )
> }
> #declare smoothchecker = function (x,y,z) {
> 
> smoothcheckerbasis(x,y,z,floor(x)+floor(y)+floor(z),x-floor(x),y-floor(y),z-
> floor(z))
> }
> 
> functions only work with POV-Ray 3.5 (which is still in beta), but if you're
> using that, this should help you. It's best used as:
> 
> pigment {
>     function{smoothchecker(x,y+.5,z)}
>     // a color map similar to this will be most effective:
>     color_map {
>         [.4 rgb 0]
>         [.6 rgb 1]
>     }
> }
> 
> I use "y+.5" instead of just "y" since the function is only interesting
> halfway through a unit. It has a solid value of .5 at all integer values.
> 
> - Slime
> [ http://www.slimeland.com/ ]
> [ http://www.slimeland.com/images/ ]

Thank you. I'll check it!

Val

Post a reply to this message

Attachments:
Download 'us-ascii' (1 KB)

> that means that the light intensity depends on the scale
> you use in the scene! That's nonsense.

First off, let me say that my math education is simple. But seen from a
logic point of view, intensity of light in real life also depends on
distance.. And things in real life also has a certain "scale".. So how can
it be "nonsense" if POV works in the same way?

> The only way one have to compensate the scale influence is
> to choose a fade_distance equals to infinitesimal value

That's true, from what I know.. But instead of playing clever in this field,
I'll give you a link to someone who played a lot with light in POV and knows
how to get marvellous results:

http://www.ignorancia.org/lightsys/


Regards,
Hugo

Post a reply to this message

Hugo wrote:
> First off, let me say that my math education is simple. But seen from a
> logic point of view, intensity of light in real life also depends on
> distance.. And things in real life also has a certain "scale".. So how can
> it be "nonsense" if POV works in the same way?
> 

Simple: if you make a scene with a "correct illumination" and if you
decide to rescale your scene (to double or to half the scale), you'll
have a different render result, unless you compensate for the new scale in
light intensity!
Things in real life has a certain scale indeed. But this affects only
it's shape and texture, and not the illumination.

> 
> That's true, from what I know.. But instead of playing clever in this field,
> I'll give you a link to someone who played a lot with light in POV and knows
> how to get marvellous results:
> 
> http://www.ignorancia.org/lightsys/
> 

That's right! Great hint. Thank you.

> Regards,
> Hugo

Post a reply to this message

Attachments:
Download 'us-ascii' (1 KB)

I forgot to say that I know that the intensity of real
lights depends on distance. What I'm saying is that
Pov calculates light attenuation (function of the
distance) in such a way that makes it difficult to
simulate real lights.

Regards

Val

Post a reply to this message

Attachments:
Download 'us-ascii' (1 KB)

Valdemir Carrara wrote:
>
> 2 - There's something strange in the way that light
>   intensity is calculated.

Just use fade_power 2 and fade_distance <diameter of the source>
or sqrt(area of the source) if using irregular source. Fade distance
links the size of the source to intensity. This produces scale independent
light source. Have a look at cornell.pov in 3.5 radiosity files to see
how it works and produces physically correct results. Compare the
result to http://www.graphics.cornell.edu/online/box/box.jpg

The equation is an empirical approximation for near field axial area
source intensity and is more realistic than 1/d^2 for real, non microscopic
sources. At a distance of 5 times the source diameter both equations are
within 1%. Closer to the source the pov equation is more realistic and
at larger distances the difference is minimal.


_____________
Kari Kivisalo

Post a reply to this message