POV-Ray : Newsgroups : povray.general : Parametric surfaces faster than thought. Server Time
14 Oct 2024 03:29:38 EDT (-0400)
  Parametric surfaces faster than thought. (Message 1 to 10 of 10)  
From: William F Pokorny
Subject: Parametric surfaces faster than thought.
Date: 4 May 2020 06:13:13
Message: <5eafeab9$1@news.povray.org>
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

From: Mr
Subject: Re: Parametric surfaces faster than thought.
Date: 6 May 2020 07:00:00
Message: <web.5eb29878221855fc6adeaecb0@news.povray.org>
Thomas de Groot <tho### [at] degrootorg> 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

From: Cousin Ricky
Subject: Re: Parametric surfaces faster than thought.
Date: 9 May 2020 12:15:39
Message: <5eb6d72b$1@news.povray.org>
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

From: Bald Eagle
Subject: Re: Parametric surfaces faster than thought.
Date: 11 May 2020 07:20:00
Message: <web.5eb934c7221855fcfb0b41570@news.povray.org>
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

From: Le Forgeron
Subject: Re: Parametric surfaces faster than thought.
Date: 11 May 2020 13:16:03
Message: <5eb98853$1@news.povray.org>
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

From: Le Forgeron
Subject: Re: Parametric surfaces faster than thought.
Date: 14 Jun 2020 12:36:48
Message: <5ee65220$1@news.povray.org>
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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.