It is currently June 16th, 2021, 11:42 am

Mouth shape question

Help with creating, editing & fixing problems with skins
User avatar
balala
Rainmeter Sage
Posts: 12782
Joined: October 11th, 2010, 6:27 pm
Location: Gheorgheni, Romania

Mouth shape question

Post by balala »

Hello everybody,

A new question arose again and I can't figure out what's going on.
I wanted to draw a mouth. I came to the Shape meter and found I have to use a Path shape. So I did, here is the code:

Code: Select all

[Rainmeter]
Update=-1
BackgroundMode=2
SolidColor=220,220,220
SkinWidth=140
SkinHeight=200

[MeterMouth1]
Meter=Shape
X=0
Y=0
Shape=Path MyPath | StrokeWidth 2 | Stroke Color 0,0,0 | Fill Color 255,255,255
MyPath=10,65 | ArcTo 130,65,60,20,0,1,0 | ArcTo 10,65,60,80,1,0,0
When loaded the skin I got the mouth, however on its right side a useless line is shown:
Shape.png
I can't figure out what is causing it and how can I get rid of it. I tried playing with the last three parameters of the arcs of MyPath option but I had to quit. No more ideas how to remove that line.
If anyone has a good idea and let me know, I thank anticipately.
You do not have the required permissions to view the files attached to this post.
User avatar
death.crafter
Posts: 176
Joined: April 24th, 2021, 8:13 pm

Re: Mouth shape question

Post by death.crafter »

balala wrote: June 1st, 2021, 3:50 pm Hello everybody,

A new question arose again and I can't figure out what's going on.
I wanted to draw a mouth. I came to the Shape meter and found I have to use a Path shape. So I did, here is the code:

Code: Select all

[Rainmeter]
Update=-1
BackgroundMode=2
SolidColor=220,220,220
SkinWidth=140
SkinHeight=200

[MeterMouth1]
Meter=Shape
X=0
Y=0
Shape=Path MyPath | StrokeWidth 2 | Stroke Color 0,0,0 | Fill Color 255,255,255
MyPath=10,65 | ArcTo 130,65,60,20,0,1,0 | ArcTo 10,65,60,80,1,0,0
When loaded the skin I got the mouth, however on its right side a useless line is shown:
Shape.png
I can't figure out what is causing it and how can I get rid of it. I tried playing with the last three parameters of the arcs of MyPath option but I had to quit. No more ideas how to remove that line.
If anyone has a good idea and let me know, I thank anticipately.
I tried it and found out it is the stroke width at the point of conjunction of the two arcs. If you use ClosePath=1, you'll get something like this:
Screenshot 2021-06-01 215505.png
The more the stroke width, the more the height of the redundant line. And this problem persists even if you use two different shapes and combine them wit XOR.

So I guess it's a bug in the StrokeWidth of arcs(or path) when the junction point is intersecting each other at an acute angle.
You do not have the required permissions to view the files attached to this post.
from the Realm of Death
User avatar
balala
Rainmeter Sage
Posts: 12782
Joined: October 11th, 2010, 6:27 pm
Location: Gheorgheni, Romania

Re: Mouth shape question

Post by balala »

death.crafter wrote: June 1st, 2021, 4:46 pm I tried it and found out it is the stroke width at the point of conjunction of the two arcs. If you use ClosePath=1, you'll get something like this:
Screenshot 2021-06-01 215505.png

The more the stroke width, the more the height of the redundant line. And this problem persists even if you use two different shapes and combine them wit XOR.

So I guess it's a bug in the StrokeWidth of arcs(or path) when the junction point is intersecting each other at an acute angle.
I suppose you mean this: MyPath=10,65 | ArcTo 130,65,60,20,0,1,0 | ArcTo 10,65,60,80,1,0,0 | ClosePath 1. If you do, this indeed is better, however not perfect. Let's see if this is indeed a bug. Waiting for a dev, to tell what's going on.
Thanks again.
User avatar
Yincognito
Posts: 3184
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: Mouth shape question

Post by Yincognito »

death.crafter wrote: June 1st, 2021, 4:46 pm I tried it and found out it is the stroke width at the point of conjunction of the two arcs. [...] The more the stroke width, the more the height of the redundant line. And this problem persists even if you use two different shapes and combine them wit XOR.

