SVG interpreter about two.js HOT 28 CLOSED

Thanks for reporting this @graphmeter! Do you have the SVG files or an online example of the issues you're running into? It'll be easier for me to debug.

from two.js.

Here is the svg where I observe that the circular hole is not closing (and appears to be white when it should be black):

<?xml version="1.0" encoding="utf-8"?>
<!-- Generator: Adobe Illustrator 15.0.1, SVG Export Plug-In . SVG Version: 6.00 Build 0)  -->
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
     width="595.279px" height="841.89px" viewBox="0 0 595.279 841.89" enable-background="new 0 0 595.279 841.89"
     xml:space="preserve">
<path d="M304.641,238c-78.277,0-141.733,63.457-141.733,141.733s63.457,141.733,141.733,141.733
    c78.275,0,141.731-63.457,141.731-141.733S382.916,238,304.641,238z M304.641,452.901c-40.41,0-73.168-32.759-73.168-73.167
    c0-40.409,32.758-73.167,73.168-73.167c40.407,0,73.165,32.759,73.165,73.167C377.806,420.142,345.048,452.901,304.641,452.901z"/>
</svg>

The hole closing is ok for square holes:

<?xml version="1.0" encoding="utf-8"?>
<!-- Generator: Adobe Illustrator 15.0.1, SVG Export Plug-In . SVG Version: 6.00 Build 0)  -->
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
     width="595.279px" height="841.89px" viewBox="0 0 595.279 841.89" enable-background="new 0 0 595.279 841.89"
     xml:space="preserve">
<path d="M159.349,212.154v283.464h283.464V212.154H159.349z M371.948,424.753H230.216V283.021h141.733V424.753z"/>
</svg>

After trying a few fill colors I was only able to reproduce the color issue for black fills.

from two.js.

Thanks so much for sharing resources and looking into this further. Based on this JSFiddle it looks like the holes work correctly. You'll notice that I have to force the black shading. It looks like the browser renders fill=black and stroke=transparent by default, which is why it wasn't showing up previously. I'll update two.js so that this is not the case when interpretting svgs.

from two.js.

Based on this latest commit interpretation should work as expected.

from two.js.

Thanks! The holes looks fine with only fill but with a stroke I still get this:

from two.js.

Great find @graphmeter! I just pushed an update to master that fixes this. Here is the latest JSFiddle showing that the error should be resolved. 👍

from two.js.

Works great! If I count the number of vertices for the polygons (square/round) I get 11? Shouldn't the ideal number be 8?

Another thing, when an anchor is moved the positions of controls are not moving along (Anchor example), is there a reason for the controls not having local coordinates (which seems to be the case in Illustrator)?

from two.js.

Glad to hear it @graphmeter!

In the JSFiddle posted above the rectangle has 9 and the circle has 11. The reason for this discrepancy is because the close command Z has to be treated as a vertex in Two.js. In addition, the Z command closes a path with a straight line. In order to make sure that a curve stays curved throughout its visible rendering I add an additional curve point where the initial move command. This forces the Z command to close itself on identical points.

As for the localized anchors, this is a great idea! I hadn't thought about doing this, but this makes a lot of sense from a developer's perspective. At the moment there are two modes for a Two.Polygon, automatic = true and automatic = false. The prior is the default behavior for a polygon. When automatic = true; curved = true; then each anchor's control points will get automatically populated based on its position in relation to its neighbors. This how the Morph Example can be written with so little code. However, when you interpret an svg there are many different use cases for the anchors (including the one you mention) and as a result I turn off automatic and let you decide what you'd like the anchors to do. That's about as far as I thought, so it makes sense to address localizing the anchor points. I can see instances where you'd like anchor points to be in absolute space and other times when you want it in relative space.

If you don't mind, can you open up a new issue to add the ability to localize anchor points. I could see it something like anchor.relative = true; or something.

from two.js.

I see, but the additional anchors causes problem if one of the anchor points is moved:

Would it possible to introduce a simplify-path function, so that overlapping anchors are replaced by one?

Added the issue. Is there an easy way to get the global position of an anchor point? Currently, I am traversing the scene from the anchor point through the hierarchy to the two.scene in order to obtain the global position.

from two.js.

Ah interesting. Thanks so much for your thoroughness. Aside from anchor.x, anchor.y, anchor.controls.left.x, anchor.controls.left.y, anchor.controls.right.x, anchor.controls.right.y there is no other way to assess. This is definitely another thing I should add. You could get close using polygon.getBoundingClientRect();, which is in the global space, and then subtracting the anchor, but that gets really gross and I don't recommend it even as a stop gap.

