Hi folks,

the `prism` primitive currently supports, among others, cubic Bezier 
spline outlines.

For certain technical reasons, I may need to add support for _quadratic_ 
Bezier splines at the render engine level as well, but it would be a 
waste to not expose them to the scene description language (and, while 
I'm at it, possibly also extend `lathe` accordingly).

An open question is, what keyword should be used for this type of spline?


For the records:

- Quadratic Bezier splines are a flavor of quadratic splines, aka 2nd 
order polynomial splines.

- Quadratic splines are also occasionally referred to as "conic splines" 
or "conic arcs", for reasons I'm not entirely sure of.

- `bezier_spline` is the current moniker for cubic Bezier splines.

- `quadratic_spline` is already in use for some quirky flavor of 
quadratic spline that, in my mind, doesn't even deserve to live, but has 
a long-standing tradition of existing under this moniker and therefore 
isn't going anywhere in POV-Ray v3.x.


Here are some ideas:

- `quadratic_bezier_spline`, being the most accurate term.

- `conic_bezier_spline`, being a bit shorter.

- `conic_spline`, being yet shorter.

- `bezier2_spline`, the "2" referring to the polynomial order.


Personally, I'm somewhat unhappy with the very first for being rather 
verbose, and the third for being prone to confusion with both 
`cubic_spline` and `conic_sweep`, the latter being also used in `prism`. 
I'm also not quite happy with the second one, because it's still 
somewhat lengthy, and I think it isn't the most accurate of terms.


Thoughts, anyone?

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Hi folks,
>
> the `prism` primitive currently supports, among others, cubic Bezier
> spline outlines.
>
> For certain technical reasons, I may need to add support for _quadratic_
> Bezier splines at the render engine level as well, but it would be a
> waste to not expose them to the scene description language (and, while
> I'm at it, possibly also extend `lathe` accordingly).
>
> An open question is, what keyword should be used for this type of spline?
>
>
> For the records:
>
> - Quadratic Bezier splines are a flavor of quadratic splines, aka 2nd
> order polynomial splines.
>
> - Quadratic splines are also occasionally referred to as "conic splines"
> or "conic arcs", for reasons I'm not entirely sure of.
>
> - `bezier_spline` is the current moniker for cubic Bezier splines.
>
> - `quadratic_spline` is already in use for some quirky flavor of
> quadratic spline that, in my mind, doesn't even deserve to live, but has
> a long-standing tradition of existing under this moniker and therefore
> isn't going anywhere in POV-Ray v3.x.
>
>
> Here are some ideas:
>
> - `quadratic_bezier_spline`, being the most accurate term.
>
> - `conic_bezier_spline`, being a bit shorter.
>
> - `conic_spline`, being yet shorter.
>
> - `bezier2_spline`, the "2" referring to the polynomial order.
>
>
> Personally, I'm somewhat unhappy with the very first for being rather
> verbose, and the third for being prone to confusion with both
> `cubic_spline` and `conic_sweep`, the latter being also used in `prism`.
> I'm also not quite happy with the second one, because it's still
> somewhat lengthy, and I think it isn't the most accurate of terms.
>
>

 I like the last one 'bezier2_spline'
To tell the truth I had to look up the quadratic bezier spline, to see how it
worked. I have looked at pov sorce code to help my prism/polygon program match
pov prisms better.
 After reading about the quadratic bezier spline I was wondering why it wasn't
already a part of prisms. It seems a logic step up from the other splines
leading to the qubic bezier spline. But having said that, Now it seems a step
back. I rarely use any thing but the cubic to make prisms.

Have Fun!

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Hi folks,
>
> the `prism` primitive currently supports, among others, cubic Bezier
> spline outlines.
>
> For certain technical reasons, I may need to add support for _quadratic_
> Bezier splines at the render engine level as well, but it would be a
> waste to not expose them to the scene description language (and, while
> I'm at it, possibly also extend `lathe` accordingly).

> <snip>

> - `bezier2_spline`, the "2" referring to the polynomial order.

> Thoughts, anyone?

After doing the 25-page monograph on Bézier splines and surfaces, here are my
thoughts:

Quadratic Bézier Splines (QBS) would be very nice to have, since they are often
used in fonts/typfaces and svg representations of glyphs.  Cousin Ricky was nice
enough to provide me with an early release of his sphere sweep macro that allows
QBS.

Bézier splines of one degree can be represented by a Bézier spline of a higher
degree.

So, you may not have to code a whole separate section for QBS - just write an
algorithm to degree-elevate a QBS to a cubic.  I have my SDL version that you
can have to adapt into suitable c++ source code.

IIRC degree reduction was a bit trickier, and I hadn't implemented that.
Jim T seems to be a bit of a Bézier wizard (coding up a triangular patch), so
maybe he already has something to do that side of the degree manipulation.

What would be very nice would be a generic "bezier" keyword followed by the
desired degree, or perhaps, by the degree of the supplied control points
followed by the desired degree after elevation / reduction.

But that is JUST something to think about, before anything becomes "concrete".


Does that help?  :D

Post a reply to this message

I just wanted to point out that there seems to be something wrong with 
the web interface.
I just posted this, and when I went to read it, it was corrupted.   But 
the strange thing is, the post looks FINE when I open it in Thunderbird.
So it's getting written properly, but read/displayed improperly.

Here's what it looks like in the web interface, for anyone reading with 
Thunderbird:


------------------------------------------------------------------------

thoughts:


used in fonts/typfaces and svg representations of glyphs.  Cousin Ricky 
was nice
enough to provide me with an early release of his sphere sweep macro 
that allows
QBS.


degree.

So, you may not have to code a whole separate section for QBS - just 
write an
algorithm to degree-elevate a QBS to a cubic.  I have my SDL version 
that you
can have to adapt into suitable c++ source code.

IIRC degree reduction was a bit trickier, and I hadn't implemented that.

maybe he already has something to do that side of the degree manipulation.

What would be very nice would be a generic "bezier" keyword followed by the
desired degree, or perhaps, by the degree of the supplied control points
followed by the desired degree after elevation / reduction.

But that is JUST something to think about, before anything becomes 
"concrete".


Does that help?  :D

------------------------------------------------------------------------

Post a reply to this message

Am 07.06.2021 um 01:16 schrieb Bald Eagle:
> I just wanted to point out that there seems to be something wrong with 
> the web interface.
> I just posted this, and when I went to read it, it was corrupted.   But 
> the strange thing is, the post looks FINE when I open it in Thunderbird.
> So it's getting written properly, but read/displayed improperly.

Yes, it looks like the web interface mangles anything with non-ASCII 
characters. Such as in Mr. Bezier's properly-spelled name.

Post a reply to this message

Am 07.06.2021 um 00:40 schrieb Bald Eagle:

> Quadratic Bézier Splines (QBS) would be very nice to have, since they are often
> used in fonts/typfaces and svg representations of glyphs.  Cousin Ricky was nice
> enough to provide me with an early release of his sphere sweep macro that allows
> QBS.
> 
> Bézier splines of one degree can be represented by a Bézier spline of a higher
> degree.
> 
> So, you may not have to code a whole separate section for QBS - just write an
> algorithm to degree-elevate a QBS to a cubic.  I have my SDL version that you
> can have to adapt into suitable c++ source code.

As a matter of fact, fonts is exactly the topic I'm implementing this 
for in the first place, because I'm working on throwing out our 
dedicated `text` shape rendering code and replacing it with `prism` 
under the hood.

And yes, so far I have been using degree-elevation to map conic outlines 
to cubic ones as already supported by `prism`.

But this turns out to come at the cost of slower render times, and I 
have a hunch that's because TrueType fonts exclusively use conic (or 
linear) outline segments, so by adding native support for conic bezier 
outlines I hope to regain some of the lost performance.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

> As a matter of fact, fonts is exactly the topic I'm implementing this
> for in the first place, because I'm working on throwing out our
> dedicated `text` shape rendering code and replacing it with `prism`
> under the hood.

Very nice.  I recall that was one of the things on your list.  Maybe the visual
quality of the fonts will improve with the new implementation.

> And yes, so far I have been using degree-elevation to map conic outlines
> to cubic ones as already supported by `prism`.

Of course you have.  :D
Your toolbox of coding stuff must be astonishing to behold.

> But this turns out to come at the cost of slower render times, and I
> have a hunch that's because TrueType fonts exclusively use conic (or
> linear) outline segments, so by adding native support for conic bezier
> outlines I hope to regain some of the lost performance.

So, it hit me - while trying to get to sleep, of course - that something useful
would be to have an outline-only version of the text object - that traces out
the ttf outlines without filling them in like a prism would do.  I know a lot of
people have played with various font projects, and this would save a lot of work
in achieving the end-results.
keyword could be outline_text or text2 or something.

I don't know if daisy-chaining the spline with a sphere sweep would be the way
to go, or maybe if there's some way to take the font segment data and make it
visible to the SDL in the form of an array or something.  I've seen some very
nice technical drawings when I was researching working with the splines and font
data, and I think that such a an additional low-level tool would be attractive
to folks who work with typefaces and might want to make technical drawings,
presentations explaining how fonts are drawn, etc.
http://www.mathisintheair.org/wp/wp-content/uploads/2015/03/G-45-90_5373.gif

It would also be a very nice way to have the font data at one's fingertips in
case a user wanted to make small edits to the coordinates, or anything else
requiring the actual font data.


I'm not sure how much of your work would cross over into making SVG a useable
format, but maybe that's something to keep in mind and at least plop a juicy
comment into the source code.  ;)