So I guess it's a bug in the StrokeWidth of arcs(or path) when the junction point is intersecting each other at an acute angle.
balala wrote: June 1st, 2021, 5:29 pmIf you do, this indeed is better, however not perfect. Let's see if this is indeed a bug. Waiting for a dev, to tell what's going on.
Well, I'm not a developer (at least not of Rainmeter), but this is definitely a bug. Death.Crafter is correct, the bug gets worse if one increases the StrokeWidth parameter, but the underlying cause of this is not the StrokeWidth, but rather the SweepDirection parameter of Arc shapes when its value is 1. Before I enter into other details on the matter, here's a temporary workaround, but only for low StrokeWidth cases:

Code: Select all

[Rainmeter]
Update=-1
BackgroundMode=2
SolidColor=220,220,220
SkinWidth=140
SkinHeight=200

[MeterMouth1]
Meter=Shape
X=0
Y=0
Shape=Path MyPath | StrokeWidth 2 | Stroke Color 0,0,0 | Fill Color 255,255,255
MyPath=10,65 | ArcTo 130,65,60,20,0,1,0 | LineTo 130,65 | ArcTo 10,65,60,80,0,0,0
ArcTo - Workaround.jpg
It's basically about using a LineTo segment to the same 1st arc ending to "stabilize" the incorrect line segment problem.

This won't work completely for higher StrokeWidth-s though. Though it mostly corrects the original code behavior (i.e. without the "static" LineTo segment), setting StrokeWidth to 10 in the above code still produces similar (but milder) artefacts:
ArcTo - Still Problems.jpg
Changing the "static" LineTo end point coordinates (like setting its Y to, say, 68) to try and further correct the issue actually makes it even worse (and in the wrong direction, LOL):
ArcTo - Worse.jpg
However, when changing the SweepDirection parameter of the 1st ArcTo segment to the default 0 (that segment would then become ArcTo 130,65,60,20,0,0,0), it seems the following arc (i.e. the 2nd one) correctly grabs its starting point, even without the static / stabilizing LineTo segment:
ArcTo - No Problems.jpg
So it looks to me that the behavor is triggered by the SweepDirection parameter of an ArcTo, and its effects are grossly made worse by a higher StrokeWidth. Maybe it has something to do with how those intersecting ellipses that an arc is made of create the shape in the first place - the intersection point when the ellipses are not partially exclusive could be "lost" somehow... :???:
You do not have the required permissions to view the files attached to this post.
User avatar
balala
Rainmeter Sage
Posts: 12782
Joined: October 11th, 2010, 6:27 pm
Location: Gheorgheni, Romania

Re: Mouth shape question

Post by balala »

