<---------------------- 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