...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