Please find attached an updated tarball.

Attempting no lower case #declare, #local identifier idea. Hope is 
user's function and macro arguments made _<lower case> form will be 
immune to name collisions.

With a thought toward eventual real time modeling, continuous real time 
rendering enabled as it has been in window's versions since v37. Added a 
rtr_kla.pov sample scene for the feature.

The rtr_kla.pov scene implements an alternative to the persistent 
keyword marking idea of uberpov. While the continuous / real time 
rendering only supports multiple camera positions today, multiple frames 
can be rendered with one scene parse where more than the camera changes.

The idea is to create multiple fixed sets in which changes are made and 
where a camera is appropriately placed in each. Mentally one must, of 
course, still keep track of what is persistent and what is not, but we'd 
not need a new keyword and the code infrastructure behind it - supposing 
eventual frame capture capability. Simpler, perhaps, to look at the 
sample scene to get the idea.

Corrections to the DOINGMAKECHECK=YES build implementation - thanks jr.

I've not seen an x11 display issue in the week since adding the 
XInitThreads() call - thanks jr. Thinking of making x11 the default as 
it's windowing behavior is more consistent with my Ubuntu environment.

Added an inbuilt f_toupie() function supporting 1-15 as integer 
exponents where f_toupie() usually uses 3. Provides for a range of 
shapes lemon like, torus like (exactly the torus at 2), toupie like and 
button-ish shapes.

Bill P.

Post a reply to this message

Attachments:
Download 'povray2_f6b1c13e.tar.gz' (1636 KB)

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> Please find attached an updated tarball.

thanks.  compiles.  will properly make + install sometime later this week.

one thing I noticed, 'povr' links against an older version of libpng, unlike the
"stock" POV-Ray.

jr@swift:13:~$ ldd /usr/local/bin/povray-3.8.0-alpha.10064268
    ...
    libpng16.so.16 => /usr/lib64/libpng16.so.16 (0x00007f6cc19c5000)
    ...
jr@swift:14:~$ ldd POVr/bin/povray2
    ...
    libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x00007fb50195f000)
    ...
jr@swift:15:~$

the updated version too links to 1.2.50, when 1.6.37 is available.

> Attempting no lower case #declare, #local identifier idea. Hope is
> user's function and macro arguments made _<lower case> form will be
> immune to name collisions.

(crestfallen..)  hope 'a_' will be as acceptable as '_a'.

> ...
> I've not seen an x11 display issue in the week since adding the
> XInitThreads() call - thanks jr. Thinking of making x11 the default as
> it's windowing behavior is more consistent with my Ubuntu environment.

+1.  :-)


regards, jr.

Post a reply to this message

On 7/20/20 8:54 AM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> Please find attached an updated tarball.
> 
> thanks.  compiles.  will properly make + install sometime later this week.
> 
> one thing I noticed, 'povr' links against an older version of libpng, unlike the
> "stock" POV-Ray.
> 
> jr@swift:13:~$ ldd /usr/local/bin/povray-3.8.0-alpha.10064268
>      ...
>      libpng16.so.16 => /usr/lib64/libpng16.so.16 (0x00007f6cc19c5000)
>      ...
> jr@swift:14:~$ ldd POVr/bin/povray2
>      ...
>      libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x00007fb50195f000)
>      ...
> jr@swift:15:~$
> 
> the updated version too links to 1.2.50, when 1.6.37 is available.

Interesting find. :-) Unsure why you see a difference in library used.

It's my understanding when there are multiple versions of a library in 
place on a system there is usually a sym link established from a generic 
name to the 'official' one for the particular linux distribution. It 
would be normal then for the official distribution version to be picked 
up first. This is not necessarily the newest (or oldest) one if you have 
multiple development library versions on a system(1).

(1) - Not all that common, but certainly happens. I have only one libpng 
version on my Ubuntu 18.04 system.

There are certainly ways to override which library gets picked up 
explicitly. Hmm, wonder, if you've got multiple libraries and no symlink 
to a version-less name like libpng.so.1 I'm unsure how one library would 
be picked over another? Do you have the common sym link name given you 
have two libpngs?

> 
>> Attempting no lower case #declare, #local identifier idea. Hope is
>> user's function and macro arguments made _<lower case> form will be
>> immune to name collisions.
> 
> (crestfallen..)  hope 'a_' will be as acceptable as '_a'.
> 

Sure. You can continue to use any names you want for function and macro 
parameters. The _<lower> is the suggestion because it won't collide with 
future SDL keywords where some other lower case string might eventually 
- though probably not a_ :-).

Bill P.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 7/20/20 8:54 AM, jr wrote:
> > ...
> > one thing I noticed, 'povr' links against an older version of libpng, unlike the
> > "stock" POV-Ray.
> > ...

> ... Hmm, wonder, if you've got multiple libraries and no symlink
> to a version-less name like libpng.so.1 I'm unsure how one library would
> be picked over another? Do you have the common sym link name given you
> have two libpngs?

bingo.  yes, the "version-less" names ('libpng.{la,so}') were pointing to the
old(est) version; guess must have happened when I re-compiled/re-installed
1.6.37.  cheers.


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> > On 7/20/20 8:54 AM, jr wrote:
> > > ...
> > ... Hmm, wonder, if you've got multiple libraries and no symlink
> > to a version-less name like libpng.so.1 I'm unsure how one library would
> > be picked over another? Do you have the common sym link name given you
> > have two libpngs?
>
> bingo.  yes, the "version-less" names ('libpng.{la,so}') were pointing to the
> old(est) version; guess must have happened when I re-compiled/re-installed
> 1.6.37.  cheers.

right, and now we're getting to the bit where it gets .. strange.  :-)

built the new version of 'povray2', checked libpng link - ok, and 'make check'
ran fine, so installed.  went back into the scenes directory, and all three
scenes now fail with:
  ...
  Trace Time:       0 hours  0 minutes  0 seconds (0.354 seconds)
              using 4 thread(s) with 1.388 CPU-seconds total
Cannot allocate PNG data structures
Cannot allocate PNG data structures
Render failed

:-)  everything works as normal until it needs to write the disk file.

unfortunately cannot try those scenes with alpha.10064268, but checked that, and
other programs linking to 'libpng16', still work.  and 'povray2' output to, say,
jpeg, is ok.

'make check' succeeded because it doesn't actually try to write to disk?


regards, jr.

Post a reply to this message

hi,

"jr" <cre### [at] gmailcom> wrote:
> ...
> right, and now we're getting to the bit where it gets .. strange.  :-)

ignore.  the problem was the symlinks in /usr/include not pointing to the
correct headers.  :-(  re-built 'povray2' and all three test scenes ok.


regards, jr.

Post a reply to this message

hi,


William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> Sure. You can continue to use any names you want for function and macro
> parameters. The _<lower> is the suggestion because it won't collide with
> future SDL keywords where some other lower case string might eventually
> - though probably not a_ :-).

I find I'm not .. getting on with the forced uppercase stuff (sorry), and would
prefer to go back to the first version you posted.  regarding that, I did a
'diff' on the respective 'vfe/unix/unixconsole.cpp' files, is the 'XInitThreads'
call (including surrounding conditional) the only thing that would need to be
added to allow the _f9bc4ef7 version to function safely wrt X11?


regards, jr.

Post a reply to this message

On 7/29/20 2:16 PM, jr wrote:

Hi,
Just back from a few days at real life. Back at povr for real tomorrow - 
or the day after. Ahead of me getting back...

