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

> Why 'solid'?

Because that's the default case.
It's only not solid when you do the additional work to "hollow it out" with the
open keyword.
Let's say what we mean and mean what we say, rather than misleading the reader /
new user.

Calling it something slightly different but more accurate in the documentation
is (in my mind) better / more correct / proper, and leads to a better flow of
the documentation text when we get to invoking the keyword.
It also doesn't change the acronym sor {}.

I haven't rigorously experimented with the lathe object yet, but I've rendered a
non-closed curve, and it was solid / automatically closed.

> The 'Surface Of Revolution' terminology is, I think, the more common -
> for both objects.

I don't know what's "more common" but I'm less interested in what other people
do than the actual results of what our code does and how we describe it.
It's not (only) an infinitely thin surface - you can use it in CSG.  So why are
we calling it one?

> For me, 'lathe' implies solidness when we can create,
> for example, open shapes, torus shapes or many 2d profiles wrapped
> around the y axis at the same time.

I was renaming sor, not lathe.  I haven't gotten to scrutinizing the lathe yet,
so we'll see what I can learn / break with that one.

> Other random thoughts:
>
> 1) Both objects (mostly) end up as uni-variate polynomials (power series
> form) as fed to the solvers.

Seems right - I'm just doing this in 15-20 minute spurts, as the opportunities
arise.

> 2) The polynomial order the solvers see with the lathe depends on the
> type of spline used.

Well, yes. ("obviously") But the issue that I was trying to clarify was why the
lathe always has to solve a polynomial that is twice the _degree_ of the spline
segment being handled. (whereas the sor is happy to stick with the actual degree
of the spline)

>
> 3) For the attached image the sor is on the left and the lathe on the
> right. I'm using yuqk, so the solvers are changed from POV-Ray proper.
>
>      5
>      <+1.5,-0.1>
>      <+0.4,0.0>
>      <+0.3,0.5>
>      <+0.4,0.9>
>      <+1.5,1.1>

Please do not mislead - you're clearly using a non-specified type of spline, and
the open keyword.


> Aside: What 'sturm' actually does (or not) with any given shape where
> the keyword is supported is very muddy in the code / documentation - a
> little less so with the yuqk fork. For example, the sturmian solver is
> always used where the polynomial order is >4 no matter the use of
> 'sturm'. In official POV-Ray 'sturm' often doesn't control the inside
> test code when solving for polynomial's for roots, where in yuqk it more
> often (aways?) does. Further, in yuqk where 'sturm' is specified with
> lower order polynomials (order <= 4), the sturmian solver is used, where
> in official POV-Ray it often is not. In the official code base, there is
> too order reduction code (removed in yuqk) which routes equations to
> particular solver methods no matter the 'sturm' setting.

I have followed some of that code, and see all of that in there.
I recall posting something about the sturmian root solver in the past - couldn't
find it the last time I searched.


> As for parametrics, agree with much of what you suggest, but thinking
> maybe a stand alone program cleaner / better.

It may be, however I have a strong distaste for separable items, as well as
feeling that POV-Ray should have all of its own things as a starting point.

For example, just
> trundling through u,v coordinates forces very tiny steps (large numbers
> of triangles) universally where shapes / surfaces have sharp-ish edges /
> small features one wants maintained in the rendered result. Better would
> be optimizations of the initial mesh to reduce the size while
> maintaining 'sharp' / 'small' features

Yes, I've read some about doing just that.  I feel I'll be prepared to
understand further reading on that subject due to my work on surface curvature.

> - this sort of optimization
> should probably be done outside of SDL parsing.

It might _best_ be done that way, but I think not exclusively.
Let the user set an accuracy variable like in other shapes.

> In any case we should
> look again at what was done for this feature in hgpovray38.

Yes, always an excellent idea.  I can only unravel one code base at a time
(usually :D)

Ingo:

> A side effect that I would welcome, if we can generate internal mesh of objects,
> global meshify setting, we can do openGL pre-views.

