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