> 
> I find I'm not .. getting on with the forced uppercase stuff (sorry), and would
> prefer to go back to the first version you posted.  

Could you be more specific?

Povr breaks compatibility with as little as possible - but still quite a 
lot. My aim is to keep behavior near v3.8, but there is certainly more 
compatibility breakage to come. Is it more than wanting to continue to 
use lower case and/or includes which already have lower case?

Are there actual conflicts/problems with the approach; or examples where 
it's very inconvenient?

The functionality is still hacked in - because I'm trying it too. :-) 
But, thus far, I'm liking the behavior. In fact, I recently fixed a miss 
with command line declares letting lower case declare IDs still happen. 
That said, I've not run much old stuff with it as yet. Plus, suppose I 
wasn't in the habit of using lower case locals/declares to begin with.

Our SDL usage is different. I've not much jumped on the newer array, 
dictionary stuff, for example, mostly because it came well after my tcl 
wrapper - which already had that functionality.

regarding that, I did a
> 'diff' on the respective 'vfe/unix/unixconsole.cpp' files, is the 'XInitThreads'
> call (including surrounding conditional) the only thing that would need to be
> added to allow the _f9bc4ef7 version to function safely wrt X11?
> 

As safely as the newer release, yes.

There are other fixes and improvements relative to the prior release 
you'll be missing in using the first, but stuff should work except where 
there was already incompatible change - ie fog, inbuilt functions,...

Bill P.

Post a reply to this message

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

> Just back from a few days at real life. Back at povr for real tomorrow -
> or the day after. Ahead of me getting back...

Is it possible, and is there a security issue related to providing a means to
create a subdirectory in a write-permitted directory?

#write creates a file.  Can we create a directory by a similar means?
Just something to think about.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 7/29/20 2:16 PM, jr wrote:
>...
> > I find I'm not .. getting on with the forced uppercase stuff (sorry), and would
> > prefer to go back to the first version you posted.
>
> Could you be more specific?
>
> Povr breaks compatibility with as little as possible - but still quite a
> lot. My aim is to keep behavior near v3.8, but there is certainly more
> compatibility breakage to come. Is it more than wanting to continue to
> use lower case and/or includes which already have lower case?

no, for me it's just[*] the lower/uppercase stuff.  basically, each of my old
scenes I tried, failed.  I thought about modifying scene code, but since they
work I'll find it easier not to use (the new version of) 'povr'.

[*] at present.

> Are there actual conflicts/problems with the approach; or examples where
> it's very inconvenient?

just inconvenient.  eg, to "fix" the scene I used when I ran into the X11
animation issue, would be a lot of work, made worse by the fact that I got that
scene from the web, ie it's not even my code.

> The functionality is still hacked in - because I'm trying it too. :-)
> But, thus far, I'm liking the behavior.

cannot say the same.  guess I'm "allergic" to uppercase.  :-)

(could this behaviour be enabled/disabled via a 'povray.conf' setting instead?)

> ...
> > regarding that, I did a
> > 'diff' on the respective 'vfe/unix/unixconsole.cpp' files, is the 'XInitThreads'
> > call (including surrounding conditional) the only thing that would need to be
> > added to allow the _f9bc4ef7 version to function safely wrt X11?
> >
>
> As safely as the newer release, yes.

thanks, I'll try that then, sometime this weekend.


regards, jr.

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> ...
> Is it possible, and is there a security issue related to providing a means to
> create a subdirectory in a write-permitted directory?
>
> #write creates a file.  Can we create a directory by a similar means?
> Just something to think about.

have been thinking about (wishing for) for a 'system()' type function for a long
time.  but reading the above made me realise that a modified '#fopen' which
supports command pipelines, aided by a new OPEN_TYPE for r/w access could do
"everything" anyway.  then we could write, eg:

#fopen FP "| program" rdwr

to communicate with 'program', making creating a directory, all sorts of stuff,
easy and convenient.  for instance write some calculated parameters to 'program'
and read back new, derived values.


regards, jr.

Post a reply to this message

Le 31/07/2020 à 16:40, jr a écrit :
> hi,
> 
> "Bald Eagle" <cre### [at] netscapenet> wrote:
>> ...
>> Is it possible, and is there a security issue related to providing a means to
>> create a subdirectory in a write-permitted directory?
>>
>> #write creates a file.  Can we create a directory by a similar means?
>> Just something to think about.
> 
> have been thinking about (wishing for) for a 'system()' type function for a long
> time.  but reading the above made me realise that a modified '#fopen' which
> supports command pipelines, aided by a new OPEN_TYPE for r/w access could do
> "everything" anyway.  then we could write, eg:
> 
> #fopen FP "| program" rdwr
> 
> to communicate with 'program', making creating a directory, all sorts of stuff,
> easy and convenient.  for instance write some calculated parameters to 'program'
> and read back new, derived values.
> 
>


"Danger Will Robinson"

This could lead to some system corruption... A reason that there is
already io-restrictions: to protect the innocent.


You already have "shell-out" capability, with pre & post, scene & frame
level, so grouping actions should be doable to have all you need.

http://wiki.povray.org/content/Reference:Shell_Command_Options

Post a reply to this message

hi,

Le_Forgeron <jgr### [at] freefr> wrote:
> Le 31/07/2020 à 16:40, jr a écrit :
> > ... but reading the above made me realise that a modified '#fopen' which
> > supports command pipelines, aided by a new OPEN_TYPE for r/w access could do
> > "everything" anyway.  then we could write, eg:
> >
> > #fopen FP "| program" rdwr
> >
> > to communicate with 'program', making creating a directory, all sorts of stuff,
> > easy and convenient.  for instance write some calculated parameters to 'program'
> > and read back new, derived values.
>
> "Danger Will Robinson"
>
> This could lead to some system corruption... A reason that there is
> already io-restrictions: to protect the innocent.

:-)  true.  otoh, the imagined '|program' form of '#fopen' could be made subject
to the same '[Shellout Security]' setting as the pre/post commands.

> You already have "shell-out" capability, with pre & post, scene & frame
> level, so grouping actions should be doable to have all you need.

also true, I guess, that those commands can be used to do "everything".  still,
there are differences.  for instance, now, if I need to pass multiple/many
calculated values to 'program', I have to write a temporary file to be processed
by 'program', and then read the results on the next frame.  a modified '#fopen'
would allow a different programming style, and would in the example obviate the
need for temporary file(s) and animation control.


regards, jr.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> Please find attached an updated tarball.
> ...

ran into a problem with some code I was sent.

==== [Parsing...] ==========================================================
#include "spheresweep.inc" //version 1.2
File '/home/jr/POVr/share/povray-3.8/include/shapes.inc' line 20:
Possible Parse Error:
Cannot find file 'Wrapper.inc', even after trying to append file type extension.
File '/home/jr/POVr/share/povray-3.8/include/shapes.inc' line 20:
Parse Error:
Cannot open include file Wrapper.inc.
Fatal error in parser: Cannot parse input.
Render failed


regards, jr.

Post a reply to this message

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

> ran into a problem with some code I was sent.
>
> ==== [Parsing...] ==========================================================
> #include "spheresweep.inc" //version 1.2
> File '/home/jr/POVr/share/povray-3.8/include/shapes.inc' line 20:
> Possible Parse Error:
> Cannot find file 'Wrapper.inc', even after trying to append file type extension.
> File '/home/jr/POVr/share/povray-3.8/include/shapes.inc' line 20:
> Parse Error:
> Cannot open include file Wrapper.inc.
> Fatal error in parser: Cannot parse input.
> Render failed

