|
|
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
|
|