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,



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

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