William F Pokorny <ano### [at] anonymousorg> wrote:

> Not yet. I'm still changing up how things are structured while working
> on new/changed functionality. Povr will be just the core code and work
> only on unix like systems - which probably makes it of no use to you?

I could use a console version if it builds on Windows Linux and Mac
I might even try it if it builds on Linux only, but I would consider that time a
waste in the long run, if crossplatform is not a goal.

> Already much of the windows stuff is gone.

If something remains to work with.  Minimalist is no problem.


> A possibility I guess would be posting a tar ball here on the newsgroups
> in the short term which folks could build themselves.
I imagine it could be only beneficial to it.

Post a reply to this message

On 6/15/20 7:34 AM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> On 6/14/20 8:48 AM, Mr wrote:
>>> William F Pokorny <ano### [at] anonymousorg> wrote:
>> ...
>>> Is there a way to play with this povr branch? I could'nt find it on github or
>>> online....
>> ...
>> I want to get rid of the ini system and move to just flags.
> 
> that would be a shame, I think.  personally, I find .ini files increasingly
> useful, as they allow me to quick render the wip with just "povray name", or
> (when it matters) "povray name[final]"; also, having multiple sections allows me
> to render the same image with different "environments", ie library_paths, so
> different versions of the same .inc files can be used.
> 

I'll think about this some more.

I don't myself use the ini system much beyond what's automatic - and the 
POVINI environment variable. My belief is in a *nux environment the 
usual shells / scripting languages and environment variables will do. 
It's how I mostly do things, but... ?

My thinking is losing the ini mechanism will simplify the code and 
documentation. Plus unix types are used to $PATH etc. Maybe I'm fooling 
myself though. Almost always once I get into something for real, it's 
more complicated than I imagined. :-)

Bill P.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 6/15/20 7:34 AM, jr wrote:
> > William F Pokorny <ano### [at] anonymousorg> wrote:
> >> On 6/14/20 8:48 AM, Mr wrote:
> >>> William F Pokorny <ano### [at] anonymousorg> wrote:
> >> ...
> >> I want to get rid of the ini system and move to just flags.
> >
> > that would be a shame, I think.  personally, I find .ini files increasingly
> > useful, as they allow me to quick render the wip with just "povray name", or
> > (when it matters) "povray name[final]"; also, having multiple sections allows me
> > to render the same image with different "environments", ie library_paths, so
> > different versions of the same .inc files can be used.
>
> I'll think about this some more.

you could always just mark it as 'deprecated'.  :-)

> I don't myself use the ini system much beyond what's automatic - and the
> POVINI environment variable. My belief is in a *nux environment the
> usual shells / scripting languages and environment variables will do.
> It's how I mostly do things, but... ?

I do not use the environment variable.  initially I thought that .ini files are
useful only for animations, but have since come to appreciate them for other
uses.

you're right, I guess, that with BASH, awk, Tcl, etc, everything seems to be ..
well catered for.  still, the .ini, being "specialist" for the application, has
its place, imo.

> My thinking is losing the ini mechanism will simplify the code and
> documentation. Plus unix types are used to $PATH etc. Maybe I'm fooling
> myself though. Almost always once I get into something for real, it's
> more complicated than I imagined. :-)

I guess that you not being a user of .ini files does not help.  :-)  perhaps, as
Bald Eagle suggested else-thread, a poll of actual and potential users, asking
their opinion on (desired) features/functionality?

(there's an .ini file processing utility in tcllib1.18.  ;-))


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:

> I guess that you not being a user of .ini files does not help.  :-)  perhaps, as
> Bald Eagle suggested else-thread, a poll of actual and potential users, asking
> their opinion on (desired) features/functionality?


I don't use them either, except for animations, and only then because - that's
the way it works.

I would much rather have a way to have everything contained in one scene file
rather than in multiple files.  A temporary working ini file could be
constructed to run the animation and store whatever persistent stuff is needed
across all frames.

I'm also a fan of multiple ways of performing the same task.
So, leaving .ini alone, I'd say the same functionality should be available from
within the .pov file.
But I mean, that's my personal preference, and things that I expect to see in
commercial software.  And something that MS messes up on a regular basis.

I'd like to see the "command line options" capable of being invoked from within
the .pov file as well.

And, it's tough, with the way that POV-Ray is, and the way the files and
primitives are structured, and the way a scene has to be parsed and then
rendered - it limits what is possible and what is practical.

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> ...
> I would much rather have a way to have everything contained in one scene file
> rather than in multiple files.

that, for example, would make (CLI or .ini) uses like 'declare=N=2' and such
impossible.  personally, I frequently benefit from that flexibility.


regards, jr.

Post a reply to this message

"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

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