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

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