That's a _weird_ error, especially since line 20 of shapes.inc is
#include "shapes_old.inc"

And there's no reference to 'Wrapper.inc' in either file.

Maybe if you have a reference to that, just comment it out?

Post a reply to this message

On 7/30/20 8:44 PM, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
>> Just back from a few days at real life. Back at povr for real tomorrow -
>> or the day after. Ahead of me getting back...
> 
> Is it possible, and is there a security issue related to providing a means to
> create a subdirectory in a write-permitted directory?
> 
> #write creates a file.  Can we create a directory by a similar means?
> Just something to think about.
> 

Yes, and no security issue with unix/linux/*x at least(1).

(1) - Maybe some obscure ways to disable a file system if one works at it.

The more tangled part is what would a command set supporting directories 
look like. Then we'd have the implementation of those commands, 
documentation and training of users. I saw too jr's suggestion for 
system commands. I don't know...

I'll further hedge. Again due my tcl wrapper, I've not used the POV-Ray 
based IO all that much. You and others, understand SDL IO better than me.

Aside:
My few, true animations I've done with my wrapper so I can do other 
frame to frame work in tcl (as jr suggested useful) and more so to 
see/work with the "as calculated" per-frame scene files while 
debugging/developing. Being able to get an after SDL(tcl) 'runs' scene 
representation is helpful.

My pure POV-Ray animation use has been: Creating a few frames where 
early images are used in a final one; Tickets and promo stuff for an 
arts program; A large puzzle piece image for a town treasure/scavenger 
hunt where the 'animation' created the puzzle piece images which were 
printed on smaller photo sized paper edge to edge. POV-Ray and its 
animation capability is very useful for such projects.

Bill P.

Post a reply to this message

On 7/31/20 12:55 PM, Le_Forgeron wrote:
> Le 31/07/2020 à 16:40, jr a écrit :
>> hi,
>>
>> "Bald Eagle" <cre### [at] netscapenet> wrote:
>>> ...
...
>> have been thinking about (wishing for) for a 'system()' type function for a long
>> time.  but reading the above made me realise that a modified '#fopen' which
>> supports command pipelines, aided by a new OPEN_TYPE for r/w access could do
>> "everything" anyway.  then we could write, eg:
>>
>> #fopen FP "| program" rdwr
>>
>> to communicate with 'program', making creating a directory, all sorts of stuff,
>> easy and convenient.  for instance write some calculated parameters to 'program'
>> and read back new, derived values.
...
> 
> "Danger Will Robinson"
> 
> This could lead to some system corruption... A reason that there is
> already io-restrictions: to protect the innocent.
> 

Though I've used *x systems for a long time, I make no claims on being a 
system image / os expert. I get that there might have been reasons for 
the io restrictions long ago, but how much protection do the io 
restrictions 'really' offer these days?

A properly set up unix/linux/*x system - whether POV-Ray is installed or 
not - already sets permissions which prevent regular users from reading 
and writing system directories and files.

Excepting, when they are allowed to run as root, in which case they 
already have an infinite number of ways to corrupt the system. And, as 
root, they can even do it using POV-Ray too as it ships/is-packaged today.

On systems, true multi-user or not, a regular user can fill up /tmp for 
example. They can chew up all the real ram, perhaps even all the swap 
with enough time (assuming the system admins are not running monitors 
which kill bad acting processes).

I look at our io restrictions and I think they likely cause as many 
users problems as they solve(1), while making it only a little easier 
for POV-Ray as an entity to say "it's unlikely POV-Ray wiped out your 
system."

(1) - When users or well intention-ed system admins prevent folks from 
being able to read and write where they should be able to read and write.

What am I missing?

Bill P.

Post a reply to this message

On 7/31/20 4:19 AM, jr wrote:
> hi,
...
> 
> no, for me it's just[*] the lower/uppercase stuff.  basically, each of my old
> scenes I tried, failed.  I thought about modifying scene code, but since they
> work I'll find it easier not to use (the new version of) 'povr'.
> 
> [*] at present.
> 
>> Are there actual conflicts/problems with the approach; or examples where
>> it's very inconvenient?
> 
> just inconvenient.  eg, to "fix" the scene I used when I ran into the X11
> animation issue, would be a lot of work, made worse by the fact that I got that
> scene from the web, ie it's not even my code.
> 
>> The functionality is still hacked in - because I'm trying it too. :-)
>> But, thus far, I'm liking the behavior.
> 
> cannot say the same.  guess I'm "allergic" to uppercase.  :-)
> 
> (could this behaviour be enabled/disabled via a 'povray.conf' setting instead?)
> 

Maybe in the near term, but the whole idea is to offer a way to code 
function and macro parameters which will never collide. This method only 
works if people cannot turn off the case checking.

I don't think there is any magic here. Name spaces, or whatever method, 
any fix(es) for indentifier name collisions will require changes to 
existing code and coding habits.

Bill P.

Post a reply to this message

On 7/31/20 6:29 PM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> Please find attached an updated tarball.
>> ...
> 
> ran into a problem with some code I was sent.
> 
> ==== [Parsing...] ==========================================================
> #include "spheresweep.inc" //version 1.2
> File '/home/jr/POVr/share/povray-3.8/include/shapes.inc' line 20:
> Possible Parse Error:
> Cannot find file 'Wrapper.inc', even after trying to append file type extension.
> File '/home/jr/POVr/share/povray-3.8/include/shapes.inc' line 20:
> Parse Error:
> Cannot open include file Wrapper.inc.
> Fatal error in parser: Cannot parse input.
> Render failed
> 
> 
> regards, jr.
> 
Ah, dang. Thanks!

While I'm working on new inbuilt functions, I use the Wrapper.inc 
include. It's found via my own POVINI variable setting and is used to 
point to a git tracked functions.inc file instead of the normal 
./include directory. The latter is not at the moment code controlled - 
though that's the plan.

In short, Wrapper.inc is a hack that lets me develop without having to 
create a build package on inbuilt function re-compiles. This mistake 
happened when I implemented an inbuilt f_supertorus() and updated the 
existing Supertorus shapes.inc macro to call it over, the old explicit 
function {} isosurface code.

I reviewed the other povr shipped includes just now - and I found one 
other mistake... I'd un-commented, or as likely commented in the wrong 
directory, the const.inc include in rand.inc and it declares 'e' which 
fails the lower case check. That include const.inc isn't needed today 
even in POV-Ray best as I can tell(1).

(1) - I fact looked to me as if several POV-Ray shipped includes are 
doing pointless includes which of course burns parse time for no reason. 


Bill P.

Post a reply to this message

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

> The more tangled part is what would a command set supporting directories
> look like.

I don't use any of the shellout commands, but I would imagine it would just be a
call to the "DOS" to create the specified directory.
mkdir "newDirectory"

#CreateDirectory "newDirectory"

The only bell-and-whistle thing I could envision would be opening a file for
writing in a subdirectory that doesn't yet exist, and automagically creating the
necessary directory branches for the file.  Probably wisest to purposefully
enable this feature to guard against simple typographical errors.

> Then we'd have the implementation of those commands,

I'm guessing you mean the actual POV-Ray source code

> documentation and training of users.

Which would be --- 3 or 4 lines of text?  :D
I mean, I know that packages of food come with instructions nowadays, "1. tear
open package 2. remove contents 3. eat" but I'm pretty sure most of it ought to
be "self-evident".

Post a reply to this message

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

> ... looked to me as if several POV-Ray shipped includes are
> doing pointless includes which of course burns parse time for no reason.

Yes, and some don't have prerequisite include statements for their dependencies.
  I think that the segment of torus object needs something in another shapesN
include file and that include file isn't in the file "header".

Some of the other include files / insert files have some mysterious blocks of
code that I haven't deciphered/translated [yet].  IIRC, FL's analytic geometry
has a few near the end...

I was trying to figure out a way to create a monolithic include file that could
selectively include whatever you specified, but I haven't figured out the best
way to do that.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 7/31/20 4:19 AM, jr wrote:
> > ...
> > cannot say the same.  guess I'm "allergic" to uppercase.  :-)
> >
> > (could this behaviour be enabled/disabled via a 'povray.conf' setting instead?)
> >
>
> Maybe in the near term, but the whole idea is to offer a way to code
> function and macro parameters which will never collide. This method only
> works if people cannot turn off the case checking.
>
> I don't think there is any magic here. Name spaces, or whatever method,
> any fix(es) for indentifier name collisions will require changes to
> existing code and coding habits.

while I agree that the "method only works if", and that, ultimately, "existing
code and coding habits" would (will?) need to change as part of a process, I
found myself thinking about a car analogy, the time when what are now "classic"
cars had to be retrofitted with seat belts[*]; and I wonder whether, like with
the seat belt, the primary victim of car-based incidents, the pedestrian, will
not actually benefit.  </rant>  (:-))

[*] and since they weren't designed with "attach points" in mind, other problems
arose.

I'll address a couple of other points here too.

> I fact looked to me as if several POV-Ray shipped includes are doing
> pointless includes which of course burns parse time for no reason.

yes.  I now tend to simply cut+paste the one or two bits I need from a given
POV-Ray include file into the scene, to get that efficiency.  Bald Eagle makes a
good point about a "monolithic" include, if we had a stand-alone parser,
conceivably, one could write a scene file "optimiser" using that.

in reply to Le Forgeron you write wrt permissions: "A properly set up
unix/linux/*x system..".  just to add for completeness that unlike past setups,
where Alice and Bob were in the (primary) 'users' group, these days it is common
for Alice and Bob to be in their own respective groups, with 'users' membership
being additional; ie even safer by default (assuming system is set up +
maintained).

and lastly, on the 'system()'/'#fopen' .. speculations.

> The more tangled part is what would a command set supporting directories
> look like. Then we'd have the implementation of those commands,
> documentation and training of users. I saw too jr's suggestion for
> system commands. I don't know...

the .. hankering after :-) a 'system()' function, which would have allowed eg BE
to write "system("mkdir -p new/sub/tree")", was long-term.  but I had my "road
to Damascus" moment when I read BE's post, and now think that modifying '#fopen'
to allow bi-directional access to a command would be both a "sympathetic"
extension of the SDL, and a very useful one in that it would permit (promote?) a
completely different way of writing scene code; you already do something
similar, so can vouch for the "useful" aspect.


regards, jr.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 7/29/20 2:16 PM, jr wrote:
> ...
> regarding that, I did a
> > 'diff' on the respective 'vfe/unix/unixconsole.cpp' files, is the 'XInitThreads'
> > call (including surrounding conditional) the only thing that would need to be
> > added to allow the _f9bc4ef7 version to function safely wrt X11?
>
> As safely as the newer release, yes.
> ...

not sure you will be as pleased as I am, but I've successfully downgraded to a
patched _f9bc4ef7.  I've used it to re-run the animation, no problems.  and it
is, for that code, faster than stock POV-Ray.  for the parsing, 'povr' needed
around 13.2 seconds per frame, while the alpha took around 13.8; for a 360 frame
animation, that alone has saved more than three minutes.  the total times (360
frames) were:
      alpha.10064268     povr
real    204m9.135s     181m32.384s
user    547m30.221s    470m55.856s
sys     0m3.471s       0m6.385s

another "interesting" thing is the output of 'ps'.  a big difference in the
virtual memory size, 'povr' barely 2% of POV-Ray's size.  and, puzzling this,
while the thread count ('nlwp') for POV-Ray fluctuates (6 to 10), 'povr's always
reads 1.

and regarding my previous post, I feel I should not have just given the car
analogy and left it at that; another instance of (me) communicating poorly.  I
guess it is, for me, about choice.  if, in the documentation, early and
prominently, there was a section regarding "interoperability", a paragraph on
name collisions and concerns, and one on the naming convention chosen to
(almost) always prevent name clashes, that should suffice. in my case, virtually
all SDL code I write is exclusively for my own consumption/entertainment, hence
my .. feeling bolshie re mandated uppercase, I guess.  :-)  if I write something
I think might be useful and decide to publish, then I'd have no objection to
writing that code to adhere to given guidelines. so, I hope the feature can be
made a selectable option, because I'd like to keep following along on the ..
'povr' journey.  :-)  (I guess I might even use the feature, to check whether
the code "passes")


regards, jr.

Post a reply to this message

On 8/2/20 7:33 PM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> On 7/29/20 2:16 PM, jr wrote:
>> ...
>> regarding that, I did a
>>> 'diff' on the respective 'vfe/unix/unixconsole.cpp' files, is the 'XInitThreads'
>>> call (including surrounding conditional) the only thing that would need to be
>>> added to allow the _f9bc4ef7 version to function safely wrt X11?
>>
>> As safely as the newer release, yes.
>> ...
> 
...
> 
> another "interesting" thing is the output of 'ps'.  a big difference in the
> virtual memory size, 'povr' barely 2% of POV-Ray's size.  and, puzzling this,
> while the thread count ('nlwp') for POV-Ray fluctuates (6 to 10), 'povr's always
> reads 1.
> 

Thank you for information on parsing and render times! I welcome all the 
feedback.

The 2% of normal POV-Ray memory use is surprising/unlikely as is the 1 
thread - given the actual results.

First the obvious, might you have been looking at 'povr' the script and 
not the real running povray command? Otherwise I'm not completely sure.
Something with animation perhaps. Animations do drop back to one thread 
when parsing and memory use would drop there too - initially.

If using photons, the thread use is different in that phase too.

Mostly these days I use top (linux) or htop (Raspberry (now with 8gb 
models and a promise of a true 64bit OS!)). For an artificially long 
running biscuit scene, I do see smaller sizes with top when using -y x11 
- which is not too surprising.

Virtual memory(a) KiB
     1120456 -> 754484 ---> -32.66%
Real memory
      47576  ->  32372 ---> -31.96%

(a) - always a little 'wide' of the mark in my experience.

In news to me. When I look at threads specifically with 'ps -eLf | grep 
povr' I do see a difference between SDL1.2 (v38) and SDL2.0 (povr) in 10 
to 14 active threads on my 2 core 4 thread machine. For me, POV-Ray 
proper normally runs with 10 threads in the final render phase. Six of 
threads are mostly idle. For reasons unknown to me, SDL2.0 has 4 more 
mostly idle threads? A question for the 'someday-maybe look at it 
further' list. :-)

Bill P.

Post a reply to this message

I haven't had much time to explore all of the forks and other projects - but
while they are under development, maybe I could throw some old and new ideas
out.

SO many people have asked to have values like the camera location be available.

As it is a vector, having the ability to have such a value be translated,
rotated, etc. and then queried for the result reminds me that having a point or
vector object that can be manipulated using standard SDL commands would be very
useful for a lot of folks who need to do that kind of thing.

Working on Yadgar's code, I realized that it might be an interesting and useful
thing to be able to access the current memory usage and the current number of
tokens parsed - for reporting, but also to define a bailout so as not to crash
the system, etc.

Obviously there have been many requests for vector functions, and that leads me
to bring this up:
#macro eval_pigment(pigm, vec)
    #local fn = function { pigment { pigm } }
    #local result = (fn(vec.x, vec.y, vec.z));
    result
#end

Somehow this magically returns a vector quantity, rather than a scalar.  :O

Matrix objects would be very nice for certain 3D graphics calculations and
transformations.  Maybe a matrix convolution function for image processing.  I
can see this being closely related to the recent work on function gradients as
well.

1D and 2D fast Fourier transforms.
Paul Bourke already has 2D in-place FFT code in c++ posted on his site.
http://paulbourke.net/miscellaneous/dft/

Just throwing out ideas, as these are inherently source code edits and
additions.

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
>...
> Obviously there have been many requests for vector functions, and that leads me
> to bring this up:
> #macro eval_pigment(pigm, vec)
>     #local fn = function { pigment { pigm } }
>     #local result = (fn(vec.x, vec.y, vec.z));
>     result
> #end
>
> Somehow this magically returns a vector quantity, rather than a scalar.  :O

Bill,

Have you seen these sections in the documentation ?

Declaring User-Defined Vector Functions
https://www.povray.org/documentation/3.7.0/r3_3.html#r3_3_1_8_4

Declaring User-Defined Color Functions
https://www.povray.org/documentation/3.7.0/r3_3.html#r3_3_1_8_5

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

Post a reply to this message

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:

> Bill,
>
> Have you seen these sections in the documentation ?
>
> Declaring User-Defined Vector Functions
> https://www.povray.org/documentation/3.7.0/r3_3.html#r3_3_1_8_4
>
> Declaring User-Defined Color Functions
> https://www.povray.org/documentation/3.7.0/r3_3.html#r3_3_1_8_5

Aye, I have, I have used the spline functions, and intuitively knew about the
pigment functions, but have spent so much time with scalar-only functions, that
it just struck me as --- odd and unexpected.


Good to see you around and poking your head in.    I hope all is going well in
your part of the world, and you have been finding ways to enjoy yourself amidst
- everything.

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
>...
> Good to see you around and poking your head in.    I hope all is going well in
> your part of the world, and you have been finding ways to enjoy yourself amidst
> - everything.

I'm lurking around in here in periods, but I seldom have as much time to
contribute as I would like. What is happening here is often interesting and
thought provoking. And sometimes very nice images appear ! So it is very good
that you and others keep this forum alive over time.

All is well here, thank you, except, of course, from the COVID-19 pandemic.
The Corona virus has not (yet) caused such big problems here in Norway as it has
in many other parts of the world. I hope all is well with you too Bill.

--
Best regards
Tor Olav
http://subcube.com
https://github.com/t-o-k

Post a reply to this message

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:

> I'm lurking around in here in periods, but I seldom have as much time to
> contribute as I would like.

Of course.  I hope you enjoy what you do and your field of work is flourishing.

Most of my work gets done in fits and starts and flashes of inspiration.  Rest
assured that much of what you have done to help myself and others clarify key
concepts and make it over hurdles we were struggling with has been of great
value.   Every snippet of code, equation, macro, or even a single 9-character
line of code is something to be used, learned from, and transferred on to others
climbing the same ladder.

> What is happening here is often interesting and
> thought provoking. And sometimes very nice images appear ! So it is very good
> that you and others keep this forum alive over time.

Indeed, there is still development happening across the spectrum - from
fundamental equations, algorithms, and other under-the-hood work to the
glistening final renders of stalwarts and masters.

> All is well here, thank you, except, of course, from the COVID-19 pandemic.
> The Corona virus has not (yet) caused such big problems here in Norway as it has
> in many other parts of the world. I hope all is well with you too Bill.


It all seems to be part of the cunning game taking place on the Grand
Chessboard.  The way I see it, "COVID-19" hasn't created any problems over and
above any of the other diseases that have ever arisen over the years, but
certainly the [over]reactions to it HAVE.

All is never "well" - but I have learned from many of the people who have
offered me insight and wisdom over the years that adversity and a bit of
hardship keep the mind and body healthy.

"...technology alone didn't allow humans to go to Madagascar, to Australia.
Neanderthals built boats too. Instead, he says, there's "some madness there. How
many people must have sailed out and vanished on the Pacific before you found
Easter Island? I mean, it's ridiculous. And why do you do that? Is it for the
glory? For immortality? For curiosity? And now we go to Mars. We never stop."
It's ridiculous, foolish, maybe? But it was the Neanderthals who went extinct,
not the humans.”"

“Maybe it's only a fool who will perilously journey out to what might not be
there. And maybe it's only a fool who will ask about supertasks, about infinity.
But if you want to solve problems, you don't just solve the ones that are there,
you find more and make more and go after the impossible ones; fostering a love
and obsession with problems is how you solve problems. Antoine de Saint-Exupéry
wasn't a mathematician, but his advice fits nicely here. If you want to build a
ship, don't drum up people to collect wood and don't assign them tasks and work,
but rather teach them to long for the endless immensity of the sea."

- Michael Stevens

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 8/2/20 7:33 PM, jr wrote:
> > ...
> > another "interesting" thing is the output of 'ps'.  a big difference in the
> > virtual memory size, 'povr' barely 2% of POV-Ray's size.  and, puzzling this,
> > while the thread count ('nlwp') for POV-Ray fluctuates (6 to 10), 'povr's always
> > reads 1.
> ...
> First the obvious, might you have been looking at 'povr' the script and
> not the real running povray command? Otherwise I'm not completely sure.
> ...

thanks, yes.  I forgot/overlooked that the executable is invoked from a script.
:-(


regards, jr.

Post a reply to this message

Le 03/08/2020 à 19:43, Bald Eagle a écrit :
> I haven't had much time to explore all of the forks and other projects - but
> while they are under development, maybe I could throw some old and new ideas
> out.
> 
> SO many people have asked to have values like the camera location be available.
> 

And nobody looked at hgpovray:

http://wiki.povray.org/content/User:Le_Forgeron/cameras#Access_to_camera_information

> http://wiki.povray.org/content/User:Le_Forgeron/cameras#Access_to_camera_information




> As it is a vector, having the ability to have such a value be translated,
> rotated, etc. and then queried for the result reminds me that having a point or
> vector object that can be manipulated using standard SDL commands would be very
> useful for a lot of folks who need to do that kind of thing.

Only if such "object" could be queried. It would have to distinguish
between points (3D vector) and normal (also 3D vector) at a given location.

On the other hand, the answer of Tor is fine: you can already have a
transform object and process vectors in it.

> 
> Working on Yadgar's code, I realized that it might be an interesting and useful
> thing to be able to access the current memory usage and the current number of
> tokens parsed - for reporting, but also to define a bailout so as not to crash
> the system, etc.

That could be considered, a bit like "now", the variable which returns
the current number of seconds since 2000-1-1 0:0:0 GMT.

* number of parsed token is a local data, just to find it in the code
(as it is currently reported by the parser, it must exist somewhere).

* current memory usage, I have a problem: how do you get that piece of
information, in a portable/Posix way ?
** Linux/Unix could use sysinfo()
** Windows could use GetProcessMemoryInfo(GetCurrentProcess(), ... )
** Mac could use task_info(mach_task_self(), ... )

If you want to protect your system from memory exhaustion, it is better
to ask the system to do it, or delegate to some tools between the system
and povray.



> 
> Obviously there have been many requests for vector functions, and that leads me
> to bring this up:
> #macro eval_pigment(pigm, vec)
>     #local fn = function { pigment { pigm } }
>     #local result = (fn(vec.x, vec.y, vec.z));
>     result
> #end
> 
> Somehow this magically returns a vector quantity, rather than a scalar.  :O
> 
> Matrix objects would be very nice for certain 3D graphics calculations and
> transformations.  Maybe a matrix convolution function for image processing.  I
> can see this being closely related to the recent work on function gradients as
> well.

There is already "transform" & "matrix" , but they are targeted to 3D
operations, using weighted coordinates (4x4, but you do not get to
specify the last column)

Convolution matrices are 2D filters, this is nothing related to our
matrices, it could be a totally new domain of exploration.

> 
> 1D and 2D fast Fourier transforms.
> Paul Bourke already has 2D in-place FFT code in c++ posted on his site.
> http://paulbourke.net/miscellaneous/dft/
> 

Und ich sage "Warum ?"

Fourier transforms are used with sampling (and fixed number of values).
It is lovely in Jpeg and other compressions, but what would be the usage
in a 3D rendering program ?

Wavelet (compression) also had its time of hype, yet it seems unrelated
to 3D rendering.


> Just throwing out ideas, as these are inherently source code edits and
> additions.
> 
> 

Ok, I note there is one remaining point that could be interesting:
getting the current number of parsed tokens.
Does not seem so urgent as a change.

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:

> And nobody looked at hgpovray:

I have and I do.   I have a tab open in my browser right now:
https://github.com/LeForgeron/povray/releases/tag/v3.8.0.alpha%2BHg.228.Jasmin
because it's going to get installed on my "new" laptop.

But I was mentioning this with an eye toward implementing it in official
pov-ray, the argument being, "If the code exists, and it works, and no one has
discovered any bugs - then what are the excuses left to NOT implement it?"
And if hgpovray has it AND povr has it, ....?


> Only if such "object" could be queried. It would have to distinguish
> between points (3D vector) and normal (also 3D vector) at a given location.

No, because it would be a proper object.
point {<vector>}
Then you could do translate <-1, 3, 9> and rotate -x*45
and then do a standard min_extent max_extent "query" on its location.

This would be useful for collections of points in a union that define important
points in/on an object.  Like a rotating gear or a chain or whatever one might
like to have a usable data point to plug into an equation.


> On the other hand, the answer of Tor is fine: you can already have a
> transform object and process vectors in it.

You can, but it's --- awkward.   I _can_ do certain things with macros and
functions, but it's not anywhere near as straightforward as if I were just
driving forward with aliases and vector functions.



> That could be considered, a bit like "now", the variable which returns
> the current number of seconds since 2000-1-1 0:0:0 GMT.

Yes, sure - that makes sense.

> * number of parsed token is a local data, just to find it in the code
> (as it is currently reported by the parser, it must exist somewhere).

Well it ticks off at the bottom of qtpovray and presumably windows, so I just
assumed that it was available at any given moment.

> * current memory usage, I have a problem: how do you get that piece of
> information, in a portable/Posix way ?

IIRC, the windows editor displays that information during parsing, so someone
has already done it?


> If you want to protect your system from memory exhaustion, it is better
> to ask the system to do it, or delegate to some tools between the system
> and povray.

Yes, but for some people, that's a whole other skill set and learning curve and
time sink that takes away from writing the scene.   It was just a small
suggestion that I thought could be useful if it could be trivially implemented.


> There is already "transform" & "matrix" , but they are targeted to 3D
> operations, using weighted coordinates (4x4, but you do not get to
> specify the last column)

Yes - I meant in a general sense.  Data structures and tools where one could
create normal mathematical matrices and do all of the usual matrix math
operations.   I know that we have _some_ macros for that, and I have written
quite a few of my own, but having a more complete, formal set of tools for this
would be nice - there are a lot of people who use povray for math and graphics,
and want to use it as a tool to do creative work and understand an
illustrate/demonstrate the underlying processes.

> Convolution matrices are 2D filters, this is nothing related to our
> matrices, it could be a totally new domain of exploration.

They are.  I envision a lot of interesting things that people could do, using
them as image_map modifiers in order to process terrain and even procedural
pigment patterns.


> > 1D and 2D fast Fourier transforms.
> > Paul Bourke already has 2D in-place FFT code in c++ posted on his site.
> > http://paulbourke.net/miscellaneous/dft/
> >
>
> Und ich sage "Warum ?"

as did clipka.

> Fourier transforms are used with sampling (and fixed number of values).
> It is lovely in Jpeg and other compressions, but what would be the usage
> in a 3D rendering program ?

Because povray is uniquely a DATA driven rendering software where things are
made programmatically, not with a modeler.  And of course a vast amount of the
data we deal with is procedural.  Patterns.  Signals, if you will.  And so the
single-most useful signal-processing algorithm ever conceived could (and would)
be used to create, analyze, and filter data sets for use in making patterns, and
creating the necessary geometry to be textured and rendered.
People have already played with making object shapes with fourier.   jpg has
color banding that someone may want to know the periodicity of.   procedural
patterns and various fractal textures may have repeats that one may need to know
the frequency of in order to avoid/hide.   Procedural patterns are _patterns_
And everything we do is based on patterns.   Chris Cason mentioned that people
use povray as part of their workflow.  I corresponded somewhat recently with
someone who was in fact using fourier to do work on x-ray crystallographic data.
 Mathematicians and scientists would surely find this otherwise ubiquitous tool
useful and we may get new users who discover povray itself - not as a and
end-of-pipeline rendering tool, but as a curiosity and hobby.   This is how we
get new people and ideas.   Lots of scientific data gets processed and
visualized with povray - it's information.  Signals.
I almost see this as being akin to "of what use would something like Perlin
noise be to 3D graphics...?"



> Wavelet (compression) also had its time of hype, yet it seems unrelated
> to 3D rendering.

Unfamiliar with that.


> Does not seem so urgent as a change.

These are suggestions for the interested to consider.   Not any "urgent"
features that I'm hounding anyone to do right now.

Post a reply to this message

Le 04/08/2020 à 10:26, Le_Forgeron a écrit :
> Ok, I note there is one remaining point that could be interesting:
> getting the current number of parsed tokens.
> Does not seem so urgent as a change.

For the curious, the value is in parser/parser.h : mTokenCount

Now, can someone provide a good name for the SDL to return that value ?

Post a reply to this message

hi,

Le_Forgeron <jgr### [at] freefr> wrote:
> Le 04/08/2020 à 10:26, Le_Forgeron a écrit :
> > Ok, I note there is one remaining point that could be interesting:
> > getting the current number of parsed tokens.
> > Does not seem so urgent as a change.
>
> For the curious, the value is in parser/parser.h : mTokenCount
>
> Now, can someone provide a good name for the SDL to return that value ?

some new function modelled on 'sysconf(3)' would be cool, with 'mTokenCount'
just one of the argument values, perhaps.


regards, jr.

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:

> Now, can someone provide a good name for the SDL to return that value ?

token_count
tokens_current
parsed_tokens
object_tokens
parser_tokens
current_tokens
tokens_now()

HowMuchStuffIHaveParsedSoFar

:D

Post a reply to this message

Le 20/08/2020 à 00:22, Bald Eagle a écrit :
> Le_Forgeron <jgr### [at] freefr> wrote:
> 
>> Now, can someone provide a good name for the SDL to return that value ?
> 
> token_count
> tokens_current
> parsed_tokens
> object_tokens
> parser_tokens
> current_tokens
> tokens_now()
> 
> HowMuchStuffIHaveParsedSoFar
> 
> :D
> 
Adopted "parsed_tokens"


=======
#version 3.8;
global_settings {assumed_gamma 1.0}
#include "colors.inc"
#default{ finish{ ambient 0.1 diffuse 0.9 }}


light_source { <100,1000,-1000>, White}

camera { location <0,-1,-16>
         right    x*image_width/image_height
         angle 35
         look_at <0,-1,0>
       }

plane{-z,-10  pigment{checker color rgb<1,1,1>*0.8 color rgb<1,1,1>} }

#declare String1=concat("parsed_tokens =", str(parsed_tokens,0,0));


text{ internal 1, "Parser info", 0.3, 0 pigment{Blue*0.7} translate
-4.5*x+1.5*y }
text{ internal 1, String1, 0.3, 0 pigment{Red*0.7} translate -4.5*x }
#declare String2=concat("parsed_tokens =", str(parsed_tokens,0,0));
#declare String3=concat("parsed_tokens =", str(parsed_tokens,0,0));
text{ internal 1, String2, 0.3, 0 pigment{Red*0.7} translate -4.5*x -1.5*y }
text{ internal 1, String3, 0.3, 0 pigment{Red*0.7} translate -4.5*x -3*y }

Post a reply to this message

Le 19/08/2020 à 21:27, jr a écrit :
> hi,
> 
> Le_Forgeron <jgr### [at] freefr> wrote:
>> Le 04/08/2020 à 10:26, Le_Forgeron a écrit :
>>> Ok, I note there is one remaining point that could be interesting:
>>> getting the current number of parsed tokens.
>>> Does not seem so urgent as a change.
>>
>> For the curious, the value is in parser/parser.h : mTokenCount
>>
>> Now, can someone provide a good name for the SDL to return that value ?
> 
> some new function modelled on 'sysconf(3)' would be cool, with 'mTokenCount'
> just one of the argument values, perhaps.
> 
> 

You know what is bad with such idea ?
1. Look at the map type in image_map: using number instead of explicit
good name is painful, even when Constants.inc provides some name afterward.

http://wiki.povray.org/content/Reference:Image_Map

2. sysconf is a pain to use: you always need to be on the local system
to be sure to get what you ask (the man page of sysconf is using
symbolic constants, which do not translate at all between systems once
compiled). Initially I thought you wanted access to sysconf, but it
seems to only be a model.

3. it is too open: there is no usable specification.
It is like "add a foo(bar) function which return mTokenCount when bar is 3"
Why having such function ? What would be the common part with the value
returned when bar is 5 ?
Also Povray loves floating point values, and hates integer, so what is
the meaning of foo(3.4) ?
It reminds me far too much of the poke & peek tables in the 80's computers.

To misname things is to add to the unhappiness of the world.

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:

> You know what is bad with such idea ?
> 1. Look at the map type in image_map: using number instead of explicit
> good name is painful, even when Constants.inc provides some name afterward.

Yes.  I would agree that a good (but SHORT) name would be best.
But I have also come to value the ability to refer to things numerically, so
that I can loop through a collection of things easily - we people love
descriptive, meaningful names - computers love numbers.

Wih respect to image_map specifically, any guesses as to what the missing map
types were supposed to be?  :D

> Initially I thought you wanted access to sysconf, but it
> seems to only be a model.

I think he was interested in having a "povray system function" that would be
able to return a number of different system / environment / configuration values
- LIKE sysconf.
So perhaps some of the internal epsilon values, memory available, threads used,
etc.   Someone might want to annotate their render or generate a text file that
gets post-render bundled with their render for documentation purposes.
Development, debugging, documenting - and they may want/need to do that with a
programmable function - like if they have 3000 frames - and avoid having to drag
another software/OS tool (and learning curve) into the mix.

> To misname things is to add to the unhappiness of the world.

Yeah, brother.  No truer words were ever spoken.  Say what you mean, and mean
what you say. (Or at least try as much as possible/practical)

Post a reply to this message

hi,

Le_Forgeron <jgr### [at] freefr> wrote:
> ...
> 2. sysconf .... Initially I thought you wanted access to sysconf, but it
> seems to only be a model.

yes, just a function with an interface like 'sysconf()'.  Bald Eagle put it
better than I could.

> ...
> To misname things is to add to the unhappiness of the world.

agree, and yet, finding "good" descriptive names is never easy (for me, anyway).


regards, jr.

Post a reply to this message

On 8/23/20 1:38 PM, Bald Eagle wrote:
> Le_Forgeron <jgr### [at] freefr> wrote:
> 
...
> 
> Wih respect to image_map specifically, any guesses as to what the missing map
> types were supposed to be?  :D
> 

I ran across the following in the v1.0 source code the other day while 
trying to understand the history of something:

/* Image/Bump Map projection methods */
#define PLANAR_MAP      0
#define SPHERICAL_MAP   1
#define CYLINDRICAL_MAP 2
#define PARABOLIC_MAP   3
#define HYPERBOLIC_MAP  4
#define TORUS_MAP       5
#define PIRIFORM_MAP    6
#define OLD_MAP         7

