Thomas de Groot <tho### [at] degrootorg> wrote:

> Alain is absolutely right. He is the one person warning us, again and
> again, for the method/intervals/samples misconception cropping up
> regularly in these ng's. Hail to the chief! ;-)
>
> As for the docs, samples LesserInteger, GreaterInteger, is only valid
> for method 1 and 2. I agree that there is an ambiguity where method 3 is
> concerned: paragraph 2.7.2.3 Sampling Parameters & Methods in the wiki (
> http://wiki.povray.org/content/Reference:Sampling_Parameters_%26_Methods
> ) does not state clearly that the second term is ignored when using
> method 3. This should be changed.

Well, this is something (the type of thing) that I think ought to be addressed
in a more explanatory, demonstrable way - especially for new users or people who
have never used media, or (like myself) who never use media - because it's
complicated enough to wind up turning into a huge debugging time-sink.
A POV-Ray feature ought to be a _tool_ not a stumbling block or independent
research project.

No one's fault - not casting aspersions or assigning blame - it's just the
present state of the current version. (and with a little more work, I could get
that to sound downright poetic...)

I think that with something like POV-Ray, which is driven primarily by
user-written SDL (as opposed to GUI / modeling interface) there needs to be a
mechanism by which directives, or at least the desired ones, can be unsilenced.
If a "local" flag could be added as part of something like a media statement,
like:
media {
....
....
show_messages
}

then it would tell you everything about what was going on under the hood that it
_could_ tell.

Stream output might look like:
"Media (method 3): using a samples value greater than 1 [default] may
dramatically increase render times and result in artefacts"

"Ignoring second value for samples"

"media set to interval 1: ignoring confidence and variance values"

If a GLOBAL flag could be added - say as part of the global_settings block of
code, then it would trigger those messages for all such message-providing
directives in the current scene.  It would probably be prudent to be able to
selectively disable and re-enable that feature so that all of the directives in
#include files could be excluded, and then successfully debugged sections of
code could be excluded, thereby facilitating progressive debugging by
process-of-elimination.

Until such a time as that happens, I'd say that rather than answering the same
type of questions over and over and over again (and I for one, am very grateful
to ALL of the knowledgeable and patient folks here who do that)
perhaps a sample scene could be constructed that allows such a thing to take
place, using #declare[d] flag variables and macros, very much like is done in
the guts of the screen.inc file for camera and screen positions.

There are, I think, a lot of instances where the checking of some attribute or
value, and the resulting message sent to an output stream would save hours of
frustration, and that adds up to a lot when multiplied by multiple scene files
and multiple users writing that SDL.
It also makes it MUCH more NEW-User-friendly.
I understand that such checks, if embedded into the code, would slow down render
times, but that's why they should be activated and deactivated by such flags -
they'd only be used when desired or needed.

Because as much as I like to pursue my own ideas and experiments, I believe that
I ought to give something back, in terms of [trying to] help, and making POV-Ray
better - more accessible, easier to use, and more responsive to the user.  And I
believe that the best way to do that is with an integral, automated feedback to
the user from within the software, or the scene.  Why should the onus be on the
[new] user to go look something up (if they even know what to look up or if an
issue exists that needs to be looked up) and decipher the explanation, when the
code already can calculate the presence of a potential issue and display a
[comprehensible] and meaningful message?


I could see this type of philosophy being useful for issues that continually
crop up such as:

No light source
no camera
coincident surfaces - "one or more bounding box faces are coincident"
near-coincident surfaces - "one or more bounding box faces are within 1e-6
POV-units...."
difference - "one or more bounding box faces of differenced object is equal to
or smaller than parent object"
#declared object definitions that are never instantiated with object {}
Objects that are outside the camera view frustum (presumably this would equate
to ray-object intersections = 0)

I'm sure I could go on, and much of this will probably never find its way into
official POV code, but having an alternate version whose function is primarily
to build and debug a scene, rather than render it with the image quality that
the official code does could be a huge time-saving tool.
Then the resulting SDL could be rendered at full quality with POV-Ray-proper.

Also, based on my reading of the Graphics Gems series, maybe there could be some
options to choose lower-accuracy but much higher speed calculations so that
rough scene-building could be rendered faster (different than Quality settings)
this would be used for slow calculations like sqrt(), certain isosurface
functions, root solving, trig functions, etc.
Some of these rely on pre-calculated look-up tables, etc.


Kenneth - I think you're doing a great job with your methodical media
experiments, and it would be great to see some scenes that show the results of
your comparative studies.   Grids of media cubes against different backgrounds,
and overlapping media, with captions.  I would strongly suggest that if you do
the work tyo make such scenes available, that they be included as part of the
example scenes provided with the next distribution.

:)

Post a reply to this message