Hi Friends,
I'm playing around with the Spirograph Effects, and having a blast! I LOVED that toy when I was a kid; and I'm loving the Inkscape spirograph too!

Slight glitch in the fun -- the spirograph-made path does not seem to respond to snapping. Is that how it should be, or is this yet another bug? I don't find any mention at Launchpad

I can't get nodes of other paths to snap to the spiro's nodes, and I can't get the spiro's nodes to snap to nodes of other paths. Likewise, nodes of other paths won't snap to spiro's path, and spiro's nodes won't snap to other paths. I haven't tried snapping bounding boxes, because I don't need that to happen in this case. But I can test it out if necessary. Same for grids and guides.

Is there something about the spirograph's paths that makes them different, or makes them behave differently?

could not replicate the problem -> I'm using a Apr1 build of 0.46 and it all works...
If Document properties are set to: enable snapping, what snaps = nodes, snap to paths, snap to nodes, snap only when closer than 20 pix, then the spirograph can be snapped to path and node, (although there is only one node), and the spirograph can snap its own nodes to other paths and nodes (if the node tool is set on the spirograph all the nodes show and are snappable)

Aaaarrrghh!! I have the worst luck with snapping
Yes, I have the settings right. Because other nodes and paths snap as expected.
Well, I guess I can use the align nodes trick, where if you align nodes both horiz AND vert, it's as if they snapped -- for the nodes. It doesn't help with the paths though.

Oh well....see what I mean by buggy? The problems I have may not be official bugs. But if I'm doing everything right, and still have the problem, what else can you call it?

Anyway, thanks for your reply, loonquawl

FYI, in another image I just started, the spirograph path snaps as expected. Any idea what could have caused the problem in the other image? Or best just to chalk it up to a glitch, if not bug?

Thanks for your patience with me.

Could you post the non-snapping picture so i might try it on my Inkscapes (046 on XP and Ubuntu)?

Thanks loonquawl, I appreciate you taking the time to do this
Here's a link to the svg:
http://www.petaimg.com/uploads/1219574221.svg
Notice how you can snap the individual objects' paths to each other, but not to the spirograph path?

Um, he didn't say exactly the error message he got. But it does sound like the same problem.

However, he's since been able to access it. So maybe try again?

loonquawl, I'm sorry you're having so much trouble accessing this image. If you still have some time to spare, I've uploaded it again. And at this moment, I can open it.

Here's the new link: http://www.petaimg.com/uploads/1219785313.svg

Thank you very much

[Edit -- PS, as you may have read in my other thread on spirograms, I've found out through petaIMG's blog that they just switched to a new host, the day before I uploaded this. So maybe they just need to work out some glitches.]

2nd Edit -- I may have discovered a helpful clue to this problem, although I don't know exactly what it means. The spirograph path I am working on, which I received invaluable help in this topic, help understanding path operations, exhibited proper snapping behavior before we did the Union (on the spirograph path alone), then Difference with the light pink circle. But now it's not snapping to other paths or other paths snapping to it.

If path operations somehow affect snapping abilities, I may have done a path operation on the spirograph path which is the subject of THIS topic. Unfortunately, I've closed and opened THIS image several times since posting this topic, so I can't look at the Undo History to jog my memory. Well actually, "closed" is a bit of a stretch. I was attempting to keep it open, to help with troubleshooting, but Inkscape has crashed 2 or 3 times since.

Likewise, neither can I undo the path operations on the path in the other topic, to try and determine exactly when snapping became disabled. But while waiting for replies, I'll try and recreate a similar spirogram, to test out the theory that path operations negatively affect snapping of spirograph paths.

Geez, like microUgly in the other topic, these threads and problems have exhausted me. I'll have to take a brief sabbatical from learning Inkscape after this problem has concluded!

