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