In part due a bug report, and in part due an offline discussion with jr 
regarding an effort more than 15 years ago to implement a df3 file 
encoding format based upon 2d polygons in each z plane as a compression 
technique - I've been working on the polygon object's code.

The result is updated code which fixes a number of bugs and, of more 
interest to me, implements potential{} value pattern support(*) for the 
polygon object.

(*) The potential{} pattern is new to v3.8 and the initial 
implementation supports the blob{} and isosurface{} objects which 
naturally have a value fields defining the resulting shape.

The potential{} pattern support for the polygon object is based upon an 
expanded concept for what potential pattern support for an object means 
in general. It can be about more than reproducing the original shape as 
an isosurface or pattern.

Attached is an image with some examples and my initial pass at some 
documentation for yuqk's polygon object.

The upper left two images are the same as one gets with official POV-Ray 
releases. The green specifies the points in clockwise order. The red in 
counter-clockwise order.

The upper right two images show the 'ip_type 0' potential pattern 
support which is a sort of infinite in z inside / outside test. The 
inside values being (1.0*('ip_offset value')). By wrapping these 
potential{} patterns in function{}s, this 'ip_type 0' is essentially a 
drawn drawn polygon-tiles and calk method. A numerically noise proof, 
and infinitely flexible alternative to the 'pavement' and 'tiling' value 
patterns, for example.

The bottom row of images show some of the kinds of potential patterns 
returned. The left most bottom being one of three possible 
bounding-box-based potential patterns.

The remaining three images in the bottom row return polygon point 
values, connections between polygon points values and, on the very 
right, a stand-in 3D potential somewhat similar to the inbuilt 
f_rounded_box() function's value field - but defined by the polygon 
object's 2D shape.

Bill P.

Post a reply to this message

Attachments:
Download 'polygon.txt' (14 KB) Download 'polygonupdates.png' (17 KB)

Preview of image 'polygonupdates.png'

William F Pokorny <ano### [at] anonymousorg> wrote:

Polygon as a df3 compression method.
Nice idea.

I'm not sure what this "offset" value is, but I'm wondering if there could be
some sort of z-axis control that allows one to make things analogous to the
prism's conic sweep.
And for that matter, I'm wondering if the prism can be worked into this whole
thing.

https://news.povray.org/povray.general/thread/%3Cweb.5d75c2d16af53e9cecc0fada0%40news.povray.org%3E/?mtop=431108

illustration:

https://news.povray.org/povray.binaries.images/thread/%3Cweb.5e97c744fd34edcfb0b41570%40news.povray.org%3E/?ttop=441730
&toff=400

> The upper right two images show the 'ip_type 0' potential pattern
> support which is a sort of infinite in z inside / outside test. The
> inside values being (1.0*('ip_offset value')). By wrapping these
> potential{} patterns in function{}s, this 'ip_type 0' is essentially a
> drawn drawn polygon-tiles and calk method. A numerically noise proof,
> and infinitely flexible alternative to the 'pavement' and 'tiling' value
> patterns, for example.

Not sure what I'm seeing there - is there a rotational offset?
Could the rotational offset be defined as rotation per unit, to get a spiraling
effect?
Maybe scratch whatever the "offset" currently is and incorporate a matrix
transform for greater flexibility?

> The bottom row of images show some of the kinds of potential patterns
> returned. The left most bottom being one of three possible
> bounding-box-based potential patterns.

That's definitely pretty cool - more explanation on what that's about, and show
the other two?