Post a reply to this message

Am 07.06.2021 um 03:59 schrieb Bald Eagle:
>> But this turns out to come at the cost of slower render times, and I
>> have a hunch that's because TrueType fonts exclusively use conic (or
>> linear) outline segments, so by adding native support for conic bezier
>> outlines I hope to regain some of the lost performance.

Well, that didn't go as planned...

As it turns out, converting conic-outline fonts straight to 2nd order 
Bezier `prism`s (amended to provide direct support) is actually slower. 
My hunch is that it results in poorer bounding, because elevating the 
order also "tightens" the control points, and I suspect the `prism` 
bounding computations just plain braindeadly bound to the convex hull of 
the control points.
So there might still be potential there, but not the low-hanging fruit I 
was hopong for.

Also, turns out that the loss of performance was just empty prisms I 
created for whitespace characters. Which is of course dumb. Now that 
I've fixed that, rendering of text actually seems to be faster than ever 
before.

> So, it hit me - while trying to get to sleep, of course - that something useful
> would be to have an outline-only version of the text object - that traces out
> the ttf outlines without filling them in like a prism would do.  I know a lot of
> people have played with various font projects, and this would save a lot of work
> in achieving the end-results.
> keyword could be outline_text or text2 or something.

Oh, there's plenty of potential there for such things indeed.

