hi,

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

> > Cousin Ricky <ric### [at] yahoocom> wrote:
> >> My results are the same with versions 3.5, 3.6.1, 3.7.0.10, and
> >> 3.8.0-beta.2, all on GNU/Linux.
> >
> > So at this late date, the bigger questions are:
> >
> > 1) What should be done about the documentation concerning the defaults?
> >
> > Given that the behavior is a complicated situation, it seems to me that the most
> > expedient 'fix' would be to issue a warning (of *some* kind)-- in both the docs
> > and during a render.  Something like:
> >
> > "Due to a long-standing quirk in the photons code, be aware that these default
> > values may be overridden and cause unexpected results. Best practice would be to
> > use explicit photon blocks and on/off keywords in your scenes."

so, it all started with radmac's "Perfect Mirror" question.  and looking at the
discussion since, it seems not so much about which feature(s) have which
default(s), but more about the interaction of various features when (not)
explicitly using the keywords and "qualifiers".

the documentation of photons includes both a FAQ and "Tips".  so, eg, the radmac
question (rephrased perhaps) and a precis of the answer/issues, could make a
"fine" entry in the FAQ, and a new Tip could be added wrt explicit use of
keywords (or "why not to rely on defaults" :-)).


> > 2) Should an attempt even be made to correct the underlying code, to bring it
> > into strict compliance with the stated defaults (given that these quirks have
> > been around 'since the beginning of time')? Doing so might alter the outcome of
> > *many* older scenes. However, there are precedents for such a large change: for
> > example, the 'emission' keyword (and its message warning about a too-high
> > ambient value); and radiosity now automatically turning off 'ambient' light.
> > These two changes also required older scenes to be edited.

no :-).  an addendum (addenda, really) to the documentation would be my
preference.


> > BTW:
> > I think that the docs'  'target' default of 1.0 also needs a small
> > clarification, since a numerical value is only meant to apply when 'spacing' is
> > used in the global photos block.  Of course, the 1.0 value  also works when
> > 'count' is used instead-- but as just a Boolean operator in that case(?)-- and
> > incrementally changing the float value has no effect.
> >
> > However, a simple 'on' can also be used, again in either case... but the docs
> > don't mention it.

well, 'target [float]' is documented.  it would be nice if a future parser/SDL
was free from those aspects.


> > Would these be more appropriate for the docs' default?:
> > target 1.0     When 'spacing' is used in the global photons block
> > target on     When 'count' is used in the global photons block

why 'on' ??  (do you actually want to add further "ambiguities" to the parsing ?
:-))


> The value after target have an effect on the density of the photons for
> the target object.
>
> Even when using count, target 0.5 should cause that object to receive 4
> times as many photons compared to target 1/on/true. When using count,
> this only have an effect when there are at least two target objects.
>
> Useful when one object is very simple, like a simple box, and the other
> have a complex geometry, like a faceted gem.

am open to, and interested in, concrete suggestions to improve the photon
documentation, wrt the "interplay" of features, and all touched on in these two
threads; posted here or sent (pls use "helpful" subject line ;-)).


regards, jr.

Post a reply to this message