<---------------------- References. Thirteen previous posts

Function / pattern issues. New inbuilt f_bump().
http://news.povray.org/povray.beta-test.binaries/thread/%3C5ee4dc4b%241%40news.povray.org%3E/

and

Function / pattern issues. New inbuilt f_elliptical_sphrswp().
http://news.povray.org/povray.beta-test.binaries/thread/%3C5ee529b9%241%40news.povray.org%3E/

I posted code to povray.text.scene-files for a parametric supertoroid 
which will run in POV-Ray proper:

http://news.povray.org/povray.text.scene-files/thread/%3C5ec01b20%241%40news.povray.org%3E/

Herein documenting better povr code for it which runs about four times 
faster.

The new povr code looks like:

...
#declare Vrx  = 0.1;
#declare Vry  = 0.1;
#declare Vrz  = 0.1;
#declare VrAx = 0.9/Vrx;  // Major radius in x dived by Vrx.
#declare VrBy = 0.2/Vry;  // Major radius in y dived by Vry.
#declare VrE1 = 1.0;  // Flat / Sharp
#declare VrE2 = 1.0;  // Square or Diamond path
#declare VrMajorR = max(Vrx+VrAx,Vry+VrBy,Vrz);

#declare FnX = function (u,v)
{
     Vrx * (VrAx + f_signpow(cos(u),VrE1,VrE1)) *
                   f_signpow(cos(v),VrE2,VrE2)
}
#declare FnY = function (u,v)
{
     Vry * (VrBy + f_signpow(cos(u),VrE1,VrE1)) *
                   f_signpow(sin(v),VrE2,VrE2)
}
#declare FnZ = function (u,v) { Vrz * f_signpow(sin(u),VrE1,VrE1) }

#declare Para99 = parametric {
     function { FnX(u,v) }
     function { FnY(u,v) }
     function { FnZ(u,v) }
     <-pi,-pi>, <pi,pi>
     contained_by { box { <-VrMajorR*2.2,-VrMajorR*2.2,-VrMajorR*2.2>,
             <VrMajorR*2.2,VrMajorR*2.2,VrMajorR*2.2> } } // Sloppy
     accuracy 0.0005
     max_gradient 0.001
     precompute 18, x,y,z
     pigment { color Green }
}
...

here the bounding still general. The elapsed times for each of the 
attached images was in the 2-3 second range with AA on my two core i3.

It's a flexible shape.

Bill P.

Post a reply to this message

Attachments:
Download 'storyparasupertoroid.jpg' (121 KB)

Preview of image 'storyparasupertoroid.jpg'

William F Pokorny <ano### [at] anonymousorg> wrote:
> <---------------------- References. Thirteen previous posts
>
> Function / pattern issues. New inbuilt f_bump().
>
http://news.povray.org/povray.beta-test.binaries/thread/%3C5ee4dc4b%241%40news.povray.org%3E/
>
> and
>
> Function / pattern issues. New inbuilt f_elliptical_sphrswp().
>
http://news.povray.org/povray.beta-test.binaries/thread/%3C5ee529b9%241%40news.povray.org%3E/
>
> I posted code to povray.text.scene-files for a parametric supertoroid
> which will run in POV-Ray proper:
>
>
http://news.povray.org/povray.text.scene-files/thread/%3C5ec01b20%241%40news.povray.org%3E/
>
> Herein documenting better povr code for it which runs about four times
> faster.
>
> The new povr code looks like:
>
> ...
> #declare Vrx  = 0.1;
> #declare Vry  = 0.1;
> #declare Vrz  = 0.1;
> #declare VrAx = 0.9/Vrx;  // Major radius in x dived by Vrx.
> #declare VrBy = 0.2/Vry;  // Major radius in y dived by Vry.
> #declare VrE1 = 1.0;  // Flat / Sharp
> #declare VrE2 = 1.0;  // Square or Diamond path
> #declare VrMajorR = max(Vrx+VrAx,Vry+VrBy,Vrz);
>
> #declare FnX = function (u,v)
> {
>      Vrx * (VrAx + f_signpow(cos(u),VrE1,VrE1)) *
>                    f_signpow(cos(v),VrE2,VrE2)
> }
> #declare FnY = function (u,v)
> {
>      Vry * (VrBy + f_signpow(cos(u),VrE1,VrE1)) *
>                    f_signpow(sin(v),VrE2,VrE2)
> }
> #declare FnZ = function (u,v) { Vrz * f_signpow(sin(u),VrE1,VrE1) }
>
> #declare Para99 = parametric {
>      function { FnX(u,v) }
>      function { FnY(u,v) }
>      function { FnZ(u,v) }
>      <-pi,-pi>, <pi,pi>
>      contained_by { box { <-VrMajorR*2.2,-VrMajorR*2.2,-VrMajorR*2.2>,
>              <VrMajorR*2.2,VrMajorR*2.2,VrMajorR*2.2> } } // Sloppy
>      accuracy 0.0005
>      max_gradient 0.001
>      precompute 18, x,y,z
>      pigment { color Green }
> }
> ...
>
> here the bounding still general. The elapsed times for each of the
> attached images was in the 2-3 second range with AA on my two core i3.
>
> It's a flexible shape.
>
> Bill P.

