Hi,

That's my first intro in the pov newsgroup, so I hope
you guys be patient. 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).

I'm a pov user (not a expert user, I have to addmit), and
I'd like to make two suggestions for program improvements.

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.

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

  Pov calculates the "attenuation" by means of a similar
  equation, but with a significative difference:

  Attenuation = 2 / [1 + {d / fade_dist)^power]

  As you can see, if one consider fade_dist = 1 and power
  equal to 2, it is impossible to obtain the real light
  intensity:

  Attenuation = 2 / [1 + d^2],

  due to the presence of the "1" in the denominator. I 
  suggest that this could be modified in the following
  way:

  Attenuation = 2 / [ K + {d / fade_dist)^power]

  Of course it would be user responsability to avoid
"division
  by zero" that could happen if the light is positioned
  in an object surface (d = 0) and if K = 0.

Valdemir Carrara

Post a reply to this message

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

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{} ?

> 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

Hi,

I'd like to say welcome! Your first suggestion with the tile texture should
be easy to do with a repeating warp. The second thing about light
attentuation is an advanced question, but you'll no doubt get a good
explanation, once the right people sees your message.. It won't take too
long, you just be patient too.. ;o)

Regards,
Hugo

Post a reply to this message

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