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