I see that the center point of the outer polygon is included in that diagram -
what if instead of drawing the even division of the AABB to give that "+", the
center point was "connected" to the vertices with rays, with the potential
varying in between the rays (to give an "X")
(or a star, like the macro I used here:
https://news.povray.org/web.54414d9ccbb3d8155e7df57c0%40news.povray.org)

> The remaining three images in the bottom row return polygon point
> values, connections between polygon points values and, on the very
> right, a stand-in 3D potential somewhat similar to the inbuilt
> f_rounded_box() function's value field - but defined by the polygon
> object's 2D shape.

One thing which could be cool, would be to re-order the connection points so
that they now skip every other point.  With odd-number polygons, one would get a
star.

Is there a way to easily achieve what is essentially a convex-hull effect -
where none of the inner sub-polygon points "count"?
Using the potential feature, one could then (potentially <--- Ha!) easily make
isosurfaces...


- BW

Post a reply to this message

On 12/11/24 09:49, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
> I'm not sure what this "offset" value is, but I'm wondering if there could be
> some sort of z-axis control that allows one to make things analogous to the
> prism's conic sweep.

Once we have a potential{} pattern in hand, we have access to all the 
usual value and spatial modifiers - plus functions based on the 
potential pattern (you can scale in z). How well it all works in 
practice, I'm not sure. The door to this functionality has just opened 
for me too.

> And for that matter, I'm wondering if the prism can be worked into this whole
> thing.

The thought occurred to me too :-). I don't know, maybe some potential 
support eventually there too. It would be hard to handle the prism as 
I'm handling the polygon's potential pattern.

In yuqk, shapes with a well defined inside (already 3D) can use the 
soft_object{} and hard_object{} patterns to turn things into some sort 
of value field pattern.

> 
>> The upper right two images show the 'ip_type 0' potential pattern
>> support which is a sort of infinite in z inside / outside test. The
>> inside values being (1.0*('ip_offset value')). By wrapping these
>> potential{} patterns in function{}s, this 'ip_type 0' is essentially a
>> drawn drawn polygon-tiles and calk method. A numerically noise proof,
>> and infinitely flexible alternative to the 'pavement' and 'tiling' value
>> patterns, for example.
> 
> Not sure what I'm seeing there - is there a rotational offset?

Yes. The upper right image adds a 'rotate z*45' to one of the two 50% 
grey images exactly overlapping for the white areas in the image just to 
the left.

> Could the rotational offset be defined as rotation per unit, to get a spiraling
> effect?

Yes. Any sort of normal spatial modifier is available.

> Maybe scratch whatever the "offset" currently is and incorporate a matrix
> transform for greater flexibility?

The offset (as positive values) is usually subtracted from the distance 
formulas being used internally (roughly specifying a radius or 
thickness), but it's sometimes used as a simple value multiplier too - 
as in the case of the 'ip_type 0'.

> 
> That's definitely pretty cool - more explanation on what that's about, and show
> the other two?

Currently there are two bounding box frameworks available (ip_type 3 is 
the one shown) and a center of bounding box distance. In other words, 
there are potential patterns for the polygon based upon the shapes 
bounding box rather than the shape itself. I'm unsure how useful this 
capability is...