Yincognito wrote: June 5th, 2021, 6:20 pm Well, I'm not a developer (at least not of Rainmeter), but this is definitely a bug. Death.Crafter is correct, the bug gets worse if one increases the StrokeWidth parameter, but the underlying cause of this is not the StrokeWidth, but rather the SweepDirection parameter of Arc shapes when its value is 1. Before I enter into other details on the matter, here's a temporary workaround, but only for low StrokeWidth cases:
Well, thank you for the help, this in fact seems to be fixing the problem. I have to work with it a little bit more, but at least at a first approach, it is seeming to help. I have to transfer the approach to my skin in which I ran into this problem (because I suppose it's clear that the problem occurred into a much more complex code), but it seems this is a convenient approach.
Now if I don't get a reply by a the dev, I'm gonna post this into the Bugs & Feature Suggestions section, but this trick seems to do the job.
So, thank you again. Great idea, which I could never figure it out by myself.
User avatar
Yincognito
Posts: 3184
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: Mouth shape question

Post by Yincognito »

balala wrote: June 5th, 2021, 7:06 pm Well, thank you for the help, this in fact seems to be fixing the problem. I have to work with it a little bit more, but at least at a first approach, it is seeming to help. I have to transfer the approach to my skin in which I ran into this problem (because I suppose it's clear that the problem occurred into a much more complex code), but it seems this is a convenient approach.
Now if I don't get a reply by a the dev, I'm gonna post this into the Bugs & Feature Suggestions section, but this trick seems to do the job.
So, thank you again. Great idea, which I could never figure it out by myself.
No problem, but as I already mentioned, this doesn't "fix" the problem, it only alleviates it. For StrokeWidth=2 in your case it will work because the difference between fixing and alleviating is not obvious to the naked eye there, but for higher StrokeWidth values the fact that the problem is not entirely corrected is quite visible. Much less visible than without the workaround, but still visible.

And yes, you should definitely post about this in the Bugs section. You should also ask the devs to move this conversation / posts from here to there, as the current findings might be important in debugging the issue further or correcting the bug for good.
User avatar
balala
Rainmeter Sage
Posts: 12782
Joined: October 11th, 2010, 6:27 pm
Location: Gheorgheni, Romania

Re: Mouth shape question

Post by balala »

Yincognito wrote: June 5th, 2021, 7:15 pm No problem, but as I already mentioned, this doesn't "fix" the problem, it only alleviates it. For StrokeWidth=2 in your case it will work because the difference between fixing and alleviating is not obvious to the naked eye there, but for higher StrokeWidth values the fact that the problem is not entirely corrected is quite visible. Much less visible than without the workaround, but still visible.
This won't be a problem for me, because I'm not planning to use thicker lines (at least so far I suppose I won't use - however as usually this might change over time).
Yincognito wrote: June 5th, 2021, 7:15 pm And yes, you should definitely post about this in the Bugs section. You should also ask the devs to move this conversation / posts from here to there, as the current findings might be important in debugging the issue further or correcting the bug for good.
I wait a day or two, to see if I'm get a reply here, not to fill the Bugs section, but if I don't, then I'll post it there as well.

Thanks again.
User avatar
Yincognito
Posts: 3184
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: Mouth shape question

Post by Yincognito »

By the way, another option that would for sure fix the problem (if it was possible in the first place, that is, considering the Fill options) is to hypothetically use 2 simple Arc shapes (and not ArcTo-s), then Rotate one of the Arcs to achieve the equivalent of a SweepDirection parameter on that arc. This would make the fill impossible since the arcs would belong to different shapes, but I'm sure it would in theory solve the incorrect line segment problem...
User avatar
balala
Rainmeter Sage
Posts: 12782
Joined: October 11th, 2010, 6:27 pm
Location: Gheorgheni, Romania

Re: Mouth shape question

Post by balala »

Yincognito wrote: June 5th, 2021, 7:34 pm By the way, another option that would for sure fix the problem (if it was possible in the first place, that is, considering the Fill options) is to hypothetically use 2 simple Arc shapes (and not ArcTo-s), then Rotate one of the Arcs to achieve the equivalent of a SweepDirection parameter on that arc. This would make the fill impossible since the arcs would belong to different shapes, but I'm sure it would in theory solve the incorrect line segment problem...
Yes, but filling is important, so probably this is not an option.
User avatar
Yincognito
Posts: 3184
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: Mouth shape question

Post by Yincognito »

balala wrote: June 5th, 2021, 7:37 pm Yes, but filling is important, so probably this is not an option.
Indeed. In the search for the perfect workaround (I like perfection as you probably remember, LOL), I thought I found the one by replacing ArcTo-s with CurveTo-s ... only to find out that Curves also exhibit the same behavior (the code toggles from ArcTo-s to CurveTo-s and viceversa on mouse scroll - it was my simple way of making the overall shape identical to the original):

Code: Select all

[Variables]
Style=0

[Rainmeter]
Update=-1
BackgroundMode=2
SolidColor=220,220,220
SkinWidth=140
SkinHeight=200

[Style0]
Shape=Path MyPath | StrokeWidth 10 | Stroke Color 0,0,0 | Fill Color 255,255,255
MyPath=10,65 | ArcTo 130,65,60,20,0,1,0 | ArcTo 10,65,60,80,0,0,0

[Style1]
Shape=Path MyPath | StrokeWidth 10 | Stroke Color 0,0,0 | Fill Color 255,255,255
MyPath=10,65 | CurveTo 130,65,10,172,130,172 | CurveTo 10,65,130,92,10,92

[MeterMouth]
Meter=Shape
X=0
Y=0
MeterStyle=Style#Style#
MouseScrollUpAction=[!SetVariable Style (1-#Style#)][!UpdateMeter MeterMouth][!Redraw]
MouseScrollDownAction=[!SetVariable Style (1-#Style#)][!UpdateMeter MeterMouth][!Redraw]
DynamicVariables=1
So much for my perfect workaround, LMAO. After the CurveTo experiment, I'm not sure the culprit is the SweepDirection parameter of arcs anymore, since cubic Bezier curves like this lack that parameter in Rainmeter. It seems the problem has a greater extent than I thought, and more shapes are affected, just like death.crafter stated earlier... :confused: