|
|
Am 19.10.2017 um 14:11 schrieb Bald Eagle:
> Le_Forgeron <jgr### [at] freefr> wrote:
>> It is not slow with a polynomial.
>
> But now check this out:
> http://www.povray.org/documentation/view/3.7.1/74/
>
> "Note:Since version 3.5, POV-Ray includes the new isosurface object which makes
> the polynomial object more or less obsolete. The isosurface is more versatile
> (you can specify any mathematical function, not just polynomials), easier to
> use. You can write the function as is, without needing to put values in a
> gigantic vector.
> Isosurfaces often render considerably faster than equivalent polys."
>
> Whaaaaat?
I'd expect this to depend on both the order and "density" of the
coefficient matrix, i.e. how many coefficients are non-zero. If you have
many zero coefficients, it may be faster to execute a corresponding
user-defined function than to compute the full set of polynomial terms
and then multiply most of them by zero.
For example, given the function
f(x,y,z) = x^2 + y^2 + z^2
and
f(x,y,z) = x^10 + y^10 + z^10
this should require roughly the same effort when using an isosurface,
but when using a polynomial the second function will require a much
higher effort to solve.
> Also, considering that quintics are apparently of ridiculous complexity to
> solve, and higher order polynomials rapidly become more insane, I'd like to get
> a little insight as to how POV-Ray deals with 15th order polys and, if the
> version of the docs I'm reading is right - _35th_ order.
>
> http://www.povray.org/documentation/3.7.0/t2_3.html
>
> "Note: A maximum of 35th degree polynomial can be represented with the poly
> object. If a higher degree polynomial or other non-polynomial function has to be
> represented, then it is necessary to use the isosurface object."
>
> (When did the limit go from 15 to 35? WHO recoded that in the source??)
This is defined by the `MAX_ORDER` constant in the source code, which
was "recently" increased by Jerome Grimbert (aka Le_Forgeron).
The previous limit of 15 was rather arbitrary; the current limit of 35
is imposed by the `binomials` precomputed table in `polynomial.cpp`,
which would require more than 32 bits per entry if the limit was
increased above 35.
Post a reply to this message
|
|