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