Alain <kua### [at] videotronca> wrote:

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

Depends on how many media statements you have, and where they're located.
One can have an include file (which presumably works as it's 'supposed to'.
One can have a media statement that you're currently debugging.
One can have a freshly written SDL file with multiple media statements that you
want to be checked, and then progressively exclude them as they are verified as
working correctly.
Then the global switch could be flicked off to have the parser skip all of the
individual checks.


> > "Media (method 3): using a intervals value greater than 1 [default] -may-
> > dramatically increase render times and result in artefacts"
> Not «may» but «will»

So then maybe put that in all caps with asterisks:  *** WILL ***   ;)


> > No light source
> May be intentional. Common in radiosity scenes.

Indeed, but when a message is issued, it's easy to look at it and know that it's
superfluous, whereas in the absence of a message, it's hard to tell that
something you're assuming exists actually doesn't.

> > no camera
> In this case, the default camera is used, but yes, a warning may tell
> "default camera in use"
Yes.

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

Well this is just a first approximation of how it could work, and it's just
meant as a helper / reminder, than to be an omniscient automated debugger.

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

Well, yes.  I knew that as I was writing it, but it might be meaningful for the
very new users who are doing simple test scenes.  Something that is easily
triggered by false positives would an excellent place to have a default = off,
and then it would only be used if intentionally enabled.

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

Yes, many things may be intentional - but the point is not to declare the
situation as a bona fide error - but pick it up and point it out just in case
it's something that's missed through haste or inattention, etc.

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

Of course, I had thought of that as well, but those are peripheral cases.
The point here is to address a case where a user may be programming a scene and
be very frustrated about why they can't see it.  And of course, if it's not in
the view frustum, then that's something worth knowing, rather than trying to
debug an isosurface statement because you thought it was something in the math
or the settings, rather than it's just in the wrong location.



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

I'm sure I may be using outdated information - but I've seen numerous people
point out that it's better to compare two "squared" values, than compare two
square-roots, because it's faster, especially if there's a LOT of those checks
being done in the code.
"Quite fast" can always be faster, especially if it helps one to write better
code, and if such calculations are being performed millions, or in the case of
nested or recursive code - billions of times.

Perhaps some things are good ideas, perhaps some are appropriate only for new
users, but I could see them being useful, since I've seen - and done myself -
simple errors that wasted hours or days of debugging until the issue was solved.
 It's always easy once you know what's wrong, and it's always obvious in
hindsight.

But I thought I'd get the ball rolling - and then perhaps others might start
thinking along those lines, and come up with more and better suggestions, and it
would get their minds into the habit of looking for those instances in their own
code, and they'd be much better debuggers for it.

Post a reply to this message