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
>



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:


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:



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