Jump to content
Search Community

DrawSVG Problem with stroke-dasharray

Davros test
Moderator Tag

Warning: Please note

This thread was started before GSAP 3 was released. Some information, especially the syntax, may be out of date for GSAP 3. Please see the GSAP 3 migration guide and release notes for more information about how to update the code to GSAP 3's syntax. 

Recommended Posts

I'm trying to recreate an animation I already built that reveals a logo - it is shown in the attached gif. I did this with a lot of javascript and a complicated clippath and svg setup. I want to use DrawSVG to rewrite and simplify the animation and also avoid the aliasing that's occurring where the lines meet/overlap. (I believe I fixed the aliasing issue by using one single path for the 'M' and 'T' instead of multiple).

 

Problem: In the codepen, the stroke-dasharray is not calculated from the size of the letter T, but is ~1700px.

 

You can see in the pen that the mask moves far beyond the T before it yoyos back.

 

Any ideas what I'm doing wrong? Thanks!

 

Sep-26-2019 14-55-52.gif

See the Pen pozBNBb by davrosfl (@davrosfl) on CodePen

Link to comment
Share on other sites

Hey Davros, thanks for being a Club GreenSock member!

 

There's a couple of ways to structure this animation. I think perhaps the simplest would be to actually have 5 paths (the four start points and the one start point in the top middle of the T). That way you can just draw each path with the proper timing and let layering do the rest. 

 

In terms of your question here, I'm not exactly sure why the stroke dash array is so long. You might learn something from this post, especially the video about setting up SVGs in Illustrator at the top:

P.S. If you are using multiple paths, you likely want to have them overlap very slightly. See this post for more info.

  • Like 3
Link to comment
Share on other sites

16 hours ago, ZachSaucier said:

Side note: you don't actually need masks for this. You can just use paths with a "butt" or "square" linecap.

Zach, Thanks so much for your response. The Club membership is so worth it :) 

 

So after reading your included materials, the solution seems to boil down to: 1) going back to my original approach using of multiple paths; 2) using notches/overlap techniques to avoid the edge artefacts.

 

Since my SVG is sized relative to screen size, I was getting edge artefacts on some screen sizes, but not others. I guess I have a lot of experimenting to do.

 

Do you have any codepens handy that show how to do SVG reveals using that "butt"/'square" linecap method you mentioned? I would MUCH prefer to actually draw the SVG instead of having to go through the extra hassle of revealing it.

 

  • Like 1
Link to comment
Share on other sites

1 minute ago, Davros said:

Do you have any codepens handy that show how to do SVG reveals using that "butt"/'square" linecap method you mentioned?

Well, "butt" and "square" are values of the SVG path's stroke-linecap. I was just saying that's the type of linecap you need to use in this case.

 

Animating a path should be straightforward, but here are some simple demos pulled from other threads:

See the Pen KWQrvm?editors=0010 by GreenSock (@GreenSock) on CodePen

 

See the Pen KdPKZY by GreenSock (@GreenSock) on CodePen

  • Like 2
Link to comment
Share on other sites

Thanks for all of your responses and info. Based on your help, I have it working perfectly and there are no edge artifact issues any longer as I scale the image to any size: 

See the Pen VwZNMrQ by davrosfl (@davrosfl) on CodePen

 I used the overlap approach as a work-around to the edge artifact problem. Worked like a charm.

 

Huge thanks!

 

EDIT: Added Sine.easeInOut per your suggestion to add an ease to reduce jerkiness.

Link to comment
Share on other sites

I also wanted to note something for other readers that the edge artifacts were solved by the use of overlapping paths AND use of "shape-rendering: crispEdges;" on those paths. This is an option for straight line paths which I'm using here. On curves, it will produce unsightly aliasing. It's not my preferred solution, but it does the job in this particular case.

 

@ZachSaucier @OSUblake, do you know of a more elegant solution to removing edge artifacts with paths that overlap or butt against each other (especially when the paths are the same color)? I've attached a screenshot of the SVG showing the artifacts when crispEdges isn't used. I tried reordering the paths in the SVG, but that didn't solve the artifact problem.

 

 

edge_artifacts.png

Link to comment
Share on other sites

I'm not familiar with SVG to know the answer to that off the top of my head, no.

 

I do notice that your line animation is a little jerky - one thing you can do to improve it is combine the #tmiLogoMLLeg path with the #tmiLogoMLTop path on each side. Besides that, playing with the easing functions of the drawSVG can really help improve the look of the animation.

  • Like 1
Link to comment
Share on other sites

49 minutes ago, Davros said:

do you know of a more elegant solution to removing edge artifacts with paths that overlap or butt against each other (especially when the paths are the same color)?

 

Most people won't like this response because they want their SVGs to be scalable, but sometimes you don't need them to be. So you could remove the viewBox from your SVG so it doesn't scale, and make everything pixel perfect.

 

Well, sort of. The thing about strokes is that if the width is an odd value, it will cause antialiasing. If you have a stroke that is 1px wide, it will straddle 2 pixels. Half of the stroke will be in one pixel, and the half will be in the other pixel.

 

The fix is to move it over half a pixel. The bottom box is moved over 1/2 a pixel.

 

See the Pen dfd6a4ca4e7d1c252c819996c56fd07b by osublake (@osublake) on CodePen

 

A little experiment that zooms in to let see what's going on. If you click the Translate 1/2 pixel option, lines that are odd width will clear up.

 

See the Pen 08be2488622766dc922010a69c5b40c8 by osublake (@osublake) on CodePen

 

Of course, that trick only works if the a line is positioned at whole values. If the line's x/y position was 100, it would work. It the line's x/y position was 100.2, it wouldn't. It can be very tricky to get everything aligned perfectly.

 

 

  • Like 3
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...