Hi all,

Not sure if this is the right group for it (maybe advanced users would be
better). I've just written an article about Povray's arealights, based on
some tests I've conducted recently, and unfortunatly I have to say it isn't
glowing with praise for them.

You can read the article here:
http://www.redbrick.dcu.ie/~element/areaLights/

It's a bit image heavy, so watch your connection ;)

Let me know what you think, either by replying here or posting to my comment
system (the link is at the bottom of the article).

All the best,


John Mellerick
------------------------------------
http://www.redbrick.dcu.ie/~element/
ele### [at] redbrickdcuie

Post a reply to this message

John -

It seems that you have made a mistake in comparing the POVs area light
to your truAreaLight.  To compare the two in your first example, you
should have declared the area light as

light_source {
    <?, ?, ?>
    color ?
    area_light <?, ?, ?>, <?, ?, ?>, 8, 16
}

This should mimic the density of light sources that you're using in your
tru implementation of area lights.

However, it looks like you actually used 

light_source {
    <?, ?, ?>
    color ?
    area_light <?, ?, ?>, <?, ?, ?>, 2, 2
}

which would just put a pointlight at each corner of the rectangle and
give you exactly the results you are showing.

Why don't you re-render the images with the 8, 16 settings and see if
there's a difference??  I'd be interested to see the results.

- Ben

Post a reply to this message

John Mellerick wrote:
> 
> Hi all,
> 
> Not sure if this is the right group for it (maybe advanced users would be
> better). I've just written an article about Povray's arealights, based on
> some tests I've conducted recently, and unfortunatly I have to say it isn't
> glowing with praise for them.
> 
> You can read the article here:
> http://www.redbrick.dcu.ie/~element/areaLights/
> 
> [...]

You seem to have put quite some work into that, but you don't seem to know
very much about the technical aspects of soft shadows in a raytracer in
general and about the POV-Ray area_light function in particular.

I addition your text does not seem to spend a single word on speed
issues.  

My suggestion before jumping to quick conclusions would be to:
- read the relevant sections of the POV-Ray documentation again, a lot of
the things you write indicate you did not really understand what
area_lights are about.
- read something about the techniques of soft shadows in raytracing in
general, you seem to think the POV-Team does not know how to implement a
good area light function...
- try some other raytracers for comparison and see if they supply more
realistic functions.
- use POV-Ray more intensively to get a feeling for the necessities when
really using the program and not just doing theoretical tests.

BTW, most of the images are broken because of spaces in the file names.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

My first guess is that POV-Ray always uses the same light direction (namely 
the vector from lightsource "main" location to the hitpoint) for the 
calculation of the lighting (diffuse, phong, etc.). Or it does this 
calculation only once (with a light source intensity calculated from all 
the shadow rays shot for each sub-light of the area_light). This would 
explain pritty much all of your effects. Also, if the light source is 
relativly far away from the illuminated objects it will not make a big 
difference as the vector only changes a bit.


-- 
http://objects.povworld.org - the POV-Ray Objects Collection

Post a reply to this message

In article <3d6d2f16@news.povray.org> , "John Mellerick" 
<joh### [at] maildcuie> wrote:

> Let me know what you think, either by replying here or posting to my comment
> system (the link is at the bottom of the article).

You would have gained more by reading the documentation first and to try to
understand it rather than building a wrong mental model of how POV-Ray works
to then develop a model how it should work that misses most important
points.  While different shapes for area light sources are nice, that is the
only thing your SDL code provides.

However, as most of the image and SDL links are broken it is hard to say
more in detail...

    Thorsten

Post a reply to this message

Hi Ben,

> light_source {
>     <?, ?, ?>
>     color ?
>     area_light <?, ?, ?>, <?, ?, ?>, 2, 2
> }
>
> which would just put a pointlight at each corner of the rectangle and
> give you exactly the results you are showing.

Well, actually I *did* use the 8, 16 settings! Here's the code, copy and
pasted right out of the .pov file:

  light_source
  {
    0*x                 // light's position (translated below)
    color <1.0, 1.0, 1.0>*1.7       // light's color
    area_light
    <2, 0, 0> <0, 4, 0> // lights spread out across this distance (x * z)
    8, 16                // total number of lights in grid (4x*4z = 16
lights)
    adaptive 0          // 0,1,2,3...
    #if (letPovrayCheat = true)
      adaptive 5
    #end
    translate <-2, 0, -2>   // <x y z> position of light
  }

Ignore the comments, I never botherd updating them from the Povray defaults.
As you can see, for the first test the Povray area light *did* have 8x16
lights.


John

Post a reply to this message

Hey Christoph,

> You seem to have put quite some work into that, but you don't seem to know
> very much about the technical aspects of soft shadows in a raytracer in
> general and about the POV-Ray area_light function in particular.

That's true, I have never tried coding a raytracer before (but next year in
college there is a module in computer graphics where I will - looking
forward to it ;)), so I don't have any technical programming knowledge of
how Povray specifically works, or how other raytracers work. I'm just basing
my test visually, on the images I get out of Povray.

> I addition your text does not seem to spend a single word on speed
> issues.