> 
> I see that the center point of the outer polygon is included in that diagram -
> what if instead of drawing the even division of the AABB to give that "+", the
> center point was "connected" to the vertices with rays, with the potential
> varying in between the rays (to give an "X")
> (or a star, like the macro I used here:
> https://news.povray.org/web.54414d9ccbb3d8155e7df57c0%40news.povray.org)
> 

...

> One thing which could be cool, would be to re-order the connection points so
> that they now skip every other point.  With odd-number polygons, one would get a
> star.
> 
> Is there a way to easily achieve what is essentially a convex-hull effect -
> where none of the inner sub-polygon points "count"?
> Using the potential feature, one could then (potentially <--- Ha!) easily make
> isosurfaces...
> 

As to the rest of your suggestions, what I have in mind is to implement 
a new keyword called 'laxparse on|off' or 'lax_parsing on|off' for the 
polygon object which would free the polygon's parsing so we can specify 
sets of four connection values:

<2D vector of first pt> <2D vector second pt> <offset> <taper on 't'>

The code here has similarities to the previously implemented f_path() 
inbuilt function in yuqk. In f_path() one specifies a collection of 
points in space; followed by a limited number of 'connection 
specifications' between those points.

I don't think I've posted examples, but f_path() can change the base 
radius (offset to distance), the direction of every connection it makes 
- and taper the offset value up or down as each connection is made. 
This includes tapers which stop or start short; only pointing toward the 
closing or starting point. These f_path(), per connection, hooks are 
sitting in the polygon object's potential code - currently unused.

---

It might be a push in this direction leads eventually to a new 3D point 
set shape which would be a collection of 3D spheres by default, behind 
which would be potential{} pattern support allowing arbitrary point to 
point 'connections' in 3D rather than 2D.

The performance with the distance based methods degrade as the number of 
total measures needed for the overall value field go up. Without max 
value clamping on each component measure the value field's gradient 
values get pretty choppy away from any resultant surface too. In short,
there is much I don't know about the practical use / limits here.

Bill P.

Aside: One of the things I noticed while playing with a polygon made up 
of a bunch of small triangle loops is that we can get voronoi like 
results due the distances to other than just points in space. Maybe this 
an obvious result I guess... :-)

Post a reply to this message

On 12/11/24 09:49, Bald Eagle wrote:
> That's definitely pretty cool - more explanation on what that's about, and show
> the other two?

Attached an image of four isosurfaces occupying the same bounded space. 
Using one polygon object, but with four different potential pattern 
settings wrapped in four functions for the isosurfaces.

I used a 'bounded_by' to create an overly large bounding box and, on 
rendering, the flag -ur so it wasn't ignored.

The white frame is what the 'ip_type 3' bounding frame looks like. (I 
had a bug in this code I didn't see just looking at it as a pigment on a 
plane. Now fixed.)

The yellow-brown shape is the 'ip_type 6' potential value field of the 
polygon itself.

The blue-grey rods the 'ip_type 4' spheres for polygon points scaled big 
in z so as to clip on the isosurfaces bounding box.

The yellow lines the 'ip_type 5' connected point to point value field 
scaled slightly larger in z so the smaller ip_offset protrudes enough to 
just show up.

Bill P.

Post a reply to this message

Attachments:
Download 'pgonpoteniso.png' (172 KB)

Preview of image 'pgonpoteniso.png'

William F Pokorny <ano### [at] anonymousorg> wrote:

> The white frame is what the 'ip_type 3' bounding frame looks like. (I
> had a bug in this code I didn't see just looking at it as a pigment on a
> plane. Now fixed.)

So that's an inbuilt function that outlines the bounding box of the isosurface?
Is there one for the bounding sphere {} as well?

I'm wondering what the syntax, and arguments for that function are.
Do you think it would be too much trouble to add the middle lines crossing
through the center?

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.

- BW

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:

> The yellow-brown shape is the 'ip_type 6' potential value field of the
> polygon itself.

> The yellow lines the 'ip_type 5' connected point to point value field
> scaled slightly larger in z so the smaller ip_offset protrudes enough to
> just show up.

Out of curiosity about the crossing number / normal direction, and to give you
another debugging test:

Have you tried making a pentagonal arrangement, with the connectivity
every-other point, to produce a star?

Post a reply to this message

On 12/13/24 10:48, Bald Eagle wrote:
> Out of curiosity about the crossing number / normal direction, and to give you
> another debugging test:
> 
> Have you tried making a pentagonal arrangement, with the connectivity
> every-other point, to produce a star?

I'd not done it with this new polygon / polygon-potential code. See the 
attached image - crossing star form on the right.

FWIW. The right form with f_path() previously:

https://news.povray.org/povray.pov4.discussion.general/thread/%3C651d4739%241%40news.povray.org%3E/

Bill P.

Post a reply to this message

Attachments:
Download 'fiveptstarforbw.png' (59 KB)

Preview of image 'fiveptstarforbw.png'

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