Oh, yeah.  I hadn't thought about that!

> An other side effect, subdivision modelling, though purely by script it's not
fun.

I have dabbled with that in the past - and wasn't there a whole POV-Ray version
that had that sort of code in it?   May be time to revisit.

> If I could write POVRAY5, i'd look into language and parsers in such a way that
> it can spit out multiple things to serve multiple rendering back ends.

That would be nice - though unsure if we could handle _everything_ that way.
But keep talking - I'm listening.  :)



-BW

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:

> That would be nice - though unsure if we could handle _everything_ that way.
> But keep talking - I'm listening.  :)
>
>

"everything", wrt mesh depending on the object, either Parametric or Marching
"Cubes" / Dual Contouring. Prism, SOR, Lathe, all mesh extrusion/rotation of
some kind (is kind of parametric). The odd one out may be the sphere sweep
depending on the kind of result one wants.

Text I've never looked in to, maybe lofting a mesh, kind of parametric. ('t
would be nice to have the path of a glyph available in SDL for
interpolation/spline)

Lofting may be a mesh thing that has no equivalent in the "solid" world.

Subdivision modelling. Iirc John VanSickle wrote a macro for it. I don't
remember a POV-Ray patch that was able to do it, may have missed it.

An other thing that comes with mesh is displacement mapping (combined with
subdivision or parametric) as is currently possible through the macro route an
using an image as a function.

For CSG there are mesh libraries.

"everything" wrt backend. When there would be a meshify option for objects, 3D
printing etc. would be easier. It would require testing for closed mesh' and
probably a few more things.

I've been dabbling with Half Edge Mesh data structures in Nim. Once you have one
it is relative easy to convert it to any mesh format. They are also useful for
operations on mesh.

Almost all of this is available in libraries, https://www.cgal.org/ for example.

ingo

Post a reply to this message

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

> Aside: What 'sturm' actually does (or not) with any given shape where
> the keyword is supported is very muddy in the code / documentation

What _anything_ actually does is often very muddy in the code / documentation.

It shouldn't take me a week to unravel something like sor because there's a
complete absence of any explanatory / guiding comments.

Some people have this attitude that "Well, it just _expected_ that if you're
using a computer graphics package, that you'd at least know about XYZPDQ...."
But I'd say that from a developer's perspective, the comments ought to be in
there just as part of good coding practice, and not every c++ coder is going to
be a graphics expert or experienced mathematician.  I'm perpetually mystified as
to why someone would be expected to "just figure it out", when someone already
had it all figured out when they wrote the source code.

I would say that if POV-Ray still actually has an active user base, and we want
to actually make the push forward to 4.0 or 5.0 or whatever --- then folks
should take a peek into the code for their favorite object, one that they
understand the CG theory of, or one that they've always been curious about how
it worked - and make some notes about what the source code does and how.

Because even just having a patch version that consists of nothing more than
user-added commentary and theoretical references for all of the various
algorithms would be a big step forward for us, and a giant help to anyone we
might find willing to be a developer.

The comments don't even necessarily have to be IN "the code" - we could just
have a .h, a .cpp, and then an additional .doc or some other extension (.prd Pov
Ray Documentation) text file where everything can get hashed out and unfinished
work can be left as empty outline sections for others to continue work on.

If we had all of that available as an additional "developer documentation"
section of the distribution, then 1. our code would be far more well documented
than it currently is, 2. anyone debugging or adding to the code would be way
ahead of the curve rather than way behind, and 3. all of that theory and
under-the-hood operational stuff would be readily available as a resource to
point to when people on the forum ask the usual questions.

- BE

Post a reply to this message

"ingo" <nomail@nomail> wrote:

> The odd one out may be the sphere sweep
> depending on the kind of result one wants.

I'm guessing that we might be able to use what was learned in the whole tubular
function thread to rewrite the sphere sweep object code in triangle mesh form.

(Just because it would be cool, I'd like to see that hexagonal surface
tesselation used to cover surfaces, because the triangle mesh is just a subset
of that method)