As a stopgap this is the main reason why I chose an event system as the underlying logic for two.js. If you know the two anchors in question, which I think you do based on what we've done so far you can make one a slave of the other by doing this:

var a1 = polygon.vertices[0];
var a2 = polygon.vertices[1];
a1.bind('update', function() {
  a2.copy(a1);
});

Hope this can help during the interim!

from two.js.

Thanks! Yes, binding works but I guess it can get messy if there are lots of polygons.

from two.js.

Indeed! That's why it's a stop gap... Be careful not to bind in both
directions too. I'm not certain, but I think it could cause an infinite
loop. Let me know how it goes!
On Fri, Jan 31, 2014 at 4:26 AM, graphmeter [email protected]
wrote:

Thanks! Yes, binding works but I guess it can get messy if there are lots
of polygons.

Reply to this email directly or view it on GitHubhttps://github.com//issues/63#issuecomment-33790092
.

from two.js.

Yes :). On a similar topic; is there a way to translate a scale/rotation of a group to positions of vertices when scale/rotation=1, apart from traversing down the group taking into account the scale/rotation for each sub object and moving the vertices into place? Hope it makes sense.

from two.js.

I don't believe so, but I'm not entirely sure what you mean. If you have a demo online it would help :) If you're looking to apply the matrix of a group to a set of vertices you can do:

var shape = two.makeRectangle(0, 0, 50, 50);
var group = two.makeGroup();
group.translation.set(two.width / 2, two.height / 2);
_.each(shape.vertices, function(v) {
  var projection = group._matrix.multiply(v.x, v.y, 0);
  v.copy(projection);
});

from two.js.

Thanks! Using the transformation matrix really helps, I wasn't aware you could access it. I still have to traverse the scene though as this http://jsfiddle.net/AC6Z6/1/ shows.

from two.js.

Nice, glad to hear _matrix is useful! Unfortunately, I think traversing the children and vertices is the only way to do what you're describing. But, if you don't mind, what are you ultimately doing? Maybe there's a more efficient way to achieve the end goal.

from two.js.

I would like to scale/rotate an imported svg with deeply nested groups and then calculate the bounding box for any of the groups. I have tried the getBoundingClientRect but it doesn't seem to work that well for nested groups and when rotation/scale is applied, so currently I am calculating the global vertices positions (as above). This works fine but ideally I would like to determine the bounding box for the closed bezier curves.

from two.js.

If you make online examples I can help try to sort out the getBoundingClientRect issues. I'll have to do some thinking on what the most efficient way to apply an operation your describing. Does this happen on requestAnimationFrame?

from two.js.

Sorry for the delay, this http://jsfiddle.net/6aLkX/1/ illustrates the problem I think, which seems to happen even for static drawings. Thanks for all the help!

from two.js.

Update: I believe it's an orders of operation issue on my part. Instead of calculating the bounding box and then applying the world matrix, I should apply the world matrix to each vertex and then get the bounding box of those projected coordinates. Although this gets into territory we've been before as described in issue 46. Should we be more forward thinking than what browsers have implemented or concede to their standards?

No worries, thanks so much for the follow up. Just to be clear, this example exposes inaccuracies in getBoundingClientRect(), which I think I can fix. Keep you posted.

from two.js.

Yes, I believe the getComputedMatrix should be applied first to the vertices followed by finding corner values, then projected back to local if shallow. I think it would be good have a more accurate bounding box, useful when for example animating with nested groups with different scaling/rotation, detecting interactions etc?

from two.js.

So it seems that it was an orders of operation issue. This should be fixed with the latest commit on the master branch and I added tests which match your JSFiddle reproduction 👍

from two.js.

I tried the jsfiddle code with the latest build and still get the same result?

from two.js.

Ah, sorry about that. I had to modify your example because you weren't referencing the bounding box's left or top property to set the placement of the orangered rectangle: http://jsfiddle.net/6aLkX/3/

from two.js.

Ah, didn't notice that, thanks!

from two.js.

It seems like there is an issue when there are multiple nested groups: http://jsfiddle.net/kS4wr/1/

from two.js.

👍 http://jsfiddle.net/kS4wr/3/ Latest build fixes this issue. Good find!

from two.js.

Thanks for the speedy fix!

from two.js.