 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Recently Bald Eagle has been playing with elliptical tori and he created
a parametric one. I picked it up to play with the shape - but also to
perhaps dig into why parametrics so slow.
Like many folks, initially grabbed Mike Williams's stuff and ran it -
years ago. Quickly agreed parametrics are extremely slow. I confess to
20 years plus of almost completely ignoring the things...
Well turns out the parametric's max_gradient is not like the
isosurface's max_gradient and the default of 1.0 looks to be a bad
choice. I've not run all the parametric scenes I have, but looks mostly
you want to run parametrics with gradients well below 1.0. Something
like 0.001 looks pretty good as a start. Only run into two very
complicated parametrics needing max gradients at 1.0 or above. Most, a
LOT smaller.
I've also set accuracy to 0.0005 below. The default 0.001 a little high
for today's monitors. Expect further tuning possible. I only took a
couple turns at them.
So in my mind parametric now use-ably slow, instead of never-use slow. :-)
Bill P.
---
Parametric scenes from Mike Williams's site on my 2 core i3.
-----------
povr2 <scene>.pov +a0.3 +am2 +r3 (800x600)
Param00.pov 46.082 -> 10.204 ---> -77.86% (2.7s elapsed)
Param01.pov * 411.856 -> 12.808 ---> -96.89% (3.4s elapsed)
Param02.pov 19.163 -> 16.746 ---> -12.61% (4.4s elapsed)
Param04.pov 1 515.145 -> 788.846 ---> +53.13% (198s)
param05.pov 877.672 -> 91.962 ---> -89.52% (23.6s)
param06.pov 268.503 -> 59.404 ---> -77.88% (15.2s)
param07.pov 331.665 -> 71.517 ---> -78.44% (18.2s)
param09.pov 37.754 -> 15.670 ---> -58.49% (4.1s)
param10.pov 32.087 -> 20.735 ---> -35.38% (5.4s)
param11.pov 84.101 -> 19.407 ---> -76.92% (5.1s)
param11a.pov 426.047 -> 63.336 ---> -85.13% (16.3s)
param12.pov These last all param.inc examples.
param13.pov
param14.pov
param15.pov
(*) Had artifacts at shipped settings. Not at updated. Updates running
with higher accuracy generally.
(1) See (*). Removed no_shadow modifier from both. Trying povr raw_wave
with the granite pattern and no .grey so forced to v3.8. Not apples to
apples plus color shifts. If drop back to default 0.001 accuracy better
match original (shadow tolerance issues) at 460s cpu (-10%).
Post a reply to this message
|
|
| |
| |
|
|
From: Thomas de Groot
Subject: Re: Parametric surfaces faster than thought.
Date: 5 May 2020 02:51:12
Message: <5eb10ce0@news.povray.org>
|
|
|
| |
| |
|
|
Op 04/05/2020 om 12:13 schreef William F Pokorny:
[skip]
>
> So in my mind parametric now use-ably slow, instead of never-use slow. :-)
>
[skip]
This is a significant discovery, sir! I always thought is was a pity
that parametrics were so slow. Finally, they will come into their own;
there should certainly be use for them. Keep up the good work!
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas de Groot <tho### [at] degroot org> wrote:
> Op 04/05/2020 om 12:13 schreef William F Pokorny:
> [skip]
> >
> > So in my mind parametric now use-ably slow, instead of never-use slow. :-)
> >
> [skip]
> This is a significant discovery, sir! I always thought is was a pity
> that parametrics were so slow. Finally, they will come into their own;
> there should certainly be use for them. Keep up the good work!
>
> --
> Thomas
This primitives' GUI in Blender's POV-Converter just turned from a "more than 10
hours" render to a less than 10 seconds... Thank you sooo much !
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2020-05-04 6:13 AM (-4), William F Pokorny wrote:
>
> Well turns out the parametric's max_gradient is not like the
> isosurface's max_gradient and the default of 1.0 looks to be a bad
> choice. I've not run all the parametric scenes I have, but looks mostly
> you want to run parametrics with gradients well below 1.0. Something
> like 0.001 looks pretty good as a start. Only run into two very
> complicated parametrics needing max gradients at 1.0 or above. Most, a
> LOT smaller.
>
> [snip]
>
> So in my mind parametric now use-ably slow, instead of never-use slow. :-)
This is great news, and good information!
Post a reply to this message
|
|
| |
| |
|
|
From: William F Pokorny
Subject: Re: Parametric surfaces faster than thought.
Date: 11 May 2020 04:02:14
Message: <5eb90686$1@news.povray.org>
|
|
|
| |
| |
|
|
On 5/4/20 6:13 AM, William F Pokorny wrote:
...
>
> So in my mind parametric now use-ably slow, instead of never-use slow. :-)
>
...
Yesterday got some testing infrastructure going for the parametric; I'd
never bothered given I didn't previously use it. Ran a larger matrix of
options including turning precompute completely off and have better
information on lowering the gradient.
Basically you can lower gradients as you increase the precompute depth.
The stuff I have tends to use depths of 8 to 16 say so taking the
max_gradient directly to 0.001 almost always works.
With a sphere, MG 0.001 still works at a precompute depth of 4, but at 3
you get only a partial surface(1) and the MG needs to jump up to 0.5 or
so. With no precompute you need MG 1.0.
(1) - My sphere scene. Results will vary depending on bounding, camera etc.
While I expect most everyone runs with precompute, this makes wrong my
comment the max gradient being defaulted to 1.0 a bad default. Perhaps
not having precompute on by default with a much lower gradient is... ;-)
On the other end, the benefit from lowering max_gradient below 0.001
diminishes with the sphere pretty rapidly once at a depth of say 8. You
can lower MG more at 8, but the gains really slight. Might be a reason
to do < 0.001 for accurate results on complicated shapes, but doesn't
look to be much of one for performance.
So! My updated recommendation would be to start with:
accuracy 0.0005
max_gradient 0.001
precompute 8, x,y,z
over current defaulting. Of course, what you need will depend on what
your are doing equation wise, bounding wise etc.
I've not dug into why the behavior is what it is. The apparent
exponential MG jump a low/no precompute a little surprising to me, but
yep...
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
It would be so nice to have internally coded approximation options alongside the
POV-Ray proper algorithms.
like:
http://www.econym.demon.co.uk/isotut/param.htm
http://www.econym.demon.co.uk/isotut/approx.htm
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 11/05/2020 à 13:19, Bald Eagle a écrit :
>
>
> It would be so nice to have internally coded approximation options alongside the
> POV-Ray proper algorithms.
>
> like:
> http://www.econym.demon.co.uk/isotut/param.htm
> http://www.econym.demon.co.uk/isotut/approx.htm
>
Hold my drink.
Looks like making parametric an UVMeshable object.
http://wiki.povray.org/content/User:Le_Forgeron/UVMeshable
Does not seem impossible, using the bound of the parametric as the range
for uv.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 11/05/2020 à 19:16, Le_Forgeron a écrit :
> Hold my drink.
>
> Looks like making parametric an UVMeshable object.
>
>
> http://wiki.povray.org/content/User:Le_Forgeron/UVMeshable
>
> Does not seem impossible, using the bound of the parametric as the range
> for uv.
>
Yep, done now in new release of Hgpovray38 :
https://github.com/LeForgeron/povray/releases/tag/v3.8.0.alpha%2BHg.228.Jasmin
> https://github.com/LeForgeron/povray/releases/tag/v3.8.0.alpha%2BHg.228.Jasmin
Beware, contained_by is *not* honored.
#declare OBJ= parametric{
function{ u/2 } //x(u,v) or x
function{ 0.05*(sin(v*pi)+sin(u*pi))}
function{ v/2 } //z(u,v) or z
<-4,-2>,<4,2> // start, end of (u,v)
contained_by {box {<-2,-1,-1>,<2,1,1>}}
max_gradient 2
accuracy 0.0035
precompute 18 x,y,z
scale 0.25
texture { T }
}
#include "NurbsMesh.inc"
#declare Foo=
mesh{
UVMeshable(OBJ, 16*4, 16*4 )
texture { T }
rotate -90*x
translate 0.5*x+0.5*z
};
object{ Foo }
Post a reply to this message
|
|
| |
| |
|
|
From: William F Pokorny
Subject: Re: Parametric surfaces faster than thought.
Date: 15 Jun 2020 05:50:47
Message: <5ee74477$1@news.povray.org>
|
|
|
| |
| |
|
|
On 6/14/20 12:36 PM, Le_Forgeron wrote:
> Le 11/05/2020 à 19:16, Le_Forgeron a écrit :
>
...
>>
>> http://wiki.povray.org/content/User:Le_Forgeron/UVMeshable
>>
...
>
> Yep, done now in new release of Hgpovray38 :
> https://github.com/LeForgeron/povray/releases/tag/v3.8.0.alpha%2BHg.228.Jasmin
>
>> https://github.com/LeForgeron/povray/releases/tag/v3.8.0.alpha%2BHg.228.Jasmin
>
> Beware, contained_by is *not* honored.
>
> #declare OBJ= parametric{
> function{ u/2 } //x(u,v) or x
> function{ 0.05*(sin(v*pi)+sin(u*pi))}
> function{ v/2 } //z(u,v) or z
> <-4,-2>,<4,2> // start, end of (u,v)
> contained_by {box {<-2,-1,-1>,<2,1,1>}}
> max_gradient 2
> accuracy 0.0035
> precompute 18 x,y,z
> scale 0.25
> texture { T }
> }
>
> #include "NurbsMesh.inc"
>
> #declare Foo=
> mesh{
> UVMeshable(OBJ, 16*4, 16*4 )
>
> texture { T }
> rotate -90*x
> translate 0.5*x+0.5*z
> };
> object{ Foo }
>
Cool. I'll give this a go.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
From: William F Pokorny
Subject: Re: Parametric surfaces faster than thought.
Date: 15 Jun 2020 07:24:25
Message: <5ee75a69$1@news.povray.org>
|
|
|
| |
| |
|
|
On 6/15/20 5:50 AM, William F Pokorny wrote:
> On 6/14/20 12:36 PM, Le_Forgeron wrote:
...
>
> Cool. I'll give this a go.
>
...
You know. Your UVMeshable approach - perhaps combined with the mesh
camera or user defined one - likely provides a path to address my
central complaint about our uv_mapping today.
Namely, not having a way to, somewhat, easily create the maps for the
shapes where uv_mapping is supported. Not running it yet, but :-).
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
