Drawing smooth curved vectors - is it even possible?

[stam]

Hi all,

I'm trying to generate some curved vector graphics with a polygon (so I can manipulate its "points"), but am troubled with "jaggies" on every curved angle.
Here's an example of an arc drawn by using an oval (left) and the same arc as a polygon set to the effective points of the oval (right):

Screenshot 2024-09-22 at 13.23.15.png (7.96 KiB) Viewed 11518 times

This is pretty much true of any attempt at curvature using polygon tool and manipulating its "points".
Setting antialiased to true and setting miterlimit to various values has zero effect on this.

I presume this must be cause the inability of LC to use floats as coordinates and we're limited to integers.
I have to wonder if it's actually possible to generate smooth curves? Any workarounds that may help?

Many thanks
Stam

[richmond62]

Well, you could import an SVG image of the curve you need.

[stam]

Well, you could import an SVG image of the curve you need.

erm.. no. I need to be able to generate different shapes and once created I need to be able to change them - hence was looking at a polygon whose points I can manipulate.

But while your suggestion won't do it, it did make me think it may be possible to generate an SVG path. I'll look into that...

[dunbarx]

Stam.

Good luck.

On another note, I also do not seem to understand points. I made an oval grc and set the arcAngle to 90°. I made a polygon grc. I then tried to:

Code: Select all

set the points of grc 2 to the effective points of grc 1

And got the same jagged rendering you did. How can one set the points of a polygon to the (effective) points of a smooth arc, and get a different result? You mentioned LC being limited to integers when locating pixels on screen. What else is there?? The list of effective points of my quarter circle are just that, a list of points. How do other points live on screen?? How do they likely increase in number, and find spaces between screen pixels??

Craig!!

[richmond62]

