3 Replies Latest reply: Jan 4, 2013 1:28 PM by JD_Mortal RSS

    Points not obeying grid-snapping, or any snapping-rules where merged.

    JD_Mortal Community Member

      This is my situation.

       

      1. Draw a line... It snaps to grid perfectly.

       

      2. Draw another line... It snaps to grid perfectly.

       

      3. Merge line1 with line 2 at one end... (It seems snapped to grid, but shows a "+" protruding connection so I zoom, and it is fine close-up...

       

      4. Move the point to a new grid-snap point to see if it draws better zoomed-out 100% without showing overlapping on this single point... However, now it snaps everywhere except onto the grid. Like all around the point, just not on the point. Now it will no longer snap to any grid-point or other point, always being "off". (This does not resolve by adding a new point and breaking the line. The whole line now refuses to snap to any actual point. It is always offset by an unsteady ammount/percent. Sometimes it is real close, sometimes it is about 50% between all snap-points.)

       

      Resolution = None... Never move points once set, and naver intersect a third line to a point, and never intersect one line with another.

       

      Results... everything looks misaligned, slightly off-angle, can not make any true aligned items, unless I use line-thickness 3, to hide the off-angles from misaligned points.

        • 1. Re: Points not obeying grid-snapping, or any snapping-rules where merged.
          kglad MVP

          i don't see a problem.

           

          make sure you actually merge your line segments by selecting both and clicking modfiy>union.

          • 2. Re: Points not obeying grid-snapping, or any snapping-rules where merged.
            JD_Mortal Community Member

            There is no such option (Modify->Union)...

             

            There is (Modify->CombineObjects->Union), but it is grey... {Selected point}, {Selected line}... Still grey.

             

            The line-segments are JOINED. There is only one point that moves both lines.

             

            Testing...

            1. Create a line.

            2. Create another line over that line. (Intersection AUTO-JOINS {Unions?})

            3. Make sure your grid is ON, and GRID-SNAP is on.

            4. Delete ONE of the four lines, so only three lines connect to that point. (Same thing as joining one line to the middle of another.)

            5. Try to move that POINT where your remaining three-lines/segments connect. {It will not snap to a grid-line. If it does, you got ONE to work, try another. You got lucky, or you are not zoomed-in enough to see the actual error, or your grid is too large or too small, seeming like it is snapped.}

             

            Grid = default 10px

            Project settings: 72 PPI, 24FPS, 1280x720px resolution.

             

            Issue would be resolved easily if you could manually adjust points X:Y positions, like you can for lines and objects. Or if there was a simple "Join/Snap", or even a "Join", without going through the menu to dig-up a specialized, "only works in certain situations" option for creating a Union.

             

            I don't want to do this to the millions of intersections I have. Yet, I must, and it doesn't function correctly. Makes ME look like I am a sloppy artist, with no resolution.

             

            Don't worry, I am getting use to Flashes many annoying limitations and quirks, and going to external programs to do the real vector art. Luckily, it imports others work better than it imports and manages its own vectors. 6 versions, and the few things the actual artists ask for, get rejected for code and novelty that doesn't even work. Great to see the support my money is paying for, is used to make excuses and thwart the actual issues.

            • 3. Re: Points not obeying grid-snapping, or any snapping-rules where merged.
              JD_Mortal Community Member

              This is what is happening, at a programming level...

               

              Once a point is "merged/union", at the intersection. That point it is now located, becomes an offset to the actual "Grid". However, (for some reason only on intersected lines), the offset interferes with snapping. It will SNAP, at your grid-distance, at a slight offset, never on the actual intersection. It starts to "snap", as if the grid is offset, staying on the lines, but invisible lines that are not the grid.

               

              The only resolution to get the line to go back to the grid, is to use the arrow-keys to bump it the 5.0-0.1 pixels it is off. (In my case with a 10px grid.)

               

              However, moving the point again, causes it to start snapping to the phantom-invisible grid-lines, and it will have to be nudged with the arrow-keys to push it back to an actual grid location.

               

              Also, however... This does nothing to resolve the zoomed-out view which shows top-left intersections displaying as a "+" when they are truly intersected. Also noticing that the lower-right lines alwys seem "open", not connected. (Drawing a standard rectangle with a line-width of 1px shows the "open" bottom corner.)

               

              Somewhere in code, there is an issue with drawing. Zoomed-out it is drawing "top-left" of pixel-locations, but zoomed-in, it is drawing from the "center" of the pixels. Thus, this akward offset, which is always top-left offset, and causing what seems to be "holes" on the bottom-right of intersections.

               

              (Might be a direct-x thing, becuse MS draws/calculates from top-left. GL draws from center. Most software draws bottom-right. Due to copyrighted "formulas" for drawing.)

               

              I suspect antialias may also be interfering with the drawings, as it completely messes-up curved-rectangles, making them look bowed-out not curved on the corners. Again, someone is using a GL formula for a MS translation, or software-formula for MS translation, not using the off-set adjustment to match the middle-draw to the top-left draw code.