Mostly true. I never say which is faster (Povray's arealight is faster), but
I do say about the macro I wrote "The more lights, the smoother the shadows
you'll get out of the macro, but it will take longer to parse and render,
and it will use up more memory". Not great. In the next update on the
article, I'll include a more detailed comparison of the speed of the two
types of lights (I don't have the renderstats for the scenes any more).

> My suggestion before jumping to quick conclusions would be to:
> - read the relevant sections of the POV-Ray documentation again, a lot of
> the things you write indicate you did not really understand what
> area_lights are about.

Good idea - there probably is something basic I'm missing ;) I'm a little
hazy on the way adaptive works exactly, but seeing as it was disabled for
the main test on the page, I didn't think it mattered. Also, I'm sure my
upcoming module in CG will help out in this regard.

> - read something about the techniques of soft shadows in raytracing in
> general, you seem to think the POV-Team does not know how to implement a
> good area light function...

As I said in the article, I know it's hard to code, and I have not a bad
word to say against the PovTeam. It's just that the behaviour of the
arealight in Povray from what I have seen in my tests seems to deviate
wildly from both reality and from what the documentation would suggest. The
simple macro I coded gave about 98% of the results I was expecting, while
the Povray arealight broke down for every test. Also, as I said in the
article, it's all just my oppinion ;)

> - use POV-Ray more intensively to get a feeling for the necessities when
> really using the program and not just doing theoretical tests.

There is nothing too theoretical about the tests. The Illumination Footprint
would come into effect if you were trying to simulate flat-paneled lighting
near walls. The other two tests come into play if you are trying to simulate
reflective or refractive objects in your scenes. These all seem like fairly
normal applications of a raytracer to me.

> BTW, most of the images are broken because of spaces in the file names.

Yeah, sorry about that, it should be fixed now. It was working for me with
my browser, so I just assumed - oops! All the spaces have been removed. I'd
be interested if you gave the page another look...

Thanks for reading!


John

Post a reply to this message

Hi Micha,

> My first guess is that POV-Ray always uses the same light direction
(namely
> the vector from lightsource "main" location to the hitpoint) for the
> calculation of the lighting (diffuse, phong, etc.). Or it does this
> calculation only once (with a light source intensity calculated from all
> the shadow rays shot for each sub-light of the area_light). This would
> explain pritty much all of your effects.

That might be it - however, without looking at the source code, I guess I
won't know for sure. I'm kinda busy with work and getting ready for college
in a few weeks at the moment, so hopefully I'll get a chance to look through
it soon.

>Also, if the light source is
> relativly far away from the illuminated objects it will not make a big
> difference as the vector only changes a bit.

Agreed. However in my test scenes, the lights were only a few units away
from the objects at most, so they should have recieved plenty of
illumination. The Povray arealight seemed to leave the sides of the spheres
in the dark, even with very long lights (see the extra 'cat's-eye' test near
the bottom).


John

Post a reply to this message

Hi Thorsten,

> You would have gained more by reading the documentation first and to try
to
> understand it rather than building a wrong mental model of how POV-Ray
works
> to then develop a model how it should work that misses most important
> points.

I did read the documentation, and it seemed to suggest to me that the
arealight was, at base, just a rectangular array of point light sources. I
understand (I think) how the adaptive and jitter keywords change the simple
rectangular arrangement of lights, but these were disabled for my main
tests, and so shouldn't have had any effect over the basic grid of lights.

>While different shapes for area light sources are nice, that is the
> only thing your SDL code provides.

Maybe you misunderstand - my macro lightsource wasn't designed to be better
than the Povray area light, and it wasn't designed as a replacement, it was
merely designed to replicate what the docs seem to say the area light does.
I didn't use the third dimension in my tests, and I only coded it in so I
could play around with it myself.

> However, as most of the image and SDL links are broken it is hard to say
> more in detail...

Yeah, sorry about that, the page was working fine in my browser so I assumed
it worked for everyone. So I've updated the page by removing the spaces from
all the image and linked file names. I'd be greatful if you'd have a look at
it again.

All the best,


John

Post a reply to this message

In article <3d6d46dd@news.povray.org> , "John Mellerick" 
<joh### [at] maildcuie> wrote:

> Yeah, sorry about that, the page was working fine in my browser so I assumed
> it worked for everyone. So I've updated the page by removing the spaces from
> all the image and linked file names. I'd be greatful if you'd have a look at
> it again.

The images work, but the scene files don't yet.

    Thorsten

Post a reply to this message

Besides the things people have already commented, two points:

  Your "true" area light is not a true area light. It's a grid of point
lights, which is a completely different thing.

  There *is* a major difference between area_lights and grids of point
lights: The area_light calculations are done *only* for shadow testing.
Nothing else. For any other purpose an area_light is a point light and
nothing more. (I'm not saying that this is a good thing; I'm just stating
the fact.)
  (Ok, photons is another place where area_light makes a difference if
configured to do so, but that's another different issue.)

  By the way, I don't like your attitude at pointing at area_light "defects"
which are simply caused because you used an adaptive value which was too low
or too low dimensions. The documentation is quite clear about this: It
explains in full detail what does 'adaptive' do and what happens if it's too
low.
  Since that is an artifact which is to be expected from a too low adaptive
value and this is clearly explained in the documentation along with a simple
solution (ie. use a larger adaptive value and if that's not enough, increase
the dimensions of the area light), it's unfair that you speak of it as if it
was a defect.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

John Mellerick wrote:
 >
> Hi all,
> 
> Not sure if this is the right group for it (maybe advanced users would be
> better). I've just written an article about Povray's arealights, based on
> some tests I've conducted recently, and unfortunatly I have to say it isn't
> glowing with praise for them.

As I understand it, POV's area lights pretty much are crude hacks. Their 
*only* purpose is to create soft shadows, not to accurately simulate 
flat-panel lighting or arrays of point lights.. and because they only 
calculate shadows, they can do so much faster than a real light array 
while using less memory. Even today this is valuable; in the past it 
would have been necessary.

In regards to Christoph's "theoretical" comment, I suspect he means to 
say that having over a hundred point lights for every light in a scene 
may be practical for simple test scenes, but would make rendering for 
many real scenes unacceptably slow. I have often found the same to be 
true of high radiosity settings.

I do find the "stadium lighting" effect on the half-marble strange, 
though. Are you sure you're using the area light properly?

-Xplo

Post a reply to this message

I just wanted to say a quick word or two in defence of John and his
article.

    I can remember when I first discovered POVs area-lights and being hugely
disappointed by the results. I wanted a fluorescent strip light in my scene,
I quickly dug into the docs and found the funky area_light thing, tried it,
and it just didn't look right - I had the strip light close to a wall and
spotted the same 'the light seems to be coming from the center of the strip,
not all along it' effect.
    Ok, I later read the documentation in more depth and realised that
area_lights were never designed for the effect that I wanted and in the end
I produced something similar to John's 'truAreaLight' solution.
    But my initial reaction on reading the docs was exactly the same a
John's - 'these area_light things just don't behave realistically' - and the
very fact that Warps misconceptions page needs a section on area lights
(though, I note it insists that the results you get from an area light are
'practically identical' to an array of point lights) shows that we're not
the only two people to have had misconceptions about what area_lights are
meant to do and how they are meant to behave.

    I think there is a need in POV for a more realistically modelled 'area
light' (for the want of a better term) and John's Photon Challenge images
neatly demonstrate why - so what if it renders more slowly - people are
going to quickly learn that 'truAreaLights' (to use John's nomenclature)
kill render time, just as we all quickly came to understand that
antialiasing produces a big hit on render time - when it does produce more
realistic lighting effects ?

    Everything in POV is to some degree optional, and to some degree affects
render time, and it is up to us to decide where and when we choose to use
each feature to achieve the results we desire. I do not see why there would
be any problem in implementing an optional, more realistic, model of 'area
lights' in POV - there clearly is a need for it - and it could, I would have
thought, also benefit from optimisations and techniques that the 'create an
array point lights' solution can not.

--
Pandora/Scott Hill/[::O:M:C::]Scorpion
Software Engineer.
http://www.pandora-software.com

Post a reply to this message

Pandora wrote:

>     I think there is a need in POV for a more realistically modelled 'area
> light' (for the want of a better term) and John's Photon Challenge images
> neatly demonstrate why -

I was under the impression that he had adaptive supersampling (and probably
jitter) turned off , and the POV area_lights were probably not being used to
their best potential. I think everyone, at one time or another, has tried to
make their own version of a "real area light." My best attempt involved not a
grid but a randomized 3D cluster (using #while), and the shadows were nice and
creamy etc., and, of course, took forever.  But everyone realizes sooner or
later that area_lights are there for basically one reason - to provide soft
shadows in a reasonable amount of time, and I think, when properly used, they do
a great job.

Post a reply to this message

"Dave Dunn" <poi### [at] aolcom> wrote in message
news:3D6D7167.EA598FCF@aol.com...
> Pandora wrote:
>
> >     I think there is a need in POV for a more realistically modelled
'area
> > light' (for the want of a better term) and John's Photon Challenge
images
> > neatly demonstrate why -
>
> ....everyone realizes sooner or
> later that area_lights are there for basically one reason - to provide
soft
> shadows in a reasonable amount of time, and I think, when properly used,
they do
> a great job.
>


    Sure, I'm not criticising POVs area_light performance in terms of what
they were designed to achieve. However they don't achieve, what on the
surface, and on a quick read of the area_light docs, it would appear they
might. Correctly used, they're great at producing efficient soft shadowing,
but that's all they're good for. But, now we have things like photons and
dispersion, and to some degree before these things were available in the
standard POV distribution (for example, in the case of specular highlights)
I
do believe there is a need for a more realistic 'area light' light source
form that does behave in the way one might assume from a quick read of the
area_light documentation.

--
Pandora/Scott Hill/[::O:M:C::]Scorpion
Software Engineer.
http://www.pandora-software.com

Post a reply to this message

Micha -

I'll bet you're right.  I tried to trace out the area light code in
lighting.cpp, but it's a total mess!  If you're right, I think it should
probably be fixed in the next implementation of POV!

- Ben

Post a reply to this message

Warp -

Why not add these kind of features to the area lights?

- Ben

Post a reply to this message

Christoph Hormann wrote:

[lots]

Keep in minds that the following point may be moot...I haven't studied the
sources....

try {

Having spent most of my copious free time reading CG articles, dissecting
sources, coding some of mine and in general listening to any sources of
information, I feel that I have more of an adeguate understanding of ray
tracing to post the following question?:

1. How does Povray samples area lights?

Granted, Povray is no MC raytracer, but the problem should be similar.

2. Shouldn't it sample the solid angle subtended by the area light?

IIRC, illumination from an area light should be (in Kajiya's notation):
             /                                                dA'cos t'
L(x, psi) =  | g(x, x') rho(x, psi, psi') L(x' psi') cos(t) * --------
             / x' on S                                        ||x'-x||^2

where:
g is the blocking function, psi is the viewing vector, psi' the illumination
vector, rho is the BRDF L is the luminance function, t is the angle between
psi' and surface's normal at x, t' is the angle between psi' and x' and dA'
is the differential area of x'

3. How does Povray approximates this integral?

There is an interesting article in Graphics Gems III (ancient in terms of CG
time) which gives an unbiased probability function for a MC integration,
which should be applicable to distribution ray tracers.

4. Who is the author of the lighting code?

I would love an article from the guy (or guys) detailing the structure of
Povray's lighting engine and I daresay I'd buy a book on the innards of
Povray 3.5, which would make a splendid coursebook in CG.

I never had time to properly study Povray's sources and I'd love to plug in
some CG algorithms I've been reading in these years.

What I miss is an HOWTO (linux-style), detailing the functional units in
Povray.

Maybe...a book, or, better yet, an eBook.
}
catch(flames)
{
  // Exception dumb handler
  // Here we deal with people who can't stand a flame-bait

  // done.
}

Enough ranting...

Seriously, though: why not an eBook about Povray source?
The POV Team could write it (using docbook perhaps) and sell it through the
Povray site, making us tinkerer happy twice (we get to fully understand the
code and we *also* get to finance Povray development)
10$ or 20$ might be a reasonable price and without printing and distribution
costs, most of it would benefit the Povray team.

Just a thought,
Alex

Post a reply to this message

On Thu, 29 Aug 2002 03:58:37 EDT, "Alex" <ale### [at] alphacit> wrote:
> I never had time to properly study Povray's sources and I'd love to plug in
> some CG algorithms I've been reading in these years.

Like for example what ?

Many of algorithms can be implemented via SDL. Have you already tried this
way?

ABX

Post a reply to this message

ABX wrote:
>On Thu, 29 Aug 2002 03:58:37 EDT, "Alex" <ale### [at] alphacit> wrote:
>> I never had time to properly study Povray's sources and I'd love to plug in
>> some CG algorithms I've been reading in these years.
>
>Like for example what ?
>
>Many of algorithms can be implemented via SDL. Have you already tried this
>way?
>
>ABX
>

Ray Tracing Triangular Trimmed Free Form Surfaces - Wolfgang Stürzlinger

If you manage to implement this in SDL, I'd like to worship you as a new
Coding Deity

Alex 'No-offense-meant' Morelli
Pov & peace

Post a reply to this message

On Thu, 29 Aug 2002 04:36:13 EDT, "Alex" <ale### [at] alphacit> wrote:
> Ray Tracing Triangular Trimmed Free Form Surfaces - Wolfgang St�rzlinger

What would be the next ?

> If you manage to implement this in SDL, I'd like to worship you as a new
> Coding Deity

No need for worship just some experience. As I understand it is UV surface.
What's the problem with generating it as parametric object or mesh?
For examples of complicated surfaces created with SDL just look at:
http://news.povray.org/povray.binaries.animations/26690/188522/bezier3angular.mpg
http://news.povray.org/povray.binaries.images/24837/
http://members.home.nl/seedseven/msm.png

ABX

Post a reply to this message

Alex wrote:

> Ray Tracing Triangular Trimmed Free Form Surfaces - Wolfgang Stürzlinger

As I see the article talks about triangular Bezier patchs. See 
p.advanced-users and p.b.scene-files for a macro that creates these shapes. 
While you could directly use POV-Rays paramatric surfaces to implement it 
this is very slow, so the macro creates a mesh2 which approximates the 
surface.

- Micha

-- 
http://objects.povworld.org - the POV-Ray Objects Collection

Post a reply to this message

To Micha and ABX:

At risk of seeming offensive:

I couldn't care less about meshes - triangles are not my thing.

What I want is to trace a network of patches subject to a FFD, without
generating the approximation mesh.

To illustrate why it would be nice:
Design a blade of grass (using, say, 20 patches)
Apply a procedural FFD (calculated from the air flow)
Render it
Wow and drool at the smoothness and beauty of the movement

No difference yet between the two methods

Now, disperse the blades of grass over an HF, with a Poisson distr (just to
be a smartass), say, 100.000 of them

Let's see...
triangle meshes...what! *THAT* many *different* polygons??
One FFD per cloned blade of grass? Hmmmm...if i can find a compact way of
specifying the FFD this could be good. Oh. I can't apply a FFD to a network
of patches. Bummer.

I might take another route tho...model the single blade in F-rep, devise a
periodic version of the F-rep and superimpose a scalar field of parameters
to obtain local deformations...that sounds interesting too, well within SDL
domain.

However, a F-rep of that magnitude would be a daunting task to devise and I
would have appallingly little control on the distribution of single blades
of grass...

As of rendering time...anyone working on a parallel version of POV? Yes?
Good... Anyone could lend me for a few months a 512-node render farm? Make
those nodes at least R10000, please.....

Jokes aside, traced FFDs could help many mass scenes.

Alex

P.S.: I am truly amazed...I managed to start with area lights and arrive to
grass!
All hail the King of Offtopic!
Ha!

Post a reply to this message

John Mellerick wrote:
> As I said in the article, I know it's hard to code, and I have not a bad
> word to say against the PovTeam. It's just that the behaviour of the
> arealight in Povray from what I have seen in my tests seems to deviate
> wildly from both reality and from what the documentation would suggest.

  I can agree that they are not like the real thing, but I can't agree 
about the documentation. What the documentation states is what POV-Ray 
does. Exactly. And you know it, isn't? Why you stopped quoting section 
6.5.7.5 when it comes to explain just these things you claim it does not 
explain?

> The simple macro I coded gave about 98% of the results I was expecting,
> while the Povray arealight broke down for every test. Also, as I said in
> the article, it's all just my oppinion ;)

  As others pointed, we all have tried this sooner or later.. and sonner or 
later we all realized it is too slow.

-- 
Jaime Vives Piqueres

La Persistencia de la Ignorancia
http://www.ignorancia.org

Post a reply to this message

Ben Birdsey <cla### [at] mailcom> wrote:
> Why not add these kind of features to the area lights?

  Which features?

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Dave Dunn <poi### [at] aolcom> wrote:
> I was under the impression that he had adaptive supersampling (and probably
> jitter) turned off

  No, the problem is exactly the opposite: He had adaptive supersampling
turned on, but with a too low value, which results in artifacts in the
extreme cases shown in the page.
  IMO it's very unfair to compare shadows resulting from an area_light with
a too low adaptive value with the ones resulting from an explicit grid of
point lights. In order to make the comparison fairly, the adaptive value
has to the raised as high that no artifacts are seen.

  The real advantage of an area_light over an explicit grid of point
lights is that you can have *lots* of lights in the area_light without
the rendering slowing down unacceptably. For example you could have 30x30
lights in your area_light, and with the proper adaptive setting the rendering
time would be still acceptable. With an explicit grid of 30x30 point lights
you'd better have a couple of weeks to wait for your rendering to finish.

  The only defect of area_light is that it only affects shadow testing and
nothing more. This means that diffuse and specular lighting will still be
the one of a point light. (I'm not saying this is a good thing; it's just
the way it's currently implemented.)
  It might be possible to take into account the area_light settings when
calculating diffuse and specular lighting. Perhaps someone will try a
patch in the near future?

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:3d6e221f@news.povray.org...
> Ben Birdsey <cla### [at] mailcom> wrote:
> > Why not add these kind of features to the area lights?
>
>   Which features?
>


    Everything that Johns article talks about other than shadow artifacts!
As they are area_lights are not area _lights_ they're area _shadow
casters_...

--
Pandora/Scott Hill/[::O:M:C::]Scorpion
Software Engineer.
http://www.pandora-software.com

Post a reply to this message

Warp wrote:
> 
> [...]
> 
>   The only defect of area_light is that it only affects shadow testing and
> nothing more. This means that diffuse and specular lighting will still be
> the one of a point light. (I'm not saying this is a good thing; it's just
> the way it's currently implemented.)
>   It might be possible to take into account the area_light settings when
> calculating diffuse and specular lighting. Perhaps someone will try a
> patch in the near future?

In any case an area light only affecting shadows like now should still be
possible since this is exactly what's often wanted and everything further
would just unnecessarily slow down things in those situations.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

Pandora <pan### [at] pandora-softwarecom> wrote:
>     I think there is a need in POV for a more realistically modelled 'area
> light' (for the want of a better term) and John's Photon Challenge images
> neatly demonstrate why

  Uh? Photon mapping is more efficient with area_lights because you have
better control on how many photons are shot from it. Also AFAIK the photons
are shot randomly from the entire surface of the area light, not from the
individual point lights in it, thus getting actually a better result than
with a grid of point lights.
  Any artifact you may see is produced simply because too few photons are
shot, which is remedied by fine-tuning the photon mapping parameters.

  By the way, I added an entry about area lights to the povQ&T page.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

"Pandora" <pan### [at] pandora-softwarecom> wrote in message
news:3d6e26cb@news.povray.org...
> "Warp" <war### [at] tagpovrayorg> wrote in message
> news:3d6e221f@news.povray.org...
> > Ben Birdsey <cla### [at] mailcom> wrote:
> > > Why not add these kind of features to the area lights?
> >
> >   Which features?
> >
>
>     Everything that Johns article talks about other than shadow artifacts!


    And maybe photons - a quick test seems to suggest that area_lights and
photons do indeed appear to give pretty good results - though I'm not 100%
sure about the physical 'correctness' of the model...

--
Pandora/Scott Hill/[::O:M:C::]Scorpion
Software Engineer.
http://www.pandora-software.com

Post a reply to this message

Warp wrote:
>  The only defect of area_light is that it only affects shadow testing and
>nothing more. This means that diffuse and specular lighting will still be
>the one of a point light. (I'm not saying this is a good thing; it's just
>the way it's currently implemented.)
>  It might be possible to take into account the area_light settings when
>calculating diffuse and specular lighting. Perhaps someone will try a
>patch in the near future?

I would love to give a try...
All that I miss is couple of hints.

Follow me a bit and tell me if I'm heading wrong:

1. Povray shoots a single ray toward an area light to determine light color
(emission?) and multiple rays to determine blocking?

If I'm correct, this means that povray attenuates the color of the light
multiplying it by the blocking factor?
 Something like:
L = Lmax x (fraction of area light blocked)

this also means that only one light vector is taken into account when
calculating the lighting at the surface?

Browsing the sources seems to support this theory....
If I'm correct, the Diffuse function gets called in order to gather light
from sources, it calls do_light, which calls block_area_light.
block_area_light calculates the shadow fraction, using multiple rays.
However Diffuse_One_Light (called from Diffuse) uses the original light
vector only.

It seems to me that two avenues are open:
1. Use a single-ray to sample both color and shadow, leading to the need of
many pixel samples
2. Use a specialized version of Diffuse_One_Light which uses each one of the
shadow rays to calculate lighting

Comments?

Post a reply to this message

Just how much slower is your alternative?  How about if you post the render
times for all your examples?

Post a reply to this message

"Alex" <ale### [at] alphacit> wrote in message
news:web.3d6e4624170d095415e7f0160@news.povray.org...
> If I'm correct, the Diffuse function gets called in order to gather light
> from sources, it calls do_light, which calls block_area_light.
> block_area_light calculates the shadow fraction, using multiple rays.
> However Diffuse_One_Light (called from Diffuse) uses the original light
> vector only.
>
> It seems to me that two avenues are open:
> 1. Use a single-ray to sample both color and shadow, leading to the need
of
> many pixel samples
> 2. Use a specialized version of Diffuse_One_Light which uses each one of
the
> shadow rays to calculate lighting
>


    Well, without knowing the source, or anything about the algorithms used,
one would assume that using the general algorithm of block_area_light in
Diffuse_One_Light would be the ideal solution - is this your option 2, or a
further option 3 ?
    Then, I would assume, all other lighting related effects would
automatically utilise the area_light options and optimisations (e.g.
adaptive sampling) that are present for shadow calculations, yes ?

--
Pandora/Scott Hill/[::O:M:C::]Scorpion
Software Engineer.
http://www.pandora-software.com

Post a reply to this message

Greg M. Johnson <gregj:-)565### [at] aolcom> wrote:
> Just how much slower is your alternative?  How about if you post the render
> times for all your examples?

  Here are some render times:
http://www.students.tut.fi/~warp/povQandT/misconceptions.html#arealightconfusion

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:3d6e63af@news.povray.org...
>   Here are some render times:
>
http://www.students.tut.fi/~warp/povQandT/misconceptions.html#arealightconfu
sion
>
> 1 minute 8 seconds to render. [versus]
> ...only 7 seconds to render.
>

My "last place"- winning  IRTC anim two rounds ago used my own homemade area
lights.  It took something like four minutes per frame to render IIRC. I had
no time to add any additional scenes or fix old problems.

Post a reply to this message

Hey,

Doh! This should be fixed now.

I apologise that there have been so many problems with the page. PHP I can
do. Simple HTML? Apparently not ;)


John

Post a reply to this message

Hey,

>   I can agree that they are not like the real thing, but I can't agree
> about the documentation. What the documentation states is what POV-Ray
> does. Exactly. And you know it, isn't? Why you stopped quoting section
> 6.5.7.5 when it comes to explain just these things you claim it does not
> explain?

To be totally honest, I stopped reading the docs when I got to the point
about area lights being a grid of point lights. Then I went off to Warp's
site to confirm that he said the same thing (it had been a few days since I
had read it). And I launched off into my tests. I have since had explained
to me about how the area_lights in Povray only affect the shadows, and have
found the bit in the docs that cover it - embarrassingly, right after where
I
stopped reading ;) So that kind of nullifies Test One in my article.

However, I still think that it's kind of hacky for the arealights to behave
in one way in relation to their shadows, and another way for their
illumination. Shadows are only a side effect of the absence of light; the
soft shadows should be a side effect of the fact that an arealights
illumination doesn't come from a point. Povray totally breaks this
conception with what I consider to be a hacky lightsource. I personally
would much prefer to spend whatever extra time would be needed for a more
accurate source of *illumination* that also happened to give soft shadows by
their very nature.

>   As others pointed, we all have tried this sooner or later.. and sonner
or
> later we all realized it is too slow.

Well, actually, when I was testing my truAreaLight when I was developing it,
I did a 640x480 rendering of a Cornell box with a concrete texture. In it
were two of my truAreaLights, each with 300 point lights (600 total), that
mesh of the warrioress Athena that has been doing the rounds (I think it was
made by a company called De Esponsa or something) which is an 11mb include,
so I can only guess it contains *a lot* of triangles, as well as a shiny red
sphere. Both the sphere and the Athena model had variably reflective
surfaces, and both occupied quite a bit of image-space, so a good bit of the
render time was on them. Added to that the fact that the scene was rendered
with fairly high quality radiosity (count 200, error_bound 0.5,
recursion_limit 3, low_error_factor .5, minimum_reuse 0) and command line
settings of "+r9 +a0.0" meant a fairly heavy-duty render. On a 600mhz P3,
which is hardly a top of the line PC these days, which was being used for
other tasks as well, the scene rendered in 61 hours 18 minutes   8.0 seconds
(including parse time); just over two and a half days. Personally I think
that was quite fast, considering the circumstances.

Now, maybe you think that's really slow. However, considering the quality of
the final image (which I can post with stats if you want), I think that was
fairly quick. Maybe processor speeds have just caught up with the method?


John

Post a reply to this message

Hi,

> As I understand it, POV's area lights pretty much are crude hacks. Their
> *only* purpose is to create soft shadows, not to accurately simulate
> flat-panel lighting or arrays of point lights.. and because they only
> calculate shadows, they can do so much faster than a real light array
> while using less memory. Even today this is valuable; in the past it
> would have been necessary.

As I've been coming to understand over the last 24 hours, the point of
area_lights in Povray, and seeming the reason they were included as they
are, is simply to cast soft-edged shadows. And it's obvious as to why we'd
want soft edged shadows available as a feature - they are all around us in
the real world, there are very few lightsources that I can think of that
could even remotely be considered point light sources.

However, I think they way that Povray goes about creating soft-edged shadows
is *all wrong*. It would appear that the area_lights were written purely for
the shadows, and let the illumination be damned. However, I find this
incredibly counterintuitive. Shadows only exist because of an absence of
light; shadows are only a secondary effect, not the primary one. In my
opinion, it is the special type of *illumination* that should set
area_lights apart from other lights in Povray, with the fact that they cast
illumination from their entire surface area (Povray's implementation of
area_lights doesn't bother with this - they only affect the diffuse and
other aspects of the scene as if they were a point source). The soft edged
shadows should only be a naturally occuring secondary consequence of the
settings that the user applies to the size of the area_light lightsource.
Povray at the moment works mostly like the reverse of this - the user sets
up settings to get the shadows to look and behave a certain way, and the
illumination is only a secondary concern. That is what I think makes
Povray's area_lights a cheap hack.

> In regards to Christoph's "theoretical" comment, I suspect he means to
> say that having over a hundred point lights for every light in a scene
> may be practical for simple test scenes, but would make rendering for
> many real scenes unacceptably slow. I have often found the same to be
> true of high radiosity settings.

Have a look at my reply to Jaime Vives Piqueres above - I describe (in too
much detail to repost here) a very intensive test scene I did with my point
light array macro, with fairly high radiosity settings, very high quality
antialiasing on an average machine that I was using during the day, and the
scene finished fairly quickly, much quicker then I would have expected,
considering what Warp said on his webpage about how slow the "array of point
lights" method was.

> I do find the "stadium lighting" effect on the half-marble strange,
> though. Are you sure you're using the area light properly?

Again, have a look at my reply to Ben Birdsey near the top of the thread, I
posted the settings used for the arealight in that test. Also, the source
code download for my article should be fixed now if you want to download the
whole scene yourself.


John

Post a reply to this message

Hi,

>   Your "true" area light is not a true area light. It's a grid of point
> lights, which is a completely different thing.

I know, I just called it truAreaLight as a name. I realise that a "true"
area light is a very complex thing to simulate in a raytracer, and that
you'd probably have to implement some kind of Monte Carlo engine to do
forwards-raytracing or something equally nasty. My grid of point lights was
just an implementation of what I thought the Povray area light was under the
hood.

>   There *is* a major difference between area_lights and grids of point
> lights: The area_light calculations are done *only* for shadow testing.
> Nothing else. For any other purpose an area_light is a point light and
> nothing more. (I'm not saying that this is a good thing; I'm just stating
> the fact.)
>   (Ok, photons is another place where area_light makes a difference if
> configured to do so, but that's another different issue.)

As I have subsequently found out, and that nullifies Test One in my article.
I still don't think it's right, but it at least explains why I got the
results I did.

>   By the way, I don't like your attitude at pointing at area_light
"defects"
> which are simply caused because you used an adaptive value which was too
low
> or too low dimensions. The documentation is quite clear about this: It
> explains in full detail what does 'adaptive' do and what happens if it's
too
> low.
>   Since that is an artefact which is to be expected from a too low
adaptive
> value and this is clearly explained in the documentation along with a
simple
> solution (ie. use a larger adaptive value and if that's not enough,
increase
> the dimensions of the area light), it's unfair that you speak of it as if
it
> was a defect.

As I just said in my reply to Jamie, "Shadows are only a side effect of the
absence of light; the soft shadows should be a side effect of the fact that
an arealights illumination doesn't come from a point". I believe that the
very fact that there is a disparity between the illumination model that
Povray uses for its arealight and the model it uses to calculate shadows for
the area light totallys break any kind of intuitive concept about how
illumination works. Povray arealights were designed to give soft shadows; I
believe that the illumination that arealights give off was only a distant
secondary concern. That is why I think that Povray arealights are a cheap
hack; it is the special *illumination* property of an arealight that should
be what makes it different from point light sources - the soft shadows
should just be a natural side effect of the used defined properties for the
arealight's source.

I consider the fact that Povray works the exact opposite way to this, in
which the user sets up properties to affect how the *shadows* work (seeing
as no setting apart from colour and falloff and so on will affect the
illumination), to be a defect. Therefore, seeing as adaptive is just an
extra step in this process, it is part of the defect. Do you understand what
I mean?

I'm sorry if I sound so negative, but I just think that arealights in Povray
are just plain *wrong*. It would be great if they could be updated for 4.0
;)


John

Post a reply to this message

Hey Greg,

> Just how much slower is your alternative?  How about if you post the
render
> times for all your examples?

I havn't tried rendering them seperately yet - I'll do some renders this
weekend when I have some free time, and I'll post the results here.


John

Post a reply to this message

...because now I'm repeating myself.

John Mellerick wrote:
> 
> However, I think they way that Povray goes about creating soft-edged shadows
> is *all wrong*.

Yes, those bastards! They added a feature to the software to create 
soft-edged shadows without the massive overhead of massive point light 
arrays! How dare they?

</sarcasm>

No one's holding a gun to your head and forcing you to use area lights. 
If you dislike them that much, don't use them. You have a perfectly 
servicible light array generator.

> Have a look at my reply to Jaime Vives Piqueres above - I describe (in too
> much detail to repost here) a very intensive test scene I did with my point
> light array macro, with fairly high radiosity settings, very high quality
> antialiasing...

Your test scenes were LAUGHABLY SIMPLE.. sufficient to demonstrate a 
technique, but not a good demonstration of the effects of light arrays 
on rendering time for realistically complex scenes. The fact that you 
seem to think otherwise shows your inexperience and ignorance.

-Xplo

Post a reply to this message

Pandora wrote:

>
>
>    Well, without knowing the source, or anything about the algorithms used,
>one would assume that using the general algorithm of block_area_light in
>Diffuse_One_Light would be the ideal solution - is this your option 2, or a
>further option 3 ?
>    Then, I would assume, all other lighting related effects would
>automatically utilise the area_light options and optimisations (e.g.
>adaptive sampling) that are present for shadow calculations, yes ?
>

Studying a bit more the source (mind you, just a 10 min inspection, while I
was supposed to work), the game seems to be:
1 - Lighting code shoots a ray toward a light (from point of intersection to
light origin)
2 - If the light is an area light, additional shadow rays are calculated, to
estimate blocking of light
3 - Lighting calculation (i.e. diffuse and specular) are done using the
first ray only

This means that:
Light intensity is modulated according to a (possibly) biased estimate of
blocking
Diffuse and specular components are calculated as if the light is a point
light, hence the artifacts shown in the pictures.

To obtain a more correct area light the angles used in lighting calculation
should vary. More precisely, the elements needed to calculate a point
apparent emission are not limited to the radiance from a light source, but
include also the angle of incidence.
The povray code for *direct* lighting appears to neglect this, which proves
to be a good approximation only for distant sources.

The problem is that simply plugging the code to sample more than a single
ray leads to multiple evaluations of texturing components, which could be
avoided in a more specific code.

Montecarlo ray-tracers are very accurate, but slow, because (a) they shoot a
single ray toward light sources, both for shadow and lighting, and
therefore require *many* samples per pixel, or (b) they shoot a bunch of
rays, repeating texture evaluations per each sample ray.

A possible optimization could be to calculate once per intersection the
texturing components which are indipendent of incoming light direction, but
this rules out optimization of BRDF (may be or not be true...it seems to me
but I have to check this more thorougly...there's a discussion of this
problem in some ancient paper from SIGGRAPH, iirc)

povray area lights are perfectly adequate when used in conjunction with
radiosity and photons, which utilize a different approximations of the
illumination integral.

However, to obtain efficient "true" area light, I suspect we would have to
rewrite the whole lighting code. In the meanwhile, I'll try (this sunday,
if time permits) to plug in the code described in Graphic Gems III
(http://www.acm.org/tog/GraphicsGems/).

I think I'll try both styles (single-sample and multi). Inituitively, they
should yield the same times (roughly), but....

If anyone is willing to discuss this more or to help me, feel free to write
me directly on ale### [at] alphacit

Alex

------------------------------------------------------
Shadow softly and carry a big light, you'll render far
------------------------------------------------------

Post a reply to this message

Xplo Eristotle wrote:
>....because now I'm repeating myself.
>
>John Mellerick wrote:
>>
>> However, I think they way that Povray goes about creating soft-edged shadows
>> is *all wrong*.
>
>Yes, those bastards! They added a feature to the software to create
>soft-edged shadows without the massive overhead of massive point light
>arrays! How dare they?
>
></sarcasm>
>
>No one's holding a gun to your head and forcing you to use area lights.
>If you dislike them that much, don't use them. You have a perfectly
>servicible light array generator.
>
>> Have a look at my reply to Jaime Vives Piqueres above - I describe (in too
>> much detail to repost here) a very intensive test scene I did with my point
>> light array macro, with fairly high radiosity settings, very high quality
>> antialiasing...
>
>Your test scenes were LAUGHABLY SIMPLE.. sufficient to demonstrate a
>technique, but not a good demonstration of the effects of light arrays
>on rendering time for realistically complex scenes. The fact that you
>seem to think otherwise shows your inexperience and ignorance.
>
>-Xplo
>


Oh! Oh! Calma!

Everybody, let's take a big breath and stop sounding so bitter and harsh.

I only saw discussions get so heated in political forums (tho, sports forums
could be candidates to that, at least in Italy).

These newsgroups at times seem a lesson from Ruffled Feathers 101....

Alex

Post a reply to this message

"Alex" <ale### [at] alphacit> wrote in message
news:web.3d6f2ac71c92063515e7f0160@news.povray.org...
>
> Oh! Oh! Calma!
>
> Everybody, let's take a big breath and stop sounding so bitter and harsh.
>
> I only saw discussions get so heated in political forums (tho, sports forums
> could be candidates to that, at least in Italy).
>
> These newsgroups at times seem a lesson from Ruffled Feathers 101....
>

But he criticised POV! That's fighting talk where I come from...

Seriously, John sort of asked for it - even he admits he didn't read the full
documentation.

What seems a shame is that, written from another perspective - e.g. "Why area
lights are different from a grid of point lights" - would have been a helpful
(and non-contentious) resource....

Post a reply to this message

>
>But he criticised POV! That's fighting talk where I come from...
>

Ruffled Feathers 101: Lesson Two.....

fighting talk? What, we're in a Jihad?

Seriously, tho, POV has a *LOT* of shortcomings, but, hey!, it's free,
developed on a voluntary base, comes with source...

IT DOESN'T HAVE SUBSURFACE-SCATTERING!!! IT DOESN'T SUPPORT THE METROPOLIS
LIGHT TRANSPORT!! IT'S NOT SPECTRAL BASED!!! IT DOESN'T DO SKYDOMES!!!
I WANT BSSRDF! I WANT METROPOLIS! I WANT SPECTRAL! I WANT REAL MOTION BLUR!
I WANT PHISICALLY CORRECT DYNAMICS! CLOTH! FLUIDS!

Now, *that* is fighting talk :)
Alex

Post a reply to this message

On Fri, 30 Aug 2002 05:35:16 EDT, "Alex" <ale### [at] alphacit> wrote:
> IT DOESN'T HAVE SUBSURFACE-SCATTERING!!! IT DOESN'T SUPPORT THE METROPOLIS
> LIGHT TRANSPORT!! IT'S NOT SPECTRAL BASED!!! IT DOESN'T DO SKYDOMES!!!
> I WANT BSSRDF! I WANT METROPOLIS! I WANT SPECTRAL! I WANT REAL MOTION BLUR!
> I WANT PHISICALLY CORRECT DYNAMICS! CLOTH! FLUIDS!
>
> Now, *that* is fighting talk :)

Please don't hurt my eyes with caps lock on ;-)

ABX

Post a reply to this message

On Thu, 29 Aug 2002 05:45:41 EDT, "Alex" <ale### [at] alphacit> wrote:
> To illustrate why it would be nice:
> Design a blade of grass (using, say, 20 patches)
> Apply a procedural FFD (calculated from the air flow)
> Render it

My point was not to against conding your idea as patch.
Every patch with speedup/new feature/bug fix is welcome.
My point was to create general algorithm with SDL and create triangles for
mesh with it. Then measure parsing and rendering time. If both are reasonably
then it is better to keep algorithm written as SDL becouse easier and faster
it can be changed this way.

ABX

Post a reply to this message

Ok, my bad....
my point was that you can't possibly change the behaviour of povray from
SDL,
e.g. you cannot change the lighting equations into Blinn's or Cook's.

If you managed to accomplish that, it would imply at least divine power in
programming, that's what I meant.

Yes, you can and should test new objects meshing them, but it is very
different than adding support for them: tracing directly a patch, for
instance, leads to better texturing and less artifacts, opposed to tracing
a b-rep of the patch.
Simulating an area source with a grid of lights is useful to verify the
other components of the rendering equation in povray, but can not
substitute an implementation of it which utilized the inner methods of
povray, which aren't exposed to the SDL (i.e. I can't call
Diffuse_One_Light fro the SDL)

Maybe povray could take the route of Lightflow and Mental Ray, which are
more SDKs than actual raytracers: we could have two components, a shell,
which takes care of parsing scene files, loading resources et cetera and
build a scene representation for the other component which renders the
whole thing.

Mental ray has this approach: it is a plug-in for Maya and others, i.e. the
modelers build the scene graph and mental ray renders it

The advantage would be a clearer separation from asset handling and
rendering code and, if done right, it would lead to a well-defined external
and internal API.

In povray's case, the capability of being a plug-in would not be of
paramount importance, while a well defined API would.

By well defined, I mean a very modular one where it is clear what are the
entry points, especially in those parts that now are quite entwined

If you'll let pass it, object orieantion (too use once again a much overused
cliche') would be a boon:
Add a new object? simple, derive a new object from the base object and fill
in the blanks.

Obviously, is not that simple: povray aims to be a real, practical,
ray-tracer, not an exercise in CG and programming theory.
Which is why expedients such as the area lights are not only legit, but
commendable: the implementation, which disregarded (purposefully, I
believe) an important part of the lighting calculation, nonetheless brought
to povray soft shadows.

When more processing power became commonplace, it wasn't easy to add a
feature that involved so much of the lighting code...adding it blindly
would have (IMHO) led to featuritis, without significant benefits.
I believe the pov team, wisely, let down the blinn shading for the same
reason:
there's little point in hacking in a feature, it is usually better delay it
until a rewrite of the foundations.

Photon maps are too an example of this: adding that led to a more complex
code, which would have benefit greatly from a rewrite, but implementing it
anyway let us test it and measure its limits.

Which is why I think that discussion on shortcomings and defects of povray
are valuable anyway, as misinformed as they may be...

Enuf....I feel I'm getting pedantic, apologies to all

Alex

Post a reply to this message

Alex wrote:
> 
> [...]
> 
> Which is why I think that discussion on shortcomings and defects of povray
> are valuable anyway, as misinformed as they may be...

No, valuable discussion about possible improvements of POV-Ray requires at
least some competence from those taking part.  I'm not talking about an
academic degree in CS but some basic knowledge about POV-Ray and
Raytracing.  Just whining about something in POV-Ray not working as you
expect it to do or criticizing that some feature you have read about in an
advertisement article for some commercial rendering system is not
available is not very productive.

Nobody says there is nothing to improve about POV-Ray, but talking about
'defects' and 'cheap hacks' isn't something that sounds very believable
from the mouth of someone who seemingly hasn't much experience with the
matter.

For example you say:

> Yes, you can and should test new objects meshing them, but it is very
> different than adding support for them: tracing directly a patch, for
> instance, leads to better texturing and less artifacts, opposed to tracing
> a b-rep of the patch.

Do you really think that that those of us using POV-Ray everyday, about
the only practically usable Renderer that supports both meshes and complex
not tesselated surfaces, need to be told about the advantages and
disadvantages of meshes?

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

Christoph Hormann wrote:
>Do you really think that that those of us using POV-Ray everyday, about
>the only practically usable Renderer that supports both meshes and complex
>not tesselated surfaces, need to be told about the advantages and
>disadvantages of meshes?

I said:
.... I'm getting pedantic, apologies to all...

I was pedantically reiterating the concept, I admit it.

I even managed to sound condescending....shame on me.

I just felt that ABX was missing my point. English is not my mother tongue
and I tend to get pompous when I write in English.

BTW, I always wanted to congrat you for the water tutorial.

Alex

Post a reply to this message