> Text I've never looked in to, maybe lofting a mesh, kind of parametric. ('t
> would be nice to have the path of a glyph available in SDL for
> interpolation/spline)

Cousin Ricky and I have both manually converted text to splines.
Clipka was talking about converting all of the text to prisms.

> Lofting may be a mesh thing that has no equivalent in the "solid" world.

I had been interested in creating lofting some time back, but never had the
opportunity to bite into that. (yet...  ;) )

> Subdivision modelling. Iirc John VanSickle wrote a macro for it. I don't
> remember a POV-Ray patch that was able to do it, may have missed it.

http://news.povray.org/povray.news-submissions/message/%3C40a14e8c%40news.povray.org%3E/#%3C40a14e8c%40news.povray.org%
3E

https://news.povray.org/povray.advanced-users/thread/%3C53de2167%40news.povray.org%3E/

https://news.povray.org/povray.unofficial.patches/message/%3C40aeaf37%40news.povray.org%3E/#%3C40aeaf37%40news.povray.o
rg%3E


> For CSG there are mesh libraries.

Ah, libraries . . . and licenses.  :/

> I've been dabbling with Half Edge Mesh data structures in Nim. Once you have one
> it is relative easy to convert it to any mesh format. They are also useful for
> operations on mesh.

Very interested.
I've been wanting to do a user-controlled Voronoi pattern / object, and one of
the algorithms involves using a half-edge data structure.

- BE

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "ingo" <nomail@nomail> wrote:

> Ah, libraries . . . and licenses.  :/

Politics and silo's :(

lofting in SDL:
https://news.povray.org/povray.binaries.utilities/thread/%3CXns94D4AF6BE46A0seed7%40news.povray.org%3E/?ttop=445117&tof
f=150


half edge mesh for for voronoi is a good one. In 2d each cell is a polygon, in
3d a mesh of polygons. Multiple connected cells may need some special design in
3d as most versions don't like manifolds, more than two faces connected to an
edge, so less than halve an edge. Can get messy. Wait, there's space between the
cells, are they ever touching/connected? If not it's just a "bag of cells" and
half edge works fine. I'll try it a bit ... mmm ... if jr. allows as he gave me
a job I still haven't finished.

Prisms/extrusions for text, yes of course.

Speresweeps can be lofts. Blob-sweeps are isosurfaces, marching thingies.

So it boils down to two well implemented algorithms to cover all shapes in mesh
form.

thanks for the links, I'll have a look,

ingo

Post a reply to this message

regarding Voronoi:

Voronoi cells are connected.

This means one gets manifolds and the half edge mesh system chokes on that.

Voro++ uses the bag of cells approach. But there is no further relation between
the cells. That's a pity. While constructing the voronoi pattern we gather data
about neigbours. These can be put in a record/struct together with the vertex
and face data of the cell. This makes it possible to traverse through the voroni
cells. The halfe edge datastructure can still be used for the single cell mesh.
Simplified:

VornoiCell = object
  geometry: ConvexPolyhedron  // halfedgemesh or just array of vertices & faces
  seedPoint: Vec3
  neighbors: seq[CellID]     // adjacent cells
  sharedFaces: Table[CellID, FaceID]  // which face is shared with which
neighbour

VoronoiBag = objec
  cells: Table[CellID, VoronoiCell] // if cellId is ordered, seq[VoroinoCell]


Then I thought, what if we transpose the (half) edge to a higher dimension.
That/what would be a half face/facet mesh datastructure. Very implified:

type
  HalfFace = object
    face: Face                   // geometric face (vertices, normal, etc.)
    adjacentCell: CellID         // which cell this half-face belongs to
    twinHalfFace: HalfFaceID     // opposite half-face in neighboring cell
    nextAroundCell: HalfFaceID   // next face around this cell

  VoronoiMesh = object
    halfFaces: List<HalfFace>
    cells: List<Cell>            // each cell references its half-faces