A while back, wishing to have an oval (ellipse) I generated the thing using a merry little sine-&-cosine thing
(sorry, can't spell "algor . . ."): and spent quite some time fiddling around to get 'intervals' small enough that
doing a 'move to the points' with an image of a football, the thing did not appear jerky.

[richmond62]

How do other points live on screen?? How do they likely increase in number, and find spaces between screen pixels??

No 'other' points live on a screen; mainly because there are no 'other' points (i.e. sub-pixels) and any supposed sub-pixelation that computer developers may claim is just a lot of very clever smoke and mirrors.

At the risk of teaching my Granny to suck eggs:

A vector image is NOT defined by pixel points, while a raster image is.

"Vector graphics are a form of computer graphics in which visual images are created directly from geometric shapes defined on a Cartesian plane, such as points, lines, curves and polygons."

https://en.wikipedia.org/wiki/Vector_graphics

I assume that the curve on the left is a vector image, and the one on the right is a raster (bitmapped) images:
-

RastaPasta.png (7.96 KiB) Viewed 11405 times

-
I also assume that "the effective points" means that LiveCode does some calculations and arrives at a 'best fit' bitmap definition of a vector thing:

BUT, unfortunately, LiveCode cannot perform what we could call "the effective curve" in the opposite direction.
-

-
GIMP can work out a vector image from a bitmapped image fairly effectively (especially with 'simple' curvy pictures), and I would suppose that "someone clever" could take the tracing component from GIMP (as everything in GIMP is Open Source) and work out some sort of stack that could perform that job.

"To vectorize an image in GIMP, you can follow these steps:

1. Open your image in GIMP.
2. Select the image layer from the Layers panel.
3. Go to the "Layer" menu, then "Transparency," and select "Alpha to Selection." This will create a selection around the opaque parts of your image.
4. Next, go to the "Select" menu, then "To Path." This will convert your selection into a path.
5. With the path still selected, go to the "Path" menu and choose "Path to Selection."
6. Now, go to the "Select" menu again, but this time choose "Invert." This will invert the selection so that the transparent areas are selected instead.
6. With the inverted selection still active, go to the "Edit" menu, then "Clear" to delete the transparent areas.
7. Finally, go to the "Select" menu and choose "None" to deselect everything.
8. Now your image should be vectorized, with the opaque parts converted to a vector path in GIMP.
9. You can further edit and refine the vector path using the various tools available in GIMP's Paths panel."

https://www.quora.com/How-do-I-vectoriz ... ge-in-GIMP

Personally I always use Inkscape to do Raster-to-Vector conversions (to be honest that is the ONLY thing I have ever used Inkscape for):

https://inkscape.org/

https://inkscape-manuals.readthedocs.io ... image.html

My Devawriter Pro thing has a bespoke font that features about 5,000 glyphs in the Personal Private Use Area: there were all hand-drawn by me, scanned as raster images, and then traced with Inkscape, saved as EPS images, and then imported into the font program I use.

That felt a bit like what my late father described as his favourite hobby: banging one's head on the wall, "Because it feels great when it stops."

In theory Fontforge can trace bitmaps: but my experience with that has been fairly negative, so I prefer to do that with Inkscape, and then import the resulting vector image:

https://fontforge.org/docs/ui/menus/filemenu.html

https://fontforge.org/en-US/

[stam]

Stam.

Good luck.

On another note, I also do not seem to understand points. I made an oval grc and set the arcAngle to 90°. I made a polygon grc. I then tried to:

Code: Select all

set the points of grc 2 to the effective points of grc 1

And got the same jagged rendering you did. How can one set the points of a polygon to the (effective) points of a smooth arc, and get a different result? You mentioned LC being limited to integers when locating pixels on screen. What else is there?? The list of effective points of my quarter circle are just that, a list of points. How do other points live on screen?? How do they likely increase in number, and find spaces between screen pixels??

Craig!!

Hi Craig
When you ask “what else is there” you make the assumption that1 point = 1 physical pixel, but that’s not the case, especially given the very high resolution screens we all use now. Lots, if not all other languages offer decimal coordinates. The point being (excuse the pun) that you can increase the dot density to the point of no “jaggies” and/or that antialiasing will make them invisible.

You also make the assumption that the only way to connect dots is a straight line. But most if not all other environments allow you to connect using Bézier curves as well. Sadly not LC.

The real issue is that LC offers no way of directly drawing to a formula (ie a create a handler that draws a line then continues with a curve etc). Note that I’m not suggesting that everything should be coordinate based, but as far as I can see, that’s the only tool on offer with LC to generate vector graphics that aren’t one of the basic shapes.

The obvious issue is when trying to combine a line with an arc. Both can be created smoothly, but the only way to merge them into a single graphic would be a clunky group, which is rarely satisfactory. I know this can be done in LCB, but after all these years that’s still impenetrable to me.

Having toyed a bit last night with SVG paths I’m almost there actually. The good thing with SVG is that there are a ton of resources online. I’m at the point where I can generate an SVG path with scalable curves & all, create a new SVG icon widget in script and assign the path to its iconpath property. I have also created handlers to modify the path as needed and it works brilliantly.

Only problem now is that it creates a graphic that is filled instead of a stroke outline. Will look more into this. But this is definitely the solution I was looking for…

I could go the full hog and generate a full SVG I suppose, instead of just a path to assign to an SVG icon widget, but I need to learn a lot more about SVG before contemplating that, while this approach is low hanging fruit relatively and does work really well with the caveat above. If successful in doing what I want, I’ll write it up in case others find it helpful.

[richmond62]

The point being (excuse the pun) that you can increase the dot density to the point of no “jaggies” and/or that antialiasing will make them invisible.

Really?

and spent quite some time fiddling around to get 'intervals' small enough that
doing a 'move to the points' with an image of a football, the thing did not appear jerky.

[stam]

How do other points live on screen?? How do they likely increase in number, and find spaces between screen pixels??

No 'other' points live on a screen; mainly because there are no 'other' points (i.e. sub-pixels) and any supposed sub-pixelation that computer developers may claim is just a lot of very clever smoke and mirrors.

The obvious flaw in your reasoning is that you are confusing points with coordinates. It’s how you connect the coordinates that is the issue.

You can create a polygon vector graphic in LC based on coordinates, and this will always be scalable as a vector graphic. But it only connects coordinates with straight lines. Even the “curve tool” does this. Scalable but jaggies are built in, because LC doesn’t seem to have the ability to generate true Bézier curves between points.

It has absolutely nothing to do with raster images.

[richmond62]

-
Not too bad.

Code: Select all

on mouseUp
   put empty into fld "POYNTS"
   put 0.0012 into PP
   put 1 into LYNE
   repeat until PP > 6.28
      put (((SIN(PP))* 400) + 500) into LR
      put (((COS(PP))* 400) + 500) into UD
      put LR & "," & UD into line LYNE of fld "POYNTS"
      add 0.002 to PP
      add 1 to LYNE
   end repeat
   set the points of grc "Squig" to fld "POYNTS"
   move img "Blob" to the points of grc "Squig" in 15 secs
   wait 1 sec
   set the vis of grc "Squig" to false
   move img "Blob" to the points of grc "Squig" in 15 secs
   wait 1 sec
   set the vis of grc "Squig" to true
end mouseUp

[stam]

Yes thank you Richmond.

Drawing a smooth oval is not a problem. It never has been, as I alluded to in my OP, showing a smooth arc and a “jaggy” arc.

However drawing a shape that has both straight lines and curves is problematic. Which is why I’m positing this.

Since you seem to think things are doable, I’d challenge you to create a roundRect in the same way (without using the basic roundRect shape, as you can’t actually modify that - you can’t for example create a roundRect with an arrow/triangle on one sign).

[richmond62]

Since you seem to think things are doable

I am not sure what, exactly, you mean by 'doable'.

Certainly one cannot make a 'pointless' (I smoothly curved) graphic from a polygon graphic in LiveCode: one can,
however, by making the points extremely close together, fake that to a certain extent.

This "little number" has arrows at both ends of the curve:
-

[richmond62]

drawing a sharpe that has both straight lines and curves

Presumably you mean 'shape' . . .
-

-
No solids were hurt in this stack: 'Tis all code m'dears.

[stam]

If you zoom in you still get jaggies.

My point is that if I was to draw an oval or an arc from an oval it would be entirely smooth. But not so with built in methods as you elegantly but obviously inadvertently demonstrate.

So thanks - but I'll stick with SVG paths because they generate true Bézier curves...

[dunbarx]

Stam.

You also make the assumption that the only way to connect dots is a straight line.

I did not. I spoke exclusively about pixels and their unique locations on screen.

You mentioned there are more pixels on a high-res screen than there are coordinates to describe them. In other words, there are real physical screen pixels that cannot be described with an "x,y" description, where both "x" and "y" are integers. That a small black dot can be placed on such pixels by the engine, but such a pixel cannot be described by two integers. It seems odd to me that an actual physical LED triple can exist that way, and the engine has more information about such pixels than we do. How do it know?

Anyway, if that is so, then what are the "effective points"? Simply as many of the "accessible" screen points as can be delineated along a bezier, with many actually drawn points being skipped over in the description of that path?

And that path is hidden from us?

Craig