I guess v3.8's type 7 (angular light probe?) took OLD_MAP's slot :-).

The documentation has forever said types 3 & 4 are under development, 
but I've never spotted any actual code indicating this ever true beyond 
an intent. FWIW.

Bill P.

Post a reply to this message

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

> I ran across the following in the v1.0 source code the other day while
> trying to understand the history of something:
>
> /* Image/Bump Map projection methods */
> #define PLANAR_MAP      0
> #define SPHERICAL_MAP   1
> #define CYLINDRICAL_MAP 2
> #define PARABOLIC_MAP   3
> #define HYPERBOLIC_MAP  4
> #define TORUS_MAP       5
> #define PIRIFORM_MAP    6
> #define OLD_MAP         7

VERY cool  :)
It's more than clipka uncovered.
So at least that answers a 6-year-old question.  :D

http://news.povray.org/povray.binaries.images/message/%3C5438051b%241%40news.povray.org%3E/#%3C5438051b%241%40news.povr
ay.org%3E

Are these mapping types still in need of development?

Post a reply to this message

On 8/24/20 1:35 PM, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
...
> 
> Are these mapping types still in need of development?
> 

None can be that important given how long they've not been done! :-)

Guessing a  at meaning/application, the parabolic I suppose might 
occasionally be of use - parabolas. Taking the hyperbolic to mean 
non-linear in some aspect of other usually linear mappings, that I guess 
that would end up as a set of 'hyper' mappings for linear, spherical, 
etc. Piriform suppose might have been aimed at two element blobs or 
something?