Is there a way to play with this povr branch? I could'nt find it on github or
online....

Post a reply to this message

On 6/14/20 8:48 AM, Mr wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
...
>> Herein documenting better povr code for it which runs about four times
>> faster.
>>
>> The new povr code looks like:
...
> 
> Is there a way to play with this povr branch? I could'nt find it on github or
> online....
> 

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?

Already much of the windows stuff is gone. The html documentation, scene 
fies are no longer part of povr. All the windows libraries that make the 
existing repository so large are gone.

The include directory I plan to severely prune, but I'll keep the 
include files which are closely code related. Includes like 
functions.inc, math.inc etc will stay. Things like colors.inc etc and 
anything else in there not current with v38 will not be part of the core 
povr repository.

I believe even in POV-Ray we should move to a code repository model 
which is much less monolithic. A github repository for scene files, one 
for documentation, one for includes and one for the code.

I want to get rid of the ini system and move to just flags. Dump the 
inbuilt benchmark. And much more.

Long winded way of saying I'm not yet ready to initialize a new 
repository in my own space which I could post on github.

A possibility I guess would be posting a tar ball here on the newsgroups 
in the short term which folks could build themselves.

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> Includes like
> functions.inc, math.inc etc will stay. Things like colors.inc etc and
> anything else in there not current with v38 will not be part of the core
> povr repository.

Let me just say that I'm a fan of the military mindset of "if it's detachable,
you'll lose it."
We all have some inc file that has been lost on someone's HD or only ever
existed on a now-defunct hosting site (Geocities, etc)
Things like functions and vectors and math seem so integral to the operation (at
least for me) that I'd think part of the restructuring would be to move the
externally loaded and implemented inc file code into the source where it is
always accessible and orders of magnitude faster.

> I believe even in POV-Ray we should move to a code repository model
> which is much less monolithic. A github repository for scene files, one
> for documentation, one for includes and one for the code.


For all of the ancillary material, I would vote for something:
1. easily maintained, and maintainable by several people
2. easily accessible.
      (POV-Ray already has a steep learning curve, and requiring people to then
learn git might be too much)
3. Easily indexed and cross referenced.
      (I would love a way to better search the archives for inc and scene files
based on certain topics, keywords, etc.)

Web-based searching and indexing immediately comes to mind simply because it's
so widespread and so many people can code that stuff in little time.   Not
saying that's THE way to do it - but making it compatible/friendly to that
approach would be a good thing to do from the start.

Maybe take a poll of the problems people have experienced in the past with all
manner of POV-Ray things, and use that as a guide for "Well, we certainly don't
want to do THAT again..."

Post a reply to this message

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.

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

please do.  :-)


regards, jr.

Post a reply to this message

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