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

In the last 24 hours, I was thinking that the pov developers did a great
thing, they just chose an unfortunate name.

It's reasonable for someone to hear "Area Lights" and then see that diagram
from the 3.1g manual and make the same mistake as John has. (I did, too).

The armchair quarterback in me says it should have been called
"soft_shadow_option= yes;"  or something like that.

Post a reply to this message

"ABX" <abx### [at] abxartpl> schreef in bericht
news:acfumu48ldl5qku5cjm1e4govavtovr27g@4ax.com...
> 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 ;-)

SHIFT HAPPENS
:)

whoops :)

cu!
--
camera{location-z*3}#macro G(b,e)b+(e-b)*(C/50)#end#macro L(b,e,k,l)#local C=0
;#while(C<50)sphere{G(b,e),.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1
;#end#end L(y-x,y,x,x+y)L(y,-x-y,x+y,y)L(-x-y,-y,y,y+z)L(-y,y,y+z,x+y)L(0,x+y,
<.5,1,.5>,x)L(0,x-y,<.5,1,.5>,x)               // ZK http://www.povplace.be.tf

Post a reply to this message

Hey,

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

I'm sorry if you feel the need to resort to aggressive posts, it was never
my intention to get people riled. I am aware that no one is forcing me to
use arealights, but that doesn't mean that I'm not allowed to suggest that
the feature could use some improvement and revision. That is after all the
way in which growth and development occurs, and I would very much like to
see Povray grow and develop in a very positive way.

As I have mentioned in at least two other posts in this thread, I personally
haven't found massive overheads using the point light arrays, and I do
intend to keep using and developing my macro (I'm toying with the idea of
letting the user specify an imagemap to colour each point light, and also
the idea of using eval to work out when a light is inside an object or not -
hello object_lights ;)). I enjoy the area based illumination it provides as
it's primary function, as well as the soft edged shadows it produces as a
side effect.

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

I think you misunderstand; the complex test I was talking about (read my
post to Jaime again) is *not* one of the ones I used in the article. Come
on - the article test were just two spheres and two planes, give me a
*little* credit please ;)

The test I was talking about has not been posted anywhere, it was just a
test I did for myself while developing my macro. It involved an 11mb mesh
with variable reflection, and a large red sphere, also with variable
reflection. The were a lot of inter-reflections between the sphere and the
mesh, where each was reflecting each other over and over. 640x480 with 600
point lights, "+r9 +a0.0" and fairly high quality radiosity (count 200,
error_bound 0.5, recursion_limit 3, low_error_factor .5, minimum_reuse 0)
thrown in for good measure. I rendered it on a middle-of-the-road machine, a
600mhz P3 laptop, which was in use during the render. Render completed in
just a little over two and a half days which, given the number of
calculations in the scene, I think was fairly quick, especially considering
the lovely result. I can post the stats and the image if you like.

Now, by complex test, I don't mean a work of art, or anything pretending to
be a "real" scene - by complex I mean very heavy duty in terms of what I was
asking Povray to do. That includes both the scene and settings used for the
render.

I would hope that in future you think about what you write before you call
someone inexperienced and ignorant.

All the best,


John

Post a reply to this message

news: 3d6fb27b@news.povray.org...
> The test I was talking about has not been posted anywhere, it was just a
> test I did for myself while developing my macro. It involved an 11mb mesh
> with variable reflection, and a large red sphere, also with variable
> reflection.

While the combination of reflection and radiosity explains much of the
render time, a scene containing 2 of the simplest, fastest-rendering objects
(*) in POV-Ray hardly qualifies as a good scene to test lighting issues,
particularly with regard to the speed issue, which is a fundamental factor
here.
I suggest that you test your solution (if you haven't done so yet - I may
not have read all the posts in this thread) on the benchmark scene, which
uses area_lights, and report the results here.

G.

 (*) unless your mesh textures involves transparency and superposed layers
of polys, like some Poser hair

--
**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

Post a reply to this message

John Mellerick wrote:
> 
> I'm sorry if you feel the need to resort to aggressive posts...

I haven't, yet.

> I am aware that no one is forcing me to
> use arealights, but that doesn't mean that I'm not allowed to suggest that
> the feature could use some improvement and revision.

And if you have any practical suggestions, then by all means, present 
them. So far, all I've seen out of you is some tests demonstrating that 
when rendering time and memory are no object, an array of point lights 
does a better job of simulating a diffuse light source than a feature 
with no purpose other than making soft shadows.. something which I think 
most of us already knew.

> Come on - the article test were just two spheres and two planes, give me a
> *little* credit please ;)

What exactly should I give you credit for, and why?

The impracticality of light arrays has been reported and confirmed by a 
number of people who are long-time posters here. We can accept that they 
know what they're talking about. But in your case.. does anyone know who 
you are? I certainly don't remember seeing your name before this thread. 
If you want to challenge the notion that light arrays are impractical, 
you should provide such proof as is necessary to disprove everyone who 
has come before you.

> Now, by complex test, I don't mean a work of art, or anything pretending to
> be a "real" scene - by complex I mean very heavy duty in terms of what I was
> asking Povray to do. That includes both the scene and settings used for the
> render.

There's nothing particularly complex about the scene you described at 
all, *except* for the light array, which doesn't count!

-Xplo

Post a reply to this message