On 12/13/24 10:08, Bald Eagle wrote:
> So that's an inbuilt function that outlines the bounding box of the isosurface?

It's the bounding box of the polygon object. They are similar in the end.

...
#declare PgonCW = polygon { // Normal set to -z
     10,
     <-1.0, -1.0>, <-1.0, +1.0>, <+1.0, +1.0>, <+1.0, -1.0>,
     <-1.0, -1.0>,
     <-0.6, -0.6>, <-0.6, +0.6>, <+0.6, +0.6>, <+0.6, -0.6>,
     <-0.6, -0.6>,
     bounded_by { box { <-1.5,-1.5,-0.5>, <+1.5,+1.5,+0.5> } }
}
...
#declare Offset = 0.04;
#declare Fn00 = function {
     pattern {
         potential {
             PgonCW
             ip_type 6
             ip_offset Offset
             ip_mode 0
         }
         raw_wave
     }
}
#declare Iso00 = isosurface {
     function { Fn00(x,y,z) }
     contained_by {
         box {
             min_extent(PgonCW)-10*Offset,
             max_extent(PgonCW)+10*Offset
         }
     }
     threshold 0
     accuracy 0.0005
     max_gradient 1.1
     pigment { Gold }
}
...

> Is there one for the bounding sphere {} as well?

The bounding in play here is the base bounding box used for the method 
1 & 2 overall object bounding. (Internally the last level of bounding is 
sometimes a sphere...)

Aside: One of the reasons to implement the bounding box potential 
patterns was to create an easier way to view what is happening with the 
global bounding. I have ideas for better performance - especially with 
method 2 which is under-exploited for the kinds of shapes and base 
bounding we typically have (why I believe it mostly doesn't help much). 
Anyhow...

You can get a sort of bounding sphere based upon the bound box 
coordinates - which always exist whether other last level bounding is a 
sphere (or skipped as with spheres).

...
#declare OffsetVec = (max_extent(PgonCW)-min_extent(PgonCW))/2.0;
#declare Offset    = vlength(OffsetVec);
#declare Fn99 = function {
     pattern {
         potential {
             PgonCW
             ip_type 2
             ip_offset  Offset
             ip_mode 0
         }
         raw_wave
     }
}
#declare Iso99 = isosurface {
     function { Fn99(x,y,z) }
     contained_by {
         box {
             min_extent(PgonCW)-2*Offset,
             max_extent(PgonCW)+2*Offset
         }
     }
     threshold 0
     accuracy 0.0005
     max_gradient 1.1
     pigment { White }
}
...

 > Do you think it would be too much trouble to add the middle lines
 > crossing through the center?

Could be done by change the 'dense' bbox potential form or as another 
ip_type I guess. Maybe as another light form with just those connections 
that folks can merge in if they wish... I'll think about it. There are 
trade offs.

 > I'm also envisioning another function that returns one of the points
 > on the ip_type 3 grid. Start by envisioning picking integer values for
 > a "uvw" vector <-1, 0, 1> of the bounding box and returning that?
 > <x,y,z> point.
 > I think it would be interesting to return points for any uvw value
 > passed into the function to get the corresponding x,y,z value in 3D
 > space.

Yeah, there are a lot of possibilities here and I'll add that one to the 
list banging around in my head.

Another idea on my list is using the polygon or polygon like interface 
for specifying coordinates which people can then transform and afterward 
query for a spatially updated point list.

I have some of these sorts of features in my TCL wrapper scripting - and 
being able to manipulate point lists in this way is useful.

Some years back I took a step toward that support with yuqk's new 
'pattern_modifiers' keyword for capturing and using complex spatial 
manipulations:

        #declare PigMods00 = pigment {
         color Black
         rotate 45*x
         scale <1.3,2.3,0.1>
         rotate -15*y
         scale 9
         warp { turbulence <0.1,0.1,0.1>
                octaves 5 omega 0.07 lambda 7.75 }
         scale 1/9
         rotate x*60 rotate z*35
         translate <0.1,0.1,-0.1>
         scale 1.4
     }
     #declare FnPigMods00 = function {
         pattern_modifiers { PigMods00 }
     }
     #declare Fn00 = function (x,y,z) {
         f_sphere(FnPigMods00(x,y,z).x,
                     FnPigMods00(x,y,z).y,
                     FnPigMods00(x,y,z).z,0.3)
     }

but some polygon-list like capability would be easier conceptually and 
as a tool easier to use I think. Ref:

https://news.povray.org/povray.beta-test.binaries/thread/%3C5dbc6985%241%40news.povray.org%3E/

This might be something I try as a kind of potential pattern extension 
near term, but ultimately some kind of dedicated support for point list 
manipulations in SDL would be better.

Bill P.

Post a reply to this message