"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

"Bald Eagle" <cre### [at] netscapenet> wrote:
> 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...


Ah-ha! Thanks for the follow-up! I've been trying to figure out how to make it
work since your last post - and not getting anywhere.

Post a reply to this message

"Dave Blandston" <IsN### [at] protonmailch> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > 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...
>
>
> Ah-ha! Thanks for the follow-up! I've been trying to figure out how to make it
> work since your last post - and not getting anywhere.

Now, IIRC, Mike Williams has done an impressive amount of work on tubes and
splines and using them in isosurfaces to mimic sphere sweeps.   So If you wanted
to implement the smoothing, then maybe the way to go would be to convert the
code so that you were using proper isosurfaces right out of the gate, rather
than a slow and inefficient conversion from a primitive.

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> ...
> Sacrilege indeed.   That's why we'd want to do something like convert the
> javascript that already does this to SDL.

that's an interesting page, some of the other posts I scanned cursorily looked
worth returning to.  thanks.

(sticking my neck out) I think we'd need WFP to become interested, make 'povr'
export/make visible the TTF data it (as pointed out) already has, in the parser;
pass in a text{} and get back metrics, that sort of thing.


regards, jr.

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Now, IIRC, Mike Williams has done an impressive amount of work on tubes and
> splines and using them in isosurfaces to mimic sphere sweeps.   So If you wanted
> to implement the smoothing, then maybe the way to go would be to convert the
> code so that you were using proper isosurfaces right out of the gate, rather
> than a slow and inefficient conversion from a primitive.


OK that's interesting. The conversion did not look like it was going to work out
for this particular use because the documentation said that sharp edges would
produce jagged results. Most of the edges of the letters are rounded since
that's the whole point of the project, but the top of the "u" and bottom of the
"n" do have sharp edges. I'll see if Mike Williams' work can be used. Thank you
sir!

Post a reply to this message