One day, one fine morning, all the spline-related features will be 
combined into one glorious unified system, and text will just be another 
source of splines.

Post a reply to this message

in news:60bd43a2$1@news.povray.org clipka wrote:

> Thoughts, anyone?
> 

as it is clear that it is a spline, or curve, bezier2, bezier3


A few minutes ago in http://news.povray.org/povray.binaries.scene-
files/message/%3CXnsAD427355E3A62seed7%40news.povray.org%3E/#%
3CXnsAD427355E3A62seed7%40news.povray.org%3E I posted a new version of a 
curvers / splines include file. I think the concept would make a nice 
addition to POV-Ray if implemented in C++ (that I sadly don't speak) as a 
substitute/addition to the current splines.

-- 
https://ingoogni.nl

Post a reply to this message

On 2021-06-06 5:52 PM (-4), clipka wrote:
> 
> For certain technical reasons, I may need to add support for _quadratic_
> Bezier splines at the render engine level as well, but it would be a
> waste to not expose them to the scene description language (and, while
> I'm at it, possibly also extend `lathe` accordingly).
> 
> An open question is, what keyword should be used for this type of spline?
> 
> ...
> 
> - `quadratic_spline` is already in use for some quirky flavor of
> quadratic spline that, in my mind, doesn't even deserve to live, [snip]

I'm inclined to agree with you there.  And I will speculate that Bald
Eagle also agrees.

> Here are some ideas:
> 
> - `quadratic_bezier_spline`, being the most accurate term.
> 
> - `conic_bezier_spline`, being a bit shorter.
> 
> - `conic_spline`, being yet shorter.
> 
> - `bezier2_spline`, the "2" referring to the polynomial order.

For what it's worth, when I implemented the quadratic Bezier sphere
sweep in the Object Collection, I used the name SSWP_BEZIER2_SPLINE to
select that spline type.  So of course I'm biased in favor of the last
option.

Post a reply to this message

in news:XnsAD42761851048seed7@news.povray.org ingo wrote:

> as it is clear that it is a spline, or curve, bezier2, bezier3

actually, it is a curve, not a spline ;)


-- 
https://ingoogni.nl

Post a reply to this message

On 6/6/2021 5:52 PM, clipka wrote:
> - Quadratic splines are also occasionally referred to as "conic splines" 
> or "conic arcs", for reasons I'm not entirely sure of.


IIRC, quadratic splines are parabolic segments or arcs, which are also 
conic sections.


Mike

Post a reply to this message

Am 07.06.2021 um 16:54 schrieb ingo:
> in news:XnsAD42761851048seed7@news.povray.org ingo wrote:
> 
>> as it is clear that it is a spline, or curve, bezier2, bezier3
> 
> actually, it is a curve, not a spline ;)