I finally was able to access the old one (http://www.petaimg.com/uploads/1219574221.svg - the new one has the old error )

There are lots of spirograms (some very cool colored ones) - some only look like spirograms, but are lots of path debris, some are whole - i made a circle and can snap its nodes to any spirogram in the picture.
But: Trying to snap one spirogram to another i noticed, that this only works if my computer is not overly taxed at that moment. If he is, it takes some time (i have to hover near, making only little movement, then it suddenly snaps), or never happens (never here meaning: not until i run out of patience...).

So maybe your computer is a little slow? I imagine it to be quite a task to snap a node to a path, maybe he is simply not up to it, in reasonable timeframes.
Debris-node to OtherDebris-node never poses a problem, so it might have something to do with the number of nodes in Snapper and SnappedTo (? - too lazy to experiment...)

Edit: Open the Task Manager (or Linux equivalent, and have a look at the CPU-Strain while dragging a node - quite amazing !)

Yes, I think it's a fairly well known bug, how cpu use spikes when moving cursor across canvas, whether it's dragging something or not. I've actually had trouble with double-clicking, where the cpu maxes out on the 1st click, so that the 2nd click doesn't "register". But with this snapping issue, I can snap to the object just across the spirograph path, just a fraction of an inch away from the spirograph path. So if the cpu was an issue, I would not be able to snap to the other objects either.

I'm not sure what you mean by "path debris"? Let me just insert the image here to make sure we're "on the same page". (When I 1st uploaded this, I thought only the part of the image within the image border would show up. So from now on, I know only to upload the image in question.) So here's the whole image, zoomed way down and thumbnailed:

And let's use the one in the hot pink ellipse for reference. You can't see it unless you zoom all the way to 25600, the spirograph path, because the stroke is only 0.001 wide. I did this because I intend to snap the purple and green paint bucket fill paths to the spirograph path. So that when it's finished, it looks like the purple and green objects meet exactly. (Yes tedious, but I tend to be detail oriented, and I enjoy tedious ) Please note that even if I make the spirograph path 1.000 wide, it won't snap or be snapped.

And so for further clarification, let's look at the area in the bright blue circle:


So zoom all the way in on that area (using the SVG, of course) so you can see the 0.001 stroked spirograph path. Now notice how the green and purple filled paths snap to each other, but not to the spirograph path? That's the problem. Can you (or anyone) see this happening in the SVG I provided (if anyone else has been able to access it)?

When you said you drew a circle and snapped it to the spirograph, I'm guessing it was actually snapping to the (purple or green) paint bucket filled paths inside the spirograph path? Although...ok, more clarification -- some of the spirograph paths in the whole image, DO display proper snapping behavior, for example, the one (with some strong blue coloring) directly below the hot pink circled one. But in the hot pink circled one, the one to its right, and the one below that (mostly not filled except a few light blue areas) -- these 3 do not display proper snapping. I haven't checked on the bottom row of 3 spirograms. So maybe you were testing the snap on one of the spirograms with proper snapping.

I'm sorry for the confusion, and for not uploading only the object in question. Although maybe it provides helpful contrast between those that snap properly and those that don't? And I'm REALLY sorry about the difficulty accessing the SVG on petaIMG!



Thanks again for your help. I'll be interested to know if you (or anyone) experience the same issue.

All best.

I looked into the green-and-purple spiro: Snapping of spiro to Color-Areas works, Color-Areas to Spiro does not, even after not-unsubstantial waiting... (yawn )
So there seems to be an issue with whatever algorithm is looking for current cursor position vs. Paths&Nodes.

On another note: Wouldn't it be easier to achieve this look by filling the spiro (with the leave-holes option) with purple, then construct an underlying circle with green (cutout for the middle), and then overlay a ying-yang style form with a gradient?

I looked into the green-and-purple spiro: Snapping of spiro to Color-Areas works, Color-Areas to Spiro does not, even after not-unsubstantial waiting... (yawn )
So there seems to be an issue with whatever algorithm is looking for current cursor position vs. Paths&Nodes.

From your description, I don't think cpu-related freeze-up or waiting is as much of a problem for me, as it is for you (I run 1.24 gigs ram, fyi)

So you DO confirm that this spirograph path is not exhibiting proper snapping behavior! I suppose we should have a couple more people confirm this before reporting it? (...if anyone else can access the file at petaIMG!) So finally

But now I'm confused, because of a comment microUgly made to me in another topic:

So when you say something doesn't work on a spirograph, the same must be true with any other path whether it was generated using the spirograph effect or not. This might help you identify why it's not working as you expect.

In this case, we can't say that pen- or pencil- made paths exhibit this same behavior..............whoa!!

Except perhaps in this case, where we've determined that there are occassions when portions of a path go sort of dead temporarily. In this situation, the path doesn't show the node tool cursor with the little hand in these areas, and doesn't respond to single- or double-click, can't be grabbed, dragged or selected, and you can peruse that discussion by following the link I provided just above.

The good news is that we think that bug has been fixed in the very most current version, which I'm not using at this time. I'm using 0.46, the last stable version.

However, on the other side of the coin, we have the possibility that the lack of snapping is not related to this other issue. After all, the snapping problem occurs apparently at every point along the path, while the other issue is intermittent.

So I'm not sure what should happen at this point? I guess we just need to hear from others, who are running various versions, as to whether they experience this snapping behavior or not?...IF they can access the SVG on petaIMG. But I certainly defer to the more knowledgeable and more experienced members here. What's next?

Many thanks for your patience and help, loonquawl

Hi again,
Quick update:
Now I'm working on another image, in which the spirograph path does not seem to be responding to snapping. Again, other objects are snapping as expected. And again, the other objects' paths are made with the Paint Bucket tool .

But I guess until petaIMG solves their problem, I won't upload another sample svg file.

Hi Friends,
Hey, I've found a few more tidbits of info about this snapping behavior with spirograph-made paths. I guess I'm not going to set up any SVG's for examination, at this time. I'm going to give petaIMG a little longer before I go for Firefox and Mediafire.

I've made probably hundreds of spirograms over the last couple of weeks (as I said, it captivates me!). But I just tonight noticed that not all of them are closed paths. Ok, here, I'll put up some PNG's, just for a visual.



Notice at the end of the hot pink arrow is the end of an open path. But the other spirogram is clearly closed. As a general rule, the more complex the spirogram, the more it's likely not to be a closed path. Although there certainly are very complex, closed-path spirograms.

Um, my snap settings are:
What snaps: Nodes
Snap to objects: Snap to nodes and Snap to paths
No snapping to segment intersections.

So here's what I've just observed:
-- Using a simple rect object, which has NOT been converted to a path, each of its corners snaps to the end node of the path on the left, the open path. But its side segments will not snap to the end node.
-- The rect also snaps to certain other areas in the path on the left. But I haven't yet determined what distinguishes the other areas, that might be causing them to snap. The path on the left has 1000 nodes, so I'm unclear why the rect's corners snap to the end node, possibly some other nodes, but certainly not all the nodes. I'm also not clear why the rect object, which contains no nodes, only snaps at the corners, where the nodes would be if it was converted to a path.
-- All sides and all corners of the same rect, will snap to every node and segment of the closed spirogram, on the right. I'm unclear why the segments of the rect can be snapped to the spirogram on the right, but not to the end node of the one on the left.

So that about covers the new facts I've just observed. I suppose if someone was interested enough, I could email the file to them, and they could upload it somewhere. But otherwise, I'm content to give petaIMG a little longer, for now.

[Edit -- Just figured out that the other area of the left spirogram which is being snapped to by the rect object is (duh!) the other end of the path. It's hard to see, in fact I can't see it at all without a good deal of zoom. And again, it's only the 4 corners of the rect that snap, its segments do not snap to these end nodes.]

Slightly Off-Topic:
1000 nodes seems to be the maximum the Spiro-Tool does, which elicits some rather strange behaviour:
Some Spirograms are non-repetitive, or only start to repeat themselves after lots and lots of "turns". -> They always are created with 1000 nodes. If the Quality is set to 100 , only a few turns are rendered, leaving the path open. This is because the 1000 nodes are tighly set. Quality set to low values (say, 5) gives many many turns (mostly one black disc of overlying paths) and strains the memory like crazy (values like "1" let inkscape ponder a while, write 1GB (!) to swap, and then fail.... - although only 1000 nodes are set here, too! It is all about rendering the paths in between the nodes.

If, on the other hand, the spiro is repetitive in the first few turns (closed path), the value of 1000 nodes is not reached for low quality settings : here, the quality actually says something about how faithful the path is rendered. Repetitive Spiros with the same settings (apart from Quality) do not match if overlaid. Non-Repetitive Spiros on the other hand, do completely overlap, if only for those paths that they have in common (Low Quality has a longer path).

EDIT: I should've looked into the Tavmjong-Manual. 1000 node maximum, quality, all there.

Slightly more back to topic:
I still think this is only a performance problem, not a spiro-bug : The paths i made to compare behaviour invariably were scribbles where i boosted the number of nodes - this makes for very short paths between nodes, thereby probably easing the computing & memory strain, while the spiros have long distances between nodes, that have to be computed.

I still think this is only a performance problem

But if it's a performance issue, why does it only affect the spiro's path, and no other paths? If the cpu gets overloaded, and won't allow a snap, shouldn't that happen relatively as often to all paths in the image? But it doesn't, it only affects the spiro's path, and it always affects the spiro's path. And never the other paths.

brynn wrote:

I still think this is only a performance problem

... But it doesn't, it only affects the spiro's path, and it always affects the spiro's path. And never the other paths.

And the "other" paths have as many nodes as the spiro paths you create? I don't know the answer, but as I said earlier, spiro paths are just normal paths in a spiro shape. If the problem only effects spiros then you have to start looking at what is different between the spiro paths and the other paths to identify why spiro paths behave differently--the number of nodes could be one such difference or it may be related to how the path loops over itself.

...or it may be related to how the path loops over itself.

How might the path looping over itself affect its snapping behavior?

Because if the number of nodes is affecting performance, so that it doesn't snap, how is it that the end nodes of open paths, even with over 1000 nodes, snaps properly. But none of the other nodes can snap?

Still engrossed in the Spirograph Effect....
I've noticed what I think is more interesting info. It may be that I just can't comprehend these things, that they're just over my head. But anyway, in my last update, I reported that I had noticed that closed spirograph paths snap as expected, but open ones do not. So now it happens I have taken a non-closing spirograph path, and closed it. But closing it did not make it snap properly. Here are some visuals along with the details.

This is the original spirogram:



Here is a close up of the 2 open ends (thumbnail because it's somewhat large):



The blue and hot pink arrows show the 2 open ends. The hot pink end I deleted back to the vicinity of the red arrow. Then I copied the missing segment from one of the neighboring segments, and joined the nodes on each end, to the original.

And the result:



So using a simple rect object to test the snapping, I find that all 4 corners of the rect snap to the end of the new segment I created, which I connected to the original open end at the blue arrow (using Join endnodes with a new segment). But snapping does NOT happen at the other end of the new segment (near the red arrow) (on this end it worked better to use Join selected endnodes), or to either original open end.

Isn't that weird? To me, this is totally inconsistent with the other samples I've provided. I don't know. Given the snapping in this case happens to the new segment (which probably has around 10 nodes), maybe that does speak to the looping of the 1000+ noded spirogram? But then why doesn't the node where I connected the other end of the segment snap?

Any comments? Does this new info point to any answers?
Thanks for your continued attention to this ever-lengthening thread

Hi Brynn,

If a path has more than 500 nodes, you won't be able to snap to it. This limit is being enforced in the object snapper to keep Inkscape responsive, because snapping can be very stressing for your CPU as you've already noticed.

I think I've asked before, but are you using the latest SVN build? Probably you are, because you mentioned the instability

Nice spirographs btw!

Diederik

Aaaaaahhh, finally!
Thanks for taking the time to answer this issue, dvlierop.

Honestly, I haven't noticed snapping affecting cpu use, although loonquawl has. For me, though I do get a strong cpu spike with just the cursor moving across the canvas. So if more than one action causes the cpu to jump, it's hard to tell exactly which one is stronger or weaker.

No I'm using 0.46, the last stable release. Yet Inkscape crashes a LOT when I use the Spirograph Effect. Some of it may have to do with the size of files, because a single spirogram, 1000+ nodes kind, can tax the system. I've noticed if I'm very careful about the number and size of paths I put in a single file, it doesn't crash as much. But I get to be so engrossed in making them, I can easily fill a huge canvas in just a few minutes!

Anyway, I'm glad to have an answer to this mystery now. I guess I will have to do a lot more with layers, then, as I work with these images. Because without snapping, it will be hard to properly fill so many little diamond shapes using the paint bucket tool.

So a final huge THANKS, dvlierop, and to everyone who has followed and replied to this topic. I really, truly appreciate ALL the comments!

Best to all!

Well, you didn't notice this yet probably because your pc is not that old and because you didn't try moving a 499-node object over another 499-node object .

You're the first one reporting this issue, so so far no one ran into this yet or they didn't care. Thanks for your posts though, the Inkscape community needs people like you! Please keep posting your experiences and keep reporting bugs!

Diederik

You're the first one reporting this issue, so so far no one ran into this yet or they didn't care.

Or like microUgly and loonquawl, they thought there might be some logical explanation

Thanks for your posts though, the Inkscape community needs people like you! Please keep posting your experiences and keep reporting bugs!

Oh my goodness, you are so very welcome!!
I've given a great deal of thought to teaching myself how to write Inkscape code, and join the developers. But because of health issues, I don't think I could accomplish such a goal, at this time.

But I get SO much enjoyment and pleasure from Inkscape (which is invaluable in keeping a positive outlook in the face of these health issues) I feel compelled to give whatever I have to offer, to the effort to build Inkscape. And as it happens, I tend to be detail-oriented, which lends itself quite well to noticing inconsistencies and illogical behaviors in the program...all from a (new) user's perspective, of course.

However I will quickly admit that while I might like to think all my reports are so selfless, the truth is that mostly I report problems out of personal frustration, as I struggle to learn to use Inkscape, lol