My up front issue with all more complicated mappings - and with the more 
complicated shape uv_mapping options - is one should first and foremost 
work out how the maps can easily be created in POV-Ray(1). Or, know of 
some standard external 'standard' like the light probe angular mapping 
added to v3.8. Otherwise, you've got some feature you can 'advertise' 
and which might look great for a demo or two, but in the end it's a 
feature pretty much nobody uses.

(1) - Matching cameras, an interactive painting capability, ...

Aside: Most any complicated mapping can be accomplished today via 
functions - though it might not be easy to get right, as you well know.

Bill P.

Post a reply to this message

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

> None can be that important given how long they've not been done! :-)

Well, yes.   There's that.
But one might equally ascribe their non-usage to their non-existence.

Given an easy way to do something, people usually take it.
If faced with the prospect of somehow getting someone somewhere to write a
mapping in source code and provide a new release - or - just writing some "good
enough" pseudo-mapping or function-mapping, then maybe that's what's been done.
No idea how many people (would have) use(d) those other types of maps, but
possibly that would tip the scales the other way.

It's always hard to speculate about these things accurately.  ;)

> Guessing a  at meaning/application, the parabolic I suppose might
> occasionally be of use - parabolas.

I guess maybe there might be further use with parabolic mirrors, cameras, and -
more specifically - telescopes.

