 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
Alain Martel <kua### [at] videotron ca> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"jr" <cre### [at] gmailcom> wrote:
> 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 ;-)).
The best thing, IMHO, is for someone knowledgeable in the area, or who has the
patience and tenacity to work it out - to write a script / macro whatever -
that takes the user input and properly outputs what will happen.
An accurate flowchart is a lot better than written documentation that has to be
interpreted.
In this case where there seems to be a lot of if/then/else, then a few lines of
code is worth 10 pages of documentation that the user still has to read,
interpret, comprehend, and then implement in their own code.
Don't document it. Write the code to DO the thing. Then anyone can understand
it, or barring that, make practical use of it.
- BE
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"jr" <cre### [at] gmailcom> wrote:
>
> > > [Kenneth wrote:]
> > > 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 ?)
"jr" <cre### [at] gmailcom> wrote:
>
> > > Kenneth wrote:]
> > > 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 ?
Sorry to say that I did not do much testing of 'target' behavior until now-- and
it is also a bit confusing to me.
Given that the docs say that the default for an object is 'target 1.0'-- which
should mean ON as I understand it (when *either* 'count' or 'spacing' is used in
the global photons block, both of which I tested) -- here are my current
parse/render results in both 3.7 and 3.8 beta 1. I used my test code posted
earlier.
photons{} -- an empty photon block-- the default for 'target' is actually OFF,
not ON.
With NO photons block in an object, the default is likewise OFF, not ON.
photons{target} -- neither 1.0 nor ON explicitly stated-- the object *is* a
photon target, as expected from the explicit use of the keyword
photons{target 1.0} or photons{target on} -- likewise ON as expected.
So it seems that the target default is OFF for an object-- unless I am
completely mistaken as the what 'default of target 1.0' means in the docs (other
than as an explicit 'spacing divisor').
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
"Kenneth" <kdw### [at] gmailcom> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > > > Kenneth wrote:]
> > > > 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 ?
>
> Sorry to say that I did not do much testing of 'target' behavior until now-- and
> it is also a bit confusing to me.
>
> Given that the docs say that the default for an object is 'target 1.0'-- which
> should mean ON as I understand it (when *either* 'count' or 'spacing' is used ...
"The keyword target makes this object a target." note, keyword alone.
<wiki.povray.org/content/Reference:Photons#Photon_Global_Settings>
as I wrote, the syntax diagram says 'target [float]', a value of '1.0' simply
ensures (I think) that "nothing changes" by default wrt photon spacing.
> ...
> So it seems that the target default is OFF for an object-- unless I am
> completely mistaken as the what 'default of target 1.0' means in the docs (other
> than as an explicit 'spacing divisor').
there isn't a photons "default" either w/out corresponding block, iiuc. unsure
how 'collect' plays with 'target', but, again aiui, 'refraction' and
'reflection' do not require the object to be a target.
also, fwiw, the documentation calls it a "spacing multiplier", rather than
"divisor". luckily, with '1.0', no difference :-).
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"jr" <cre### [at] gmailcom> wrote:
>
> "The keyword target makes this object a target." note, keyword alone.
> <wiki.povray.org/content/Reference:Photons#Photon_Global_Settings>
You're right about that. Although-- at the risk of sounding pedantic-- the
'default' block in the docs does not actually state it in an immediately useful
way. Instead, the only given default for target is 'target 1.0'. In my ideal
world, I wish it was clearer:
target: OFF when no explicit target keyword is specified
target spacing: 1.0
>
> as I wrote, the syntax diagram says 'target [float]', a value of '1.0' simply
> ensures (I think) that "nothing changes" by default wrt photon spacing.
Yes, that's my understanding as well, and tests confirm it.
> but, again aiui, 'refraction' and
> 'reflection' do not require the object to be a target.
Actually, an explicit 'target' *is* required (if my tests are any indication.)
In my test code earlier, in the photon blocks, use 'refraction on' in both the
light_source and the translucent box. Then comment-out 'target' in the
translucent box. The result: no refraction effects.
>
> also, fwiw, the documentation calls it a "spacing multiplier", rather than
> "divisor". luckily, with '1.0', no difference :-).
>
Ah, yes, you're correct. I was thinking in terms of 'number' of photons rather
than spacing:
target 0.5-- the spacing between photons is reduced by half...whereas the number
of photons is...either doubled or quadrupled(?)-- like spacing/2
(or spacing/4 ?)
Sorry for the confusion.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I had a window of time today, and set The AI to work on this.
I have diagrams and charts and flowcharts and code.
Still need to go through it all and test it out.
I can post or forward the zips if you'd like.
- BE
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
>
> I was thinking in terms of 'number' of photons rather
> than spacing:
>
> target 0.5-- the spacing between photons is reduced by half...whereas the number
> of photons is...either doubled or quadrupled(?)-- like spacing/2
> (or spacing/4 ?)
>
"...like spacing/2 or spacing/4" ???
Please ignore that bad analogy and arithmetic-- a result of 'over-thinking' :-[
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
"Kenneth" <kdw### [at] gmailcom> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> > I was thinking in terms of 'number' of photons rather
> > than spacing:
> > target 0.5-- the spacing between photons is reduced by half...whereas the number
> > of photons is...either doubled or quadrupled(?)-- like spacing/2
> > (or spacing/4 ?)
>
> "...like spacing/2 or spacing/4" ???
> Please ignore that bad analogy and arithmetic-- a result of 'over-thinking' :-[
no worries (hope that sort of thing doesn't keep you awake at night </grin>).
agree re the 'target', its description, will do that in the coming days. how do
you fancy "having a go" at turning the "Perfect Mirror" thread in to a "FAQ"
item ? (or a draft for an added "Tip" based on your observations ?)
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
"Bald Eagle" <cre### [at] netscapenet> wrote:
> I had a window of time today, and set The AI to work on this.
>
> I have diagrams and charts and flowcharts and code.
>
> Still need to go through it all and test it out.
> I can post or forward the zips if you'd like.
keep "us" in the loop please, wrt testing etc.
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"jr" <cre### [at] gmailcom> wrote:
> keep "us" in the loop please, wrt testing etc.
I have a lot of running around to do, so I'll only be able to sporadically play
with the output.
I'll post a zip of all the files that were generated, and maybe we can all
run/edit/debug the code, etc. and come up with something that makes sense.
One thing that I did was have it generate ALL the possible permutations of light
source and object, and I would suggest that part of the distribution be a scene
that renders all the permutations. That ought to put an end to any questions
about how povray actually operates.
- BE
Post a reply to this message
Attachments:
Download 'photons.zip' (1058 KB)
|
|
| |
| |
|
|
|
|
| |
|
|
