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

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