https://www.eso.org/sci/facilities/paranal/telescopes/vlti/tuto/tutorial_introduction_to_stellar_interf.pdf

> Taking the hyperbolic to mean
> non-linear in some aspect of other usually linear mappings, that I guess
> that would end up as a set of 'hyper' mappings for linear, spherical,
> etc.

I looked - it seems like they might be very useful and fun for Escher fans.
M. Grimbert might be interested, given he seems to be the master of tilings.
I'm guessing/speculating that these mappings (Poincare disks, etc) might have
practical engineering / scientific use in physics, Finite Element Methods, fluid
dynamics, etc?

https://computergraphics.stackexchange.com/questions/2117/map-a-texture-onto-a-hyperbolic-triangle
https://medium.com/@philogb/hyperbolic-floors-a2c5445144c6
https://mediatum.ub.tum.de/doc/1210572/1210572.pdf

Or maybe it has specific application to cartography and map projections?
https://en.wikipedia.org/wiki/Squeeze_mapping

It might also be related to a catadioptric omnidirectional camera mapping, like
that used with a hyperbolic convex mirror.
https://link.springer.com/content/pdf/10.1007%2F978-3-642-02921-9_26.pdf

And this leads me to believe that they are all related:
http://roguetemple.com/z/hyper/models.php



