hi im new to seamly and this is my first time using this pattern . while adding seam allowance im not able to add allowance beyond point A1. PLEASE HELP
I don’t see that you are doing anything wrong by the images that you’ve posted, however, if you post your file, I can have look for you.
Here, I’ve recreated your piece:
And these are the SA settings that I’ve used:
Perhaps also let me know which version of Seamly2D you’re running, please.
@Shruthisr198, your problem is here:
You need to create different points. By using the one point twice, it’s reading it when you create your pattern piece.
pat.val (2.9 KB)
I’ve made a correction so that you can see what I mean
Thank you so much grace.
Doesn’t work. By adding points A3 and A4 after the curve should not be possible… if we follow the rules of only accessing previously created objects - unless you hack the file changing the points.
What I’ve discovered, because I just had to figure out how to create point lists in the Properties editor - limiting the list to only pre existing points… is that if you hack the file the (curve) tool dialog is happy to show points A3 and A4 when it shouldn’t. Ironically the Properties Editor works correctly on my current build and throws a warning for those post existing points that can’t be found. So yeah… a bug exists if you try to work around the dialogs.
That being said… a Cubic Bezier, or what we will call a Curve - Fixed… is not needed. A 2 point simple or Curve- Interactive will suffice. Just need to adjust the control points correctly.
Yes, a bug does exist. Node A2 shouldn’t have been able to be selected twice - a warning should’ve come up. I went into the history & inserted the 2 new nodes so that I could demonstrate how this tool is actually used.
It serves just fine as a way to make the curve semi-quadratic rather than cubic as long as one doesn’t trace the 90° next.
That is to say, as long as it doesn’t cut too close to the non-line. So it’s the normal floating-point shenanigans.
Aaa… I was wondering how you did that. The problem is, by doing that it doesn’t renumber the tool id numbers I was relying on to only display pre existing tools in the dropdowns. I may have to rethink this and see if I can base it on the History timeline.
That being said… would it not it make sense in the example that point A could be used as the control point for each end of the curve, and if so how would we be able to program the path list to not allow an end point and control be the same? Not to mention switching points in the drop down?
The only sane way would be if both types of Bezier type curves disallow ANY multiple points.
BTW… the reason why the double A2 doesn’t work with the seam allowance is the same reason we discussed a bit back with the pants pattern you had issues with. By using the same point there is no length or (end) angle, which screws up the geometry math. Especially without the angle, there is no direction with which to extend out to what would be the intersection of the 2 edges on either side of the point node. Well, there’s is an angle - it’s zero… which in most cases will not intersect the other edge so you end up with a SA like the original post.
Regarding this seam allowance problem , i found a way around by chance . If i just changed the seam allowance at A1 to anything more than 1 then i got the proper seam allowance. I changed it to 1.0001 which is insignificantly more than 1 but it worked and got the perfect seam allowance.
Odd, I had a seam allowance of 1.27.
Yes… as @Pneumarian alluded to it could be due to the fuzzy math shenanigans.
Or probably more precisely by adding the .0001 it makes sure the routine that finds the seam allowance corner - which is basically found by finding intersections of lines projected from the main path edges out to the seam allowance path.
Well… you always challenge me and again I raised to the occasion. LOL
I figured out how to use the (tool) history record in the Properties Editor to determine a list of viable combobox items based on if they are pre-existing to the current tool. I racked my brains over the past 3 days trying to get the Prop editor to use the same routine to retrieve the data container objects that the tool dialogs use. For the life of me I’m baffled why the same container data getter function with dialog tools returns a list of only valid objects while the prop editor returns ALL objects???
So, I used the History records instead - which is already in a time order - to just get a list upto to the current tool. Bingo. So you can still add tool objects in the history before the current tool and they’ll show in the combobox, while any new tool objects are excluded.
Point A3 was created after the curve, while A4 was inserted before using the history trick.
You’re absolutely amazing!!! Thank you very much I knew you could do it.
Well… hold your breath. Ran into another snag - par for the course.
Problem I’m running into is that the operational tools contain (obj) item id’s in addition to the tool id - where the DataGObjects() returns a list of the obj items, the History only returns the tool ids. So by switching to using the History in the Props Editor it crashes when click on an op’s tool point.
I know what I need to do to fix it, and it’s a bit more work ( which will also fix a related issue I’m having with the list of group items)… if it’s a an op tool I need to parse the dom doc deeper to get the tools object item id’s, replace the tool id with those in the list, and reset the tool id to the last id of the obj items. Oy vey.
BTW… like I said this will help with the Groups as I’ve added the feature to double click an obj in a list widget and it will zoom to that obj (or points related to the obj such as an arc center). Problem is, right now all I can display for ex is that a group object is a “Move” or “Rotation”… can’t display a point or curve name without digging deeper into the tool. Solving one, solves the other.
Wow! That also sounds really good.
Yeah… it is neat. I also made it so it makes a hidden group visible if you’re zooming to an object - otherwise the object you’re zooming to is hidden and kinda of defeats the purpose of zooming.
BTW… I believe I got the Properties Editor fixed with the OP’s tools. Took a bit of wrangling to get it to work… the Properties Editor was originally a 3rd party library that was separate from the base code, and hence knows nothing about the rest of the program. Ran into a naming issue with 2 different “Tool” classes named the same. Argg. Move tool works, just need to check the other ops tools and I can update the broken PR I already made.