pattern :
1D: vertices bind line segments
2D: edges bind faces
3D: faces bind volumes/cells
4D: volumes would bind 4D regions

Half-edge works for 2D as edges are the boundaries between faces
Half-face makes sense for 3D as faces are the boundaries between cells
Half-volume would work for 4D as volumes are the boundaries between 4D cells?

for n-dimensional mesh elements (n-1)-faces separate n-dimensional regions?


After some searching it is actually something that exists to create 3d connected
mesh' : OpenVolumeMesh
https://www.graphics.rwth-aachen.de/software/openvolumemesh/

The choice depends on the goal,

ingo

Post a reply to this message

"ingo" <nomail@nomail> wrote:

> Speresweeps can be lofts. Blob-sweeps are isosurfaces, marching thingies.

37 page paper to ... concatenate spheres and cylinders/cones.
Just like I've (re)written hundreds of times every time I want to graph
something.

But - what's that? They calculate the tangents between the spheres to smoothly
connect them?

And the manuscript was written in ... 2019?

https://news.povray.org/povray.binaries.images/thread/%3Cweb.5da27a2a65c96eb4eec112d0%40news.povray.org%3E/?ttop=445868
&toff=650&mtop=428668

https://news.povray.org/povray.text.scene-files/thread/%3Cweb.5dd1666f8983c4eb4eec112d0%40news.povray.org%3E/?ttop=4458
70&toff=50&mtop=429362

Must just be wild coincidence.
Just like that curvature of splines YT video.

But I do think that we can rewrite the spheresweep with some better code - both
analytically as well as tesselation.

- BW

Post a reply to this message

On 9/3/25 07:10, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
>> Why 'solid'?
> 
> Because that's the default case....> It also doesn't change the acronym sor {}.
> 
> I haven't rigorously experimented with the lathe object yet, but I've rendered a
> non-closed curve, and it was solid / automatically closed.

I'm not opposed to better descriptions or feature names. That said, I 
don't see "solid of revolution" as better terminology. It might be just 
me though :-).

Many shapes have caps, or not, while still having defined inside(0) 
regions. The cone, cylinder, prism, etc, have caps or not.

The lathe does not include caps - and doesn't automatically close loops. 
Perhaps you are remembering prism{}s / polygon{}s which have code to 
close spline loops (linear_spline only?).

(0) - Less caps, these shapes are all 'tricky' to use with features 
where clean ray->surface pairs / ray-intervals are expected - CSG included.

> 
>> 2) The polynomial order the solvers see with the lathe depends on the
>> type of spline used.
> 
> Well, yes. ("obviously") But the issue that I was trying to clarify was why the
> lathe always has to solve a polynomial that is twice the _degree_ of the spline
> segment being handled. (whereas the sor is happy to stick with the actual degree
> of the spline)

I believe it relates to the sor not allowing folds in y. The defining 
points for the sor must be ever increasing or decreasing in y. Beyond 
that (which you probably knew), you've done far more work than I have in 
trying to 'really' understand the particulars of the sor & lathe 
polynomial set up code / method(s).

> 
>>
>> 3) For the attached image the sor is on the left and the lathe on the
>> right. I'm using yuqk, so the solvers are changed from POV-Ray proper.
>>
>>       5
>>       <+1.5,-0.1>
>>       <+0.4,0.0>
>>       <+0.3,0.5>
>>       <+0.4,0.9>
>>       <+1.5,1.1>
> 
> Please do not mislead - you're clearly using a non-specified type of spline, and
> the open keyword.

With 2,3 and the sturm 'aside', I was - poorly - trying to point out the 
broad, sweeping statements about sor vs lathe performance, sturm vs not 
accuracy and performance mentioned in our documentation - and often in 
our forums - are iffy at best and sometimes outright wrong(a).

I included the sor vs lathe image to show I was using 'open' with the 
sor. The lathe doesn't do caps - and the performance numbers would be 
'unfair' to the sor otherwise. I noted too the lathe in the performance 
comparison was using cubic_spline (order 6).