> Piriform suppose might have been aimed at two element blobs or
> something?

Possibly.   No idea why it was desired in v 1 of all things, and the only places
I find it aside from pure math sites, is references for POV-Ray (with Mike
Williams bridging that gap)
https://mathworld.wolfram.com/PiriformCurve.html
https://mathworld.wolfram.com/PiriformSurface.html

>
> My up front issue with all more complicated mappings - and with the more
> complicated shape uv_mapping options - is one should first and foremost
> work out how the maps can easily be created in POV-Ray(1). Or, know of
> some standard external 'standard' like the light probe angular mapping
> added to v3.8. Otherwise, you've got some feature you can 'advertise'
> and which might look great for a demo or two, but in the end it's a
> feature pretty much nobody uses.
>
> (1) - Matching cameras, an interactive painting capability, ...
>
> Aside: Most any complicated mapping can be accomplished today via
> functions - though it might not be easy to get right, as you well know.

Of course.   But sometimes these things inexplicably take on a life of their
own.  And during the course of investigating them simply out of curiosity,
novelty, or someone's specialized interest or based solely on the challenge of
doing it - we uncover bugs (!) and discover interesting new things that we might
never have thought of or even known were possible.

Just figured I'd ask - because obviously _someone_ thought they were important
enough to assign a mapping slot for them early on.

