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?


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

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.

> 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:


> 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.

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