Le 17-09-03 à 10:36, Bald Eagle a écrit :

> 
> 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
> }
The global_settings would probably be a better place for such a switch.

> 
> 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 intervals value greater than 1 [default] -may-
> dramatically increase render times and result in artefacts"
Not «may» but «will»

> 
> "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.
Most of those can be found at parse time. Those can't affect render 
speed, and only very slightly affect parse time.

> 
> 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
May be intentional. Common in radiosity scenes.
> no camera
In this case, the default camera is used, but yes, a warning may tell 
"default camera in use"
> 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...."
Those two are exedingly hard to detect. Even when the bounding boxes 
test positive to your critera, there may be no coincident surfaces, and 
you may have some in other cases when the bounding boxes are farther away.

> difference - "one or more bounding box faces of differenced object is equal to
> or smaller than parent object"
That case is so common that the message will be meaningless. You can 
easily have several big objects chopping bits of a small object, like 
planes cutting off parts of something, or many small objects carving 
dimples into a larger object...

> #declared object definitions that are never instantiated with object {}
Good one, but may be intentional, like the case of an intermediate 
object, or an object used as a building block for another complexe object.

> Objects that are outside the camera view frustum (presumably this would equate
> to ray-object intersections = 0)
What about objects visible only through reflection or refractions ?
What about out of view objects in a radiosity scene. You can't see them, 
but they can have an important effect.

> 
> 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.
> In modern CPUs, the FPU native accuracy is double precision. Using 
single precision probably won't be faster. I don't think that there is a 
way to split the FPU so tha tit can perform two single precision 
calculations at the same time.
sqrt and trigs funtions are native operations of your FPU and quite 
fast. Using a look up table could be couterproductive due to the space 
needed to store them all in memory. If your look up table ever get 
pushed to the page file, it's retreival will take far more time than 
doing the calculations.

Post a reply to this message