##############################################################################

Now, given the fact that we have uv-mapping for Bezier bicubic patches, and the
source code to create the patch from the corners and control points:

Do we think it would be a lot of work to add a feature where
colors/pigments/textures/finishes could be specified at the corners of a Bezier
patch, and a pattern / map would be generated based on the patch?
https://www.ibiblio.org/e-notes/Splines/color3d.html
(I didn't SEE such a thing in HGpovray38, but I might have missed it)

Post a reply to this message

> 
>
https://computergraphics.stackexchange.com/questions/2117/map-a-texture-onto-a-hyperbolic-triangle
> https://medium.com/@philogb/hyperbolic-floors-a2c5445144c6
> https://mediatum.ub.tum.de/doc/1210572/1210572.pdf


An investigation not as pattern but as warp could be interesting.

The early part to answer is: what happen outside the circle.
One answer can be: nothing, outside the circle, there is no transformation.

Or something different, as suggested in the pdf for poincarré disk.

It is "of course" to be mainly used with the image pattern, so it is
better from the very start that the reference plane be the same (to
avoid a systematic rotate), and the third coordinates is to be dropped.

So far the "perfect" illustration could be some pedestal table with such
topping, and some chess set on it...
With an outer ring, which implies some layered textures too.

*********

About bezier bicubic patches, I do not so far understand what is the
final purpose of the request. Does it sound like gluing the mesh camera
to a bezier bicubic patch ? (mesh camera or user-function defined camera).
As a raytracing aims at generating pictures, what is a finish map in
that context ?

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:

> An investigation not as pattern but as warp could be interesting.

Aha, yes - that's a better way of thinking about it.

> The early part to answer is: what happen outside the circle.
> One answer can be: nothing, outside the circle, there is no transformation.

That would be my initial, naive impression.  Something like "once".

> Or something different, as suggested in the pdf for poincarré disk.

I'm sure that there exist a number of different options, and of course we will
probably find out what they are once someone picks up this sort of thing to
begin experimenting with and proceeds to discover what other ways there are or
follows a path of reasoning to suggest a new option.

Geometric inversion?

> It is "of course" to be mainly used with the image pattern, so it is
> better from the very start that the reference plane be the same (to
> avoid a systematic rotate), and the third coordinates is to be dropped.

Oh, please, no.   One of my main dislikes of things like prism {} is that the
coordinates are supplied in <x, z> format.  So then rather than simply passing
[multipurpose] vectors to the object definition, where the y-component gets
_ignored_, I have to write a whole new section of code to convert everything
into a special single-purpose format.   :(

> So far the "perfect" illustration could be some pedestal table with such
> topping, and some chess set on it...
> With an outer ring, which implies some layered textures too.

Likely.  But I also envisioned seeing how all of the various tilings can be
manipulated.   :)

> About bezier bicubic patches, I do not so far understand what is the
> final purpose of the request. Does it sound like gluing the mesh camera
> to a bezier bicubic patch ? (mesh camera or user-function defined camera).
> As a raytracing aims at generating pictures, what is a finish map in
> that context ?

The idea would be to define 4 corners of the bezier patch in terms of - not
<x,y,z> - but <r, g, b> and then rather than doing a straight bilinear
interpolation of the color values between the two points across the rectangle,
bicubically interpolate the colors across a Bezier surface.
Does that make sense?

I guess I also had it in my mind that if I had an existing _geometric_ bezier
patch, that somehow it would be possible to simply define the colors of the 4
fixed corners, and those would get mapped to the geometric coordinates.   Then
the geometric control points would control the bicubic color interpolation
between the color values - avoiding the need to write a whole separate block of
code for the coloring.

I hadn't really though it all the way through, so sorry for any confusion.

But it does suggest that there could be a bicubic WARP where patterns could be
distorted (or image maps corrected) through such a mechanism.

Also, the mesh camera is an interesting idea.  I'm not sure what you mean by the
finish map - but I would imagine it has something to do with the
ray-scene/surface angles?   Like for something simple like specular reflection?
That I simply don't know.
Maybe if it were just an experimental feature, use the undistorted mesh camera
to generate the color but the bicubic functions to control the view....
No idea.

Post a reply to this message