hi,

I've simply cut'n'paste your reply here.

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 9/11/20 9:29 PM, jr wrote:
> > "jr" <cre### [at] gmailcom> wrote:
> ...
> > two scenes actually fail for v3.8, but work for 3.7.  ...
> ...
> When you run, are you running v3.7 shipped scenes with v3.7 povray and
> v3.8 scenes with v3.8 povray? Some scenes are different v3.7 to v3.8 to
> fix issues or align with v3.8 changes.

no.  I understood CC to mean that one set of files gets compared with two
different executables.  only v3.7 '/scenes/' scenes are used.

> There are also new scenes in v3.8 where no comparison is possible. With
> these results should at least be run and looked over.

that would only mean replacing a few paths and the names of the executables,
more below.

at this point, as mentioned, it's v basic, no error handling, nothing, for now
I've simply .. thrown in a possible framework to see whether there's an use for
it.

> The allscene.sh script as I recall was not handling even all the v3.7
> base features and scenes, but been years since I was doing this sort of
> testing (when we pushed and dropped a v3.71).

the '/scripts/' stuff does not use the 'recommended' settings from the scene,
afaik.

> When I run comparisons I almost always run with one thread despite this
> being slow. Otherwise some results - radiostiy involved ones for example
> - can be quite different, same version and file, run to run.
>
> There is also the issues of all the jitter settings if you want to do
> detailed automatic comparisons - these jitters all need to be off in
> such cases. AA, area lights... Oh and you have to avoid some features
> like crand (subsurface?).

thank you!  will incorporate '-j' and think about '-wt'; optional perhaps?

there is no analysis of the (given) command-line options.  I'm thinking (and
would prefer) a simple UI utility to manipulate individual scene settings in the
database.
(directories can be enabled/disabled, which may be handy)

> A kind of testing I don't believe has been done for v3.8 (even in the
> v3.71 testing) - except maybe by Christoph - is to render to all the
> output file formats.

ok.

> Some of the outputs need a viewer (preferably not POV-Ray itself) which
> supports dithering and the higher bit depth outputs. Test here I guess
> would be do things look more or less OK output format to output format.
> We wouldn't need to run all the scenes for this testing. We might lean
> on one of the image packages to do conversions and comparisons, but
> running such programs can get pretty detailed if the outputs are not all
> linear.

that's for actual image compare.  there may also be milage in extracting
information from the output of, for instance, (ImageMagick) 'identify -verbose'.
 :-)

[v3.8 stuff snipped]

> Anyway. Please forgive the typos/breaks in thought. Rushing ahead of my
> first coffee.

looked productive to me.  :-)

> ...
> My last question is whether you are running the last v3.8 official
> pre-release or the master branch at last commit?

no, it's an 'unofficial' alpha.10064268.  re the below, would consider using a
more up-to-date version.

> There were fixes and other changes in the commits between the last
> official pre-release and what is in master today. Round about way to say
> we need to decide from what "commit" we are going to try and release. I
> think many of us are running code based off the last commit (Jerome, me,
> Dick?), but maybe most are running - can only run - the last pre-release?

again, although the scripts are (as yet) in no fit state, using a different
version of POV-Ray will only need changing a file name, and to use scenes
different from v3.7 also is just a matter of adjusting paths.  ideally those
data (names of exectuables, etc) ought to be in the db too; but then we'd need
to talk (re)design "properly".


regards, jr.

Post a reply to this message