|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"jr" <cre### [at] gmailcom> wrote:
> that, for example, would make (CLI or .ini) uses like 'declare=N=2' and such
> impossible.
I don't know what that does, and that may be true with the current way
everything functions.
If WP is going to change things, then I see no reason why something like
CLI_settings {all your CLI / ini stuff}
couldn't serve the same purpose.
And THAT could have the same ifndef functionality where things already declared
outside of the file - in CLI or ini - would preclude redefinition in the
CLI_settings {} block.
> personally, I frequently benefit from that flexibility.
Not using that method of running POV-Ray, I'd need to see a specific use example
where a separate file would be necessary. Like I said - maybe not necessarily
get rid of it, but complement it with an in-SDL method to accomplish the same
thing.
If there was a way that POV-Ray could read from inside of an uncompressed
archive file, then we could tie interconnected files together so as to not
inadvertently separate them, yet still be able to read/edit them.
Apparently tar does this.
https://stackoverflow.com/questions/9516365/create-a-zip-archive-without-compression
https://stackoverflow.com/questions/430973/create-zip-style-file-without-compression
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > that, for example, would make (CLI or .ini) uses like 'declare=N=2' and such
> > impossible.
>
> I don't know what that does, and that may be true with the current way
> everything functions.
say you have a number of .. knobs which change things in a scene, like having
radiosity enabled or disabled, eg
#if (1 = Rad)
// the radiosity stuff.
#end
then, either on the command-line or in an .ini, you could
declare=Rad=1
to enable radiosity for (just) that render, w/out needing to edit the scene.
can't have strings, ie 'declare=X="foo"' won't work, still, v useful.
> ...
> If there was a way that POV-Ray could read from inside of an uncompressed
> archive file, then we could tie interconnected files together so as to not
> inadvertently separate them, yet still be able to read/edit them.
> Apparently tar does this.
+1. bundling up all project scene/inc/image/etc files in a single container,
and POV-Ray "mounting" them as virtual file systems, would be extremely neat.
(one for version 5.x. :-))
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
William F Pokorny <ano### [at] anonymousorg> wrote:
> ....
> Dump the inbuilt benchmark. ...
popped into my head this morning. :-) occurs to me that not only is having
this benchmark "nice", even if only for own information, it is also, in a sense,
a convenient and built-in 'make check' equivalent. so I think that unless
there's an explicit 'make check' which exercises the build, the '--benchmark'
(too) ought to be kept.
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
From: William F Pokorny
Subject: Re: Function / pattern issues. Povr supertoroid parametric.
Date: 21 Jun 2020 11:13:57
Message: <5eef7935$1@news.povray.org>
|
|
|
| |
| |
|
|
On 6/21/20 5:14 AM, jr wrote:
> hi,
>
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> ....
>> Dump the inbuilt benchmark. ...
>
> popped into my head this morning. :-) occurs to me that not only is having
> this benchmark "nice", even if only for own information, it is also, in a sense,
> a convenient and built-in 'make check' equivalent. so I think that unless
> there's an explicit 'make check' which exercises the build, the '--benchmark'
> (too) ought to be kept.
>
There is today an explicit 'make check' which uses the advanced
directory biscuit scene(1). I'm thinking about changing 'make check' to
something much simpler like a sphere on a checkered plane. I don't think
there is any reason for a more complete scene for the 'make check'
functionality.
(1) - Running in a mangled way for my povr compiles at present.
The current inbuilt benchmark amounts to wrappers around the scene
directory benchmark scene and ini files. Plus, it looks to me, 4 font
files which exist in the include directory get wrapped too. These are
the inbuilt fonts text{} can use. I think the whole idea is to let the
benchmark types at whatever news publication run the benchmark without
an actual install. The wrapped/c++ encapsulated stuff gets written out
to files for the --benchmark. Not sure where written at the moment. I've
looked at little at the encapsulation side, but not how it actually runs.
In any case, as done it amounts to a significant duplication of files.
Nothing really against it, other than it being something more which must
be maintained and that it takes around 700K (6.5% of povr today) of
source code space.
Aside: The current benchmark scene could be made more representative -
or perhaps their should be several benchmarks. Last I profiled the
benchmark was, time wise, 65% or more noise(NG 1) and media.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
William F Pokorny <ano### [at] anonymousorg> wrote:
> On 6/21/20 5:14 AM, jr wrote:
> > William F Pokorny <ano### [at] anonymousorg> wrote:
> >> ....
> >> Dump the inbuilt benchmark. ...
> >
> > popped into my head this morning. :-) occurs to me that not only is having
> > this benchmark "nice", even if only for own information, it is also, in a sense,
> > a convenient and built-in 'make check' equivalent. so I think that unless
> > there's an explicit 'make check' which exercises the build, the '--benchmark'
> > (too) ought to be kept.
>
> There is today an explicit 'make check' which uses the advanced
> directory biscuit scene(1). I'm thinking about changing 'make check' to
> something much simpler like a sphere on a checkered plane. I don't think
> there is any reason for a more complete scene for the 'make check'
> functionality.
see below.
> The current inbuilt benchmark ... Not sure where written at the moment. ...
/tmp/
> ...
> Aside: The current benchmark scene could be made more representative -
> or perhaps their should be several benchmarks. Last I profiled the
> benchmark was, time wise, 65% or more noise(NG 1) and media.
agree, as long as this, and or the 'make check', utilise a good cross-section of
the functionality, they should that and no more.
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|