Some notes:

The MakeCharacter () macro uses the following variables:

Coordinate [] is an array containing <x, y> spline coordinates plus a diameter
multiplier. The actual format is <x, y, multiplier>.

NPoints indicates the number of spline points in the Coordinate [] array.

HeightFactor adjusts the scale of the character without changing the diameter.

BaseRadius is the default sphere_sweep diameter.

UseLastMinsAndMaxs is useful for making multiple parts of a character to be
unioned together.

It's fairly easy but a little tedious to make characters with this macro. What
worked for me was to make a bitmap image of the characters with a paint program
then mark locations along a path following the center of the character strokes.
The <x, y> coordinates of the marks can then be typed into Coordinate [] array
entries and if necessary the diameter multipliers can be adjusted. With a little
practice one can achieve acceptable results. Don't forget that the first and
last locations aren't actually plotted since the macro uses the b_spline
sphere_sweep method.

Happy raytracing!

Kind regards,
Dave Blandston

Post a reply to this message

Attachments:
Download '3dtext.pov.txt' (11 KB)

hi,

"Dave Blandston" <IsN### [at] protonmailch> wrote:
> Some notes:
> ...
> It's fairly easy but a little tedious to make characters with this macro. What
> worked for me was to make a bitmap image of the characters with a paint program
> then mark locations along a path following the center of the character strokes.

thinking that some code to "scan" a black+white/any high contrast image, as
image_map texture on a box or a plane, would automate that step (leaving only
the "tedium" of providing the char/word bitmaps :-))

> The <x, y> coordinates of the marks can then be typed into Coordinate [] array
> entries and if necessary the diameter multipliers can be adjusted. With a little
> practice one can achieve acceptable results. Don't forget that the first and
> last locations aren't actually plotted since the macro uses the b_spline
> sphere_sweep method.

am still quite amazed at how few points are needed.


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "Dave Blandston" <IsN### [at] protonmailch> wrote:
> > Some notes:
> > ...
> > It's fairly easy but a little tedious to make characters with this macro. What
> > worked for me was to make a bitmap image of the characters with a paint program
> > then mark locations along a path following the center of the character strokes.
>
> thinking that some code to "scan" a black+white/any high contrast image, as
> image_map texture on a box or a plane, would automate that step (leaving only
> the "tedium" of providing the char/word bitmaps :-))

I would say that since most TTF fonts are rendered using Bezier splines, it
would be most efficient to find a way to load in the control points from the
font file itself.

> > The <x, y> coordinates of the marks can then be typed into Coordinate [] array
> > entries and if necessary the diameter multipliers can be adjusted. With a little
> > practice one can achieve acceptable results. Don't forget that the first and
> > last locations aren't actually plotted since the macro uses the b_spline
> > sphere_sweep method.
>
> am still quite amazed at how few points are needed.

Well, that IS the idea behind using splines to render fonts.

Perhaps one way to transform the outline of the fonts, which is used to render
them as a prism {}, into a "centerline font" would be to employ the
inside/outside crossing number testing used for prisms, and calculate the
gradient and therefore the normal of the outline.  Then find the midpoint of
that vector to get a centerline control point for the sphere sweep.

Might be a little challenging with "forked" glyphs like E, F, K, etc....

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > thinking that some code to "scan" ...
>
> I would say that since most TTF fonts are rendered using Bezier splines, it
> would be most efficient to find a way to load in the control points from the
> font file itself.

if you have access to the font file.  iiuc, DB's use of a(n intermediate) bitmap
has the advantage that any text (and not only text shapes) can be used.  _and_
you'd need an external utility to get the ttf data (sacrilege.. :-)).


> Perhaps one way to transform the outline of the fonts, which is used to render
> them as a prism {}, into a "centerline font" would be to employ the
> inside/outside crossing number testing used for prisms, and calculate the
> gradient and therefore the normal of the outline.  Then find the midpoint of
> that vector to get a centerline control point for the sphere sweep.

prism/"extruded" is interesting, could get sharp-edged shapes with complex
layouts of each "stroke".

> Might be a little challenging with "forked" glyphs like E, F, K, etc....

could not the same (sphere_sweep) data be used to position/help shape the
prism(s)?


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:

> if you have access to the font file.  iiuc, DB's use of a(n intermediate) bitmap
> has the advantage that any text (and not only text shapes) can be used.

Indeed.  But I think it would be possible to implement both, as one is sort of a
subset of the other.

  _and_