(a) - In yuqk, where many solver issues are fixed / refined and 'sturm' 
more reliably invokes the sturmian solver, or not, there is seldom any 
difference in accuracy between the dedicated <=4 order solvers and the 
sturmian solver. While 'sturm' is usually slower, it's often by not that 
much. Its also true for lower (<=4) order equations 'sturm' is, 
occasionally, faster than the fixed solvers! It depends on stuff.

>> In any case we should
>> look again at what was done for this feature in hgpovray38.
> 
> Yes, always an excellent idea.  I can only unravel one code base at a time
> (usually :D)

Indeed, multiple code bases are hard to keep straight. :-(

I get tangled up all the time trying to remember differences - v3.7, 
v3.8 (at where yuqk forked), v3.8 as backed up to something different 
for our two beta releases - and the great many yuqk fork specific 
changes / fixes relative to all the official, v3.7 / v3/8, POV-Ray code 
releases.

Bill P.

Post a reply to this message

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


> >> In any case we should
> >> look again at what was done for this feature in hgpovray38.
> >
> > Yes, always an excellent idea.  I can only unravel one code base at a time
> > (usually :D)


I tried to reach to LeFogeron, but failed. If anyone could... please attract his
attention to this discussion, trying to get him involved, so that more of the
povers who are really advanced in this area can actually also shed their light
on this topic!

Post a reply to this message

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

> I'm not opposed to better descriptions or feature names. That said, I
> don't see "solid of revolution" as better terminology. It might be just
> me though :-).

Because it looks and acts solid without any special treatment.
Regardless of caps or inside regions, if I can't see through the inside, and I
can use it in CSG, then it's solid.

If I apply the open keyword, then I can (depending on the specific location of
control points) see through it, not properly use it in CSG, and it's an
infinitely thin shell.

This is fun.  You play clipka, and I'll play Warp.  ;D

> Many shapes have caps, or not, while still having defined inside(0)
> regions. The cone, cylinder, prism, etc, have caps or not.
>
> The lathe does not include caps - and doesn't automatically close loops.
> Perhaps you are remembering prism{}s / polygon{}s which have code to
> close spline loops (linear_spline only?).

While I was very briefly making a lathe shape to contrast it with sor, I made a
square U shape, where I only supplied 8 points, not repeating the starting
point.   I didn't use an interior_texture, so I'll to try that when I get the
chance.


> I believe it relates to the sor not allowing folds in y. The defining
> points for the sor must be ever increasing or decreasing in y.

However, the documentation points out that you can use ANY point for the
"oof-spline" control points to set the tangent directions.  Haven't tried it
yet.

> With 2,3 and the sturm 'aside', I was - poorly - trying to point out the
> broad, sweeping statements about sor vs lathe performance, sturm vs not
> accuracy and performance mentioned in our documentation - and often in
> our forums - are iffy at best and sometimes outright wrong(a).

I'd probably have to try that with a much longer spline to really see.

> (a) - In yuqk, where many solver issues are fixed / refined and 'sturm'
> more reliably invokes the sturmian solver, or not, there is seldom any
> difference in accuracy between the dedicated <=4 order solvers and the
> sturmian solver. While 'sturm' is usually slower, it's often by not that
> much. Its also true for lower (<=4) order equations 'sturm' is,
> occasionally, faster than the fixed solvers! It depends on stuff.

Yes, it can get complicated, and I find myself looking into all of this solver
stuff myself, and reading about how others handle some of the quartic and higher
equations.  So far I've only written my own simple Newton-Raphson solver, and
copy-pasted the matrix multiplicative inverse method from source into SDL
(because why rewrite it...)


Thanks for chiming in - there's always more to be learned.
I wish I hadn't been so busy with graduate school in "the golden days" of
POV-Ray.  I also wish I had kept up with my programming skills.  I always feel
like I'm so very late in the game to be trying to make meaningful contributions.

- BW

Post a reply to this message