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,
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
> 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,
> 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
(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.
> 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
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".
Post a reply to this message