> you'd need an external utility to get the ttf data (sacrilege.. :-)).

Sacrilege indeed.   That's why we'd want to do something like convert the
javascript that already does this to SDL.

http://stevehanov.ca/blog/?id=143



> > Might be a little challenging with "forked" glyphs like E, F, K, etc....
>
> could not the same (sphere_sweep) data be used to position/help shape the
> prism(s)?

I was thinking that something like an E would be more than 1 sphere sweep, so
there would have to be some mechanism for determining where the joints/bends
are.
The prisms aren't the problem - that's just a continuous outline, which is easy.
 It's defining the centerline font where it's gets tricky

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> That's why we'd want to do something like convert the
> javascript that already does this to SDL.
>
> http://stevehanov.ca/blog/?id=143


That looks like a promising method. That was what I wanted to do from the
beginning but I don't have the programming skill. Completely automating the
process would be difficult for the reasons you guys have already mentioned but
being able to extract the spline points from a .ttf file would be extremely
useful. POV-Ray can already read the data so I wonder if it would be possible to
export it easily.

I also considered using Jr's idea of using an image_map and that would allow
easier fine-tuning.

It would be great if software existed that allowed one to draw curves over a
background picture and export the data. This is close
https://forums.getpaint.net/topic/27512-trs-splinemaster-v143-a-line-maker-july-1-2019/
but it appears to use a different type of curve. It would still be helpful if it
could export the control points to a .txt file to save having to type them.

Kind regards,
Dave Blandston

Post a reply to this message

Here's a question for Bald Eagle - would your SmoothMinFunction code work on
this object? I added a picture to the povray.binaries.images thread highlighting
some of the areas where sphere_sweeps are unioned together where your
SmoothMinFunction would dramatically improve the appearance if it could be
applied. I looked at the SmoothMinFunction code and I must admit, the math is
way beyond my abilities.

Post a reply to this message

"Dave Blandston" <IsN### [at] protonmailch> wrote:
> "
> It would be great if software existed that allowed one to draw curves over a
> background picture and export the data.

Why not just do what I did with the gear tooth counting project and turn the
image map into a heightfield.  Then you can scan around it with trace () and
compile a list of points.

Obviously this would only scan the exterior envelope, and so a method to get the
holes in letters like B, D, O, P, Q, and R would be required.  Maybe a stepwise
trace () across a vector accumulating a crossing number could be used to find
holes and start a sub-scan in the second "outside" region.

Post a reply to this message

"Dave Blandston" <IsN### [at] protonmailch> wrote:
> Here's a question for Bald Eagle - would your SmoothMinFunction code work on
> this object? I added a picture to the povray.binaries.images thread highlighting
> some of the areas where sphere_sweeps are unioned together where your
> SmoothMinFunction would dramatically improve the appearance if it could be
> applied. I looked at the SmoothMinFunction code and I must admit, the math is
> way beyond my abilities.

It should work just fine so long as the pieces that you want to smooth between
are separate parts.

You really don't need to understand any of the math - you just plug in the
objects to the function - just like macro arguments.

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Dave Blandston" <IsN### [at] protonmailch> wrote:
> > Here's a question for Bald Eagle - would your SmoothMinFunction code work on
> > this object? I added a picture to the povray.binaries.images thread highlighting
> > some of the areas where sphere_sweeps are unioned together where your
> > SmoothMinFunction would dramatically improve the appearance if it could be
> > applied. I looked at the SmoothMinFunction code and I must admit, the math is
> > way beyond my abilities.
>
> It should work just fine so long as the pieces that you want to smooth between
> are separate parts.
>
> You really don't need to understand any of the math - you just plug in the
> objects to the function - just like macro arguments.

isosurface {
    function {SmoothMin_Poly2 (_Box
(x*cos(Angle)-sin(Angle),y,z*sin(Angle)+cos(Angle)), _Sphere (x-3.5,y,z),
Strength)}
....
}

Now the thing is, the objects have to be converted into isosurfaces for all of
this to work:

#declare _Box = function (X, Y, Z) { max((X*X-1),(Y*Y-1),(Z*Z-1)) }
#declare _Sphere = function { x*x + y*y + z*z - 1 }

And so you'd need to do a Bill P ObjectAsIso type conversion.  Because you can't
have the infinite gradient between object and no-object.

So it would work, but it might be rather slow...

Post a reply to this message