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

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