Am 03.06.2018 um 05:24 schrieb Hedrondude:
> I'm using POV-Ray to render cross sections of four and five dimensional uniform
> polytopes - especially star polytopes.  These renders can be seen on my website
> http://www.polyope.htm/hedrondude/polychora.htm  I use the polygon keyword quite
> a bit, but it only renders with the binary filling (all odd density regions gets
> filled in, even density are left as holes) which forces me to manually fill in
> all the non-0 even density regions.  This isn't too bad for simple polytopes,
> but with more complex ones, this gets very tedious.  Is it possible to render
> polygons with density filling (all non-0 density regions gets filled in - i.e.
> filled in by the 'winding method') or better yet could this be a feature for
> POV-Ray 3.8 where there is a density filling option for the polygon keyword.  I
> would suggest something like this:
> 
> #local obj=polygon {45,v1,v2,v3,......,v44,v1 density}

I'm not sure I understand how Density Filling is defined; I had a look
at http://www.polytope.net/hedrondude/fillings.png, but the technical
terms "density" and "orientable" used in there are greek to me. (Also,
it certainly doesn't help that it is depicted as giving results
indentical to Natural Filling).

At the end of the day, we'll need an algorithm to implement, so ideally,
can you describe how one would test whether a given point (Xp,Yp) is to
be coloured black or white, based on the list of points (X1,Y1),
(X2,Y2), ... (Xn,Yn)?

The closer that algorithm is to our current Binary Filling method, the
easier it would be to implement.

The current algorithm implementing Binary Filling takes each edge
(Xa,Ya)->(Xb,Yb), tests whether it intersects the ray
(Xp,Yp)->(+inf,Yp), and keeps track of whether the number of
intersecting edges is odd or even.

For example, this algorithm would be easy to adapt to Solid Filling, by
just keeping track of whether the number of intersecting edges is non-zero.


I have a hunch that a similar algorithm to implement Density Filling
would take each edge (Xa,Ya)->(Xb,Yb), test whether it intersects the
ray (Xp,Yp)->(+inf,Yp), and if so, test whether Ya>Yb -- and then do
/something/ with the result; compute the difference between the Ya>Yb
and Ya<Yb intersections, maybe? Or keep tabs on the distances of the
intersections, and colour the point depending on whether Ya>Yb?

I'd like to point out that such an algorithm may break down "near"
regions where a portion of the polygon is "flipped over" (if you know
what I mean; but I suspect that's what is meant by "non-orientable", so
you probably already know that).


Note that an algorithm along the lines of, "examine all edges
immediately adjacent to the region the point is in", would require
drastic changes to the polygon code, as the current implementation has
no concept of "regions": All it knows about are the coordinates and
ordering of the original defining vertices.

Post a reply to this message