That very much depends on the context you're using the word in. It has 
different definitions in computer graphics, mathematics and traditional 
shipbuilding.

The mathematical definition is certainly the one with can lay the least 
claim to the term. Because what they call splines actually started out 
as nothing more than a mathematical framework invented to _describe_ 
_proper_ splines. The "function of a variable" is something the 
mathematicians bolted on to a pre-existing concept.

In all other fields that don't define "spline" as a physical tool, a 
"spline" _is_ the very thing that a mathematician might call a "spline 
curve". Or whatever they tend to call it.

Post a reply to this message

Am 07.06.2021 um 16:54 schrieb Mike Horvath:
> On 6/6/2021 5:52 PM, clipka wrote:
>> - Quadratic splines are also occasionally referred to as "conic 
>> splines" or "conic arcs", for reasons I'm not entirely sure of.
> 
> 
> IIRC, quadratic splines are parabolic segments or arcs, which are also 
> conic sections.

I'm aware of this connection in general, but I'm not really sure whether 
the spline curve segments are necessarily parabolic, or whether that 
only applies to the individual components in a value/result plot; and 
what's more, there's the snag that they can't represent any other conic 
sections. They can't even represent sections of ellipses.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Hi folks,
>
> the `prism` primitive currently supports, among others, cubic Bezier
> spline outlines.
>
> For certain technical reasons, I may need to add support for _quadratic_
> Bezier splines at the render engine level as well, but it would be a
> waste to not expose them to the scene description language (and, while
> I'm at it, possibly also extend `lathe` accordingly).
>
> An open question is, what keyword should be used for this type of spline?
>
>
> For the records:
>
> - Quadratic Bezier splines are a flavor of quadratic splines, aka 2nd
> order polynomial splines.
>
> - Quadratic splines are also occasionally referred to as "conic splines"
> or "conic arcs", for reasons I'm not entirely sure of.
>
> - `bezier_spline` is the current moniker for cubic Bezier splines.
>
> - `quadratic_spline` is already in use for some quirky flavor of
> quadratic spline that, in my mind, doesn't even deserve to live, but has
> a long-standing tradition of existing under this moniker and therefore
> isn't going anywhere in POV-Ray v3.x.
>
>
> Here are some ideas:
>
> - `quadratic_bezier_spline`, being the most accurate term.
>
> - `conic_bezier_spline`, being a bit shorter.
>
> - `conic_spline`, being yet shorter.
>
> - `bezier2_spline`, the "2" referring to the polynomial order.
>
>
> Personally, I'm somewhat unhappy with the very first for being rather
> verbose, and the third for being prone to confusion with both
> `cubic_spline` and `conic_sweep`, the latter being also used in `prism`.
> I'm also not quite happy with the second one, because it's still
> somewhat lengthy, and I think it isn't the most accurate of terms.
>
>
> Thoughts, anyone?


Well, Probably the least technical thought ever, but I find names like
something2  something3 rather drafty looking. Even mesh2 doesn't look like the
"goto" syntax it should be; it just makes it look secondary to me. Also because
without any space or underscore makes it look like a backend programer's stuff
not eyepleasing user API level... In many software the  word b_spline
("B-Spline") seems quite conventional to talk about bezier spline if less
verbosity is needed, maybe that could provide inspiration for more options?
Also, sorry if below point even increases the challenge, but to be future proof,
couldn't this be planned with respect to the eventuality of NURBS getting into
POV master one day, avoiding collisions, but also solving the confusion existing
in most other software between these (different? hierarchized?) kinds of
geometry?

Post a reply to this message

in news:web.60bf2d2584e2d21b16086ed03f378f2@news.povray.org Mr wrote:

> In many software the  word b_spline
> ("B-Spline") seems quite conventional to talk about bezier spline if
> less verbosity is needed,

there are b-splines, the quadratic b-spline, the cubic b-spline and the 
cubic b-spline with tension and bias. The latter is mostly called beta-
spline. b-spline for a bezier curve would be realy confusing,

ingo

-- 
https://ingoogni.nl

Post a reply to this message

On 2021-06-08 4:41 AM (-4), Mr wrote:
> clipka <ano### [at] anonymousorg> wrote:
>>
>> For certain technical reasons, I may need to add support for _quadratic_
>> Bezier splines at the render engine level as well, but it would be a
>> waste to not expose them to the scene description language (and, while
>> I'm at it, possibly also extend `lathe` accordingly).
>>
>> An open question is, what keyword should be used for this type of spline?
>>
>> [...]
>>
>> Here are some ideas:
>>
>> - `quadratic_bezier_spline`, being the most accurate term.
>>
>> - `conic_bezier_spline`, being a bit shorter.
>>
>> - `conic_spline`, being yet shorter.
>>
>> - `bezier2_spline`, the "2" referring to the polynomial order.
> 
> Well, Probably the least technical thought ever, but I find names like
> something2  something3 rather drafty looking. Even mesh2 doesn't look like the
> "goto" syntax it should be; it just makes it look secondary to me. Also because
> without any space or underscore makes it look like a backend programer's stuff
> not eyepleasing user API level... In many software the  word b_spline
> ("B-Spline") seems quite conventional to talk about bezier spline if less
> verbosity is needed, maybe that could provide inspiration for more options?

B-splines, though mathematically related to Bezier splines, are a
completely different animal, and the b_spline keyword is already used
elsewhere in POV-Ray for... B-splines.  To repurpose it for quadratic
Bezier prisms would be confusing on more than one level.

Maybe the keyword "mesh2" is hackish, but for a 2nd degree polynomial,
appending a "2" to "bezier" would be totally appropriate.

Post a reply to this message

Cousin Ricky <ric### [at] yahoocom> wrote:

> B-splines, though mathematically related to Bezier splines, are a
> completely different animal, and the b_spline keyword is already used
> elsewhere in POV-Ray for... B-splines.  To repurpose it for quadratic
> Bezier prisms would be confusing on more than one level.
>
> Maybe the keyword "mesh2" is hackish, but for a 2nd degree polynomial,
> appending a "2" to "bezier" would be totally appropriate.

Let's do the Google thing and "not be evil", by avoiding all confusion,
conflation, and commingling of Bezier splines, B-splines, NURBS knots, and
plagiarized Shakespearean literature.

I propose:


knot2_b_spline


.. . .



What was the question?

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Cousin Ricky <ric### [at] yahoocom> wrote:
>
> > B-splines, though mathematically related to Bezier splines, are a
> > completely different animal, and the b_spline keyword is already used
> > elsewhere in POV-Ray for... B-splines.  To repurpose it for quadratic
> > Bezier prisms would be confusing on more than one level.
> >
> > Maybe the keyword "mesh2" is hackish, but for a 2nd degree polynomial,
> > appending a "2" to "bezier" would be totally appropriate.
>
> Let's do the Google thing and "not be evil", by avoiding all confusion,
> conflation, and commingling of Bezier splines, B-splines, NURBS knots, and
> plagiarized Shakespearean literature.
>
> I propose:
>
>
> knot2_b_spline
>...

But, but, but... That confuses me.

When I see the name b-spline I always think of the type of splines used in
NURBS, never Bezier splines. And most (or all ?) splines have knots ?

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

Post a reply to this message

Am 08.06.2021 um 10:41 schrieb Mr:

> not eyepleasing user API level... In many software the  word b_spline
> ("B-Spline") seems quite conventional to talk about bezier spline if less
> verbosity is needed, maybe that could provide inspiration for more options?

B-Splines are a different beast entirely. There, the "B" stands for 
"basis", not "Bezier".

> Also, sorry if below point even increases the challenge, but to be future proof,
> couldn't this be planned with respect to the eventuality of NURBS getting into
> POV master one day, avoiding collisions, but also solving the confusion existing
> in most other software between these (different? hierarchized?) kinds of
> geometry?

I don't see a conflict between any of the proposed monikers and "NURBS". 
Oh, and those are _still_ another matter, being an extension to the 
concept of B-Splines.

Post a reply to this message

On 6/7/2021 1:23 PM, clipka wrote:
> Am 07.06.2021 um 16:54 schrieb Mike Horvath:
>> On 6/6/2021 5:52 PM, clipka wrote:
>>> - Quadratic splines are also occasionally referred to as "conic 
>>> splines" or "conic arcs", for reasons I'm not entirely sure of.
>>
>>
>> IIRC, quadratic splines are parabolic segments or arcs, which are also 
>> conic sections.
> 
> I'm aware of this connection in general, but I'm not really sure whether 
> the spline curve segments are necessarily parabolic, or whether that 
> only applies to the individual components in a value/result plot; and 
> what's more, there's the snag that they can't represent any other conic 
> sections. They can't even represent sections of ellipses.

See here:

https://www.geogebra.org/m/h779nwhd


Mike

Post a reply to this message

Am 10.06.2021 um 00:56 schrieb Mike Horvath:

>> I'm aware of this connection in general, but I'm not really sure 
>> whether the spline curve segments are necessarily parabolic, or 
>> whether that only applies to the individual components in a 
>> value/result plot; and what's more, there's the snag that they can't 
>> represent any other conic sections. They can't even represent sections 
>> of ellipses.
> 
> See here:
> 
> https://www.geogebra.org/m/h779nwhd

That's a neat demonstration.
Thanks for sharing.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 10.06.2021 um 00:56 schrieb Mike Horvath:
>
> >> I'm aware of this connection in general, but I'm not really sure
> >> whether the spline curve segments are necessarily parabolic, or
> >> whether that only applies to the individual components in a
> >> value/result plot; and what's more, there's the snag that they can't
> >> represent any other conic sections. They can't even represent sections
> >> of ellipses.
> >
> > See here:
> >
> > https://www.geogebra.org/m/h779nwhd
>
> That's a neat demonstration.
> Thanks for sharing.

Thanks, awesome visual, and sorry for increasing confusion then. I will look
better at the chosen result to try and clear my mind about this. I still hope it
won't look like "mesh2"

Post a reply to this message