POV-Ray : Newsgroups : povray.binaries.images : Trick pigment_map into selecting functions to run. Server Time: 28 May 2020 21:43:56 GMT
  Trick pigment_map into selecting functions to run. (Message 1 to 5 of 5)  
From: William F Pokorny
Subject: Trick pigment_map into selecting functions to run.
Date: 27 Apr 2020 15:40:13
Message: <5ea6fcdd$1@news.povray.org>
I've had in mind with the function and pattern work mostly described in 
povray.beta-test.binaries to be able to more easily run subsets of 
functions into an effective min() of functions using a pigment_map 
instead of running all input functions/shapes on each evaluation.

It works well. In the attached scene the traditional min method for the 
six superellipsoids takes more than twice the time as the pigment_map 
trick.

Difficult I think, but you can probably make this trick work in existing 
v3.7 or v3.8 by shifting around the thresholds and ranges.

By using the pigment_map we run only the subset of superellipsoid 
functions in the current gradient x range - so no more than two. Yes, 
with a more expressive pigment_map we could get to no more than one.

Aside. I wonder too about blending shapes along the gradient with a 
similar pigment_map set up.

Aside 2. Yep, the pigment_map mechanism is doing extra work for colors 
not really needed here for the isosurface, but I suspect that is 
something which could be exploited too where the color channels have 
been shifted for some effect.

Scene file and image attached. Scene as posted runs only with my current 
povr, but the basic approach would be the same in v3.7 or v3.8.

Bill P.

//----
#version unofficial 3.8;
global_settings { assumed_gamma 1 }
#declare Grey50 = srgb <0.5,0.5,0.5>;
background { color Grey50 }
#declare Camera00 = camera {
     perspective
     location <3,3,-3.001>*1.2
     sky y
     angle 35
     right x*(image_width/image_height)
     look_at <0,0,0>
}
#declare White = srgb <1,1,1>;
#declare Light00 = light_source { <50,150,-250>, White }
#declare Red = srgb <1,0,0>;
#declare CylinderX = cylinder { -1*x, 1*x, 0.01 pigment { Red } }
#declare Green = srgb <0,1,0>;
#declare CylinderY = cylinder { -1*y, 1*y, 0.01 pigment { Green } }
#declare Blue = srgb <0,0,1>;
#declare CylinderZ = cylinder { -1*z, 1*z, 0.01 pigment { Blue } }
#include "functions.inc"

#declare Fn00 = function { f_superellipsoid(x*6,y*2,z*2,0,1/3,1/4) }

#declare Fn00a = function { Fn00(x-1.6,y,z) }
#declare Fn00b = function { Fn00(x-1.0,y,z) }
#declare Fn00c = function { Fn00(x-0.4,y,z) }
#declare Fn00d = function { Fn00(x+1.6,y,z) }
#declare Fn00e = function { Fn00(x+1.0,y,z) }
#declare Fn00f = function { Fn00(x+0.4,y,z) }

#declare Fn01 = function {   // Traditional approach
     min(Fn00a(x,y,z),Fn00b(x,y,z),Fn00c(x,y,z),
         Fn00d(x,y,z),Fn00e(x,y,z),Fn00f(x,y,z)
     )
} // All six min input fncts run on each Fn01 call.

// Use pigment_map to evaluate fewer functions
// (Though making almost 6x more VM calls)
#declare Pg00a = pigment { function { Fn00a(x,y,z) }
     function_interval color_map { [-1 rgb -1] [1 rgb 1] } }
#declare Pg00b = pigment { function { Fn00b(x,y,z) }
     function_interval color_map { [-1 rgb -1] [1 rgb 1] } }
#declare Pg00c = pigment { function { Fn00c(x,y,z) }
     function_interval color_map { [-1 rgb -1] [1 rgb 1] } }
#declare Pg00d = pigment { function { Fn00d(x,y,z) }
     function_interval color_map { [-1 rgb -1] [1 rgb 1] } }
#declare Pg00e = pigment { function { Fn00e(x,y,z) }
     function_interval color_map { [-1 rgb -1] [1 rgb 1] } }
#declare Pg00f = pigment { function { Fn00f(x,y,z) }
     function_interval color_map { [-1 rgb -1] [1 rgb 1] } }

#declare PgOne = pigment { color rgb 1 }

#declare Fn02 = function {
     pigment {
         gradient x raw_wave
         pigment_map {
             [-2 Pg00d]
             [-1.3-1e-6 Pg00d]
             [-1.3+1e-6 Pg00e]
             [-0.7-1e-6 Pg00e]
             [-0.7+1e-6 Pg00f]
             [-0.1-1e-6 Pg00f]
             [-0.1+1e-6 PgOne]
             [+0.1-1e-6 PgOne]
             [+0.1+1e-6 Pg00c]
             [+0.7-1e-6 Pg00c]
             [+0.7+1e-6 Pg00b]
             [+1.3-1e-6 Pg00b]
             [+1.3+1e-6 Pg00a]
             [+2 Pg00a]
         }
     }
}

// povr2 trick.pov +a0.0 +am1 +r3
#declare Iso99 = isosurface {
   //function { Fn01(x,y,z) }       // 757.541s
     function { Fn02(x,y,z).red }   // 353.499s  -53.33%
     contained_by { box { <-2.0,-0.6,-0.7>,<2.0,0.6,0.7> } }
     threshold 0
     accuracy 0.0005
     max_gradient 15.1
     pigment { color Green }
}

//--- scene ---
     camera { Camera00 }
     light_source { Light00 }
     object { CylinderX }
     object { CylinderY }
     object { CylinderZ }
     object { Iso99 }


Post a reply to this message


Attachments:
Download 'trick.png' (62 KB)

Preview of image 'trick.png'
trick.png


 

From: William F Pokorny
Subject: Re: Trick pigment_map into selecting functions to run.
Date: 28 Apr 2020 10:24:21
Message: <5ea80455$1@news.povray.org>
On 4/27/20 11:40 AM, William F Pokorny wrote:
...
> 
> Aside. I wonder too about blending shapes along the gradient with a 
> similar pigment_map set up.
> 
...

Busy with real life today, but quickly tried the isosurface pigment_map 
blend idea. Raw shapes shown on the left and the pigment_map blended 
result for the +x shapes on the right.

Promising I guess. Understand the sphere's effect on the two 
superellipsoids, but don't understand why the sphere 'blended' as it 
did. Suppose something I don't understand about the value field of 
superellipsoids? Oscillations where there are positive values?

Oh, it caught my eye the scene had a comment claiming an almost 6x 
increase in vm calls - which is wrong. It was more like 3.2x, not sure 
where I got the 6x...

Bill P.


Post a reply to this message


Attachments:
Download 'storypigisoblend.png' (61 KB)

Preview of image 'storypigisoblend.png'
storypigisoblend.png


 

From: Alain Martel
Subject: Re: Trick pigment_map into selecting functions to run.
Date: 28 Apr 2020 16:20:21
Message: <5ea857c5$1@news.povray.org>
Le 2020-04-27 à 11:40, William F Pokorny a écrit :

I've seen and used some other ways to obtain the same :
Using mod(Axis, Value) to manipulate the coordinates of one or even all 
axis.
Using warp{repeat Something}

Those can allow you to have 100's of parts, you only have to vary the 
dimension of the container to change the number of «objects».


Post a reply to this message

From: William F Pokorny
Subject: Re: Trick pigment_map into selecting functions to run.
Date: 29 Apr 2020 14:17:04
Message: <5ea98c60$1@news.povray.org>
On 4/28/20 12:20 PM, Alain Martel wrote:
> Le 2020-04-27 à 11:40, William F Pokorny a écrit :
> 
> I've seen and used some other ways to obtain the same :
> Using mod(Axis, Value) to manipulate the coordinates of one or even all 
> axis.
> Using warp{repeat Something}
> 
> Those can allow you to have 100's of parts, you only have to vary the 
> dimension of the container to change the number of «objects».

Yes, there's some relation to those methods.

Expect you understand, but I want to be clear the technique and aim here 
is different than a mod()/fmod() regular spacing variation. My initial 
test and image was miss-leading due spacing and appearance.

What we are working toward is a technique which allows many completely 
different functions - or patterns (object for example) - to run via a 
'pattern' wrapped, 'pattern' bounding mechanism with no requirement of 
regularity on the bounded patterns/functions/shapes.

A more complete general implementation would probably lean on cells (the 
hash3d mechanism under it) - or something similar set up just for the 
purpose. Though, strictly, the bounding part need not have a regular 
geometric basis either...

Overlap is OK and the hope is to work out how to work with / exploit 
those sorts of set ups to create complex 'stuff.' :-)

---

The 3.2x increase in VM calls in the initial test case has been bugging 
me over the past day. It should be <1.5 I think!

My guess is the map blending mechanism is NOT today avoiding dual 
interval end point evaluations where the texture/pigment pointer is 
identical. In other words, I suspect it's doing the same end point 
'evaluation' twice ahead of blending, when it could run one and return 
when they match.  On my list to dig into that thought. We'll see.

Bill P.


Post a reply to this message

From: William F Pokorny
Subject: Re: Trick pigment_map into selecting functions to run.
Date: 29 Apr 2020 17:26:33
Message: <5ea9b8c9@news.povray.org>
On 4/29/20 10:17 AM, William F Pokorny wrote:
> On 4/28/20 12:20 PM, Alain Martel wrote:
...
> 
> Overlap is OK and the hope is to work out how to work with / exploit 
> those sorts of set ups to create complex 'stuff.' :-)
> 

Attached a blended shape using the technique. Earlier problems me being 
rushed and sloppy. Didn't set functions along x axis correctly and what 
we were seeing in the blend were very thin shells of noise where the 
blend turned negative(1)

Bill P.

(1) - Similar looking with all spheres too. Makes me think 'maybe' 
seeing something with the differences between floats (color 
representations) and doubles there. We do today cast back and forth 
between float representations with this technique.


Post a reply to this message


Attachments:
Download 'blend00.png' (36 KB)

Preview of image 'blend00.png'
blend00.png


 

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