Jump to content

Ben

Moderators
  • Posts

    1,982
  • Joined

  • Last visited

Everything posted by Ben

  1. This will be because all angles are represented internally as radians. We then convert them to degrees using a*180/pi. That leads to a small amount of error in floating point precision. The error is small enough not to matter in real terms. In this example - the angle is not about the circle, but the arc start/end when presenting a pie shape. As Walt also says - we use cubic bezier quadrant approximations for a circle/ellipse - so there is an element of error in the outline compared to a mathematically true circle.
  2. @Pšenda This is not the issue. We have all the checks possible to allow saving files to any storage medium (in fact, more than most software). The issue lies in the way that USB attached storage buffers data to later be written to physical storage. We will have finished writing the file with no error messages coming back from the Operating System. The *actual* write to the physical hardware happens at a later time that is out of our control - there is additional management of the hardware performed by device drivers, etc. This is one of the reason why you MUST dismount external drives BEFORE disconnecting them. We rarely (if ever) see these kind of corruptions happening on local storage, and that is why we advise people to work on local storage (which is also faster). Attached storage is good for duplicated backups, and we recommend that also. If a file fails to write during our saving process, we have checks and mitigation for that - as well as disconnected network shares, changes in access/permissions, out of space, etc. What we have no control over is what happens to the file after the saving process completes.
  3. If the start of the file has been overwritten with zeros, then it will be missing vital data and can't be fixed.
  4. We don't snap between geometry, only bounds of an object. The exception is for points when using the Node tool, or positioning the corner of an object bounding box. You can use the Node tool, and snap a guide to the nodes and handles of the currently selected curve objects. I think you only need to select the object, not the individual handles for that to work. (off the top of my head I can't recall if I added this for 1.8 or if it's already in 1.7). I could add snapping of guides (conceptually any infinite line) to curves in an object, BUT that snap could potentially have many potential targets. To now, people have been happy with snapping to bounds.
  5. I have a whole load of ideas for making the procedural functions better. The full vision is going to take a lot of work though, so it might not happen for a while yet. I had thought about samplers, gradients, etc, as well as a visual way of building the functions.
  6. Thanks for your help with this bug. We have now resolved the problem and will make the fix available in the next release of Affinity Photo on your platform.
  7. ok. There is a bug - it'll get fixed soon. It's got nothing to do with integers - it's to do with optimisation of the "(R*R)-T" pattern in the equation.
  8. Sorry - another thing to note. The Fit To Plane method works best when you adopt a Cube based grid. That allows us to calculate the correct scaling we need to apply. That is because the axis lengths are determined from a single scaling factor applied to the cube. If your grid is made using the Advanced Grid option (with Two Axis Custom), then it will generate an incorrect scale in one axis - leading to a shear effect like you are seeing.
  9. That's because we do not currently use true ellipse representations. That will come at some point. What you have is your original circle shape with an applied SSR transform. The SSR effect does just that - it takes your 2D geometry and applies the Shear, Scale and Rotation to put the object into to projected system. The ellipse method you are describing attempts to put a non-sheared ellipse in 2D space directly into position to appear as a axonometric projected circle, by applying a rule that produces a good enough projection of a circle (incidentally that approach is also not very accurate, but that's another discussion). It's not the same approach. Our approach attempts to maintain the original objects editablilty in terms of the original object. If you take a shape and project it, you'll still be able to adjust the shear and rotation as a continuation of the initial SSR transformation. Our approach also applies to any axonometric axis set. The isometric approach you are describing only really works well for isometric. You'd need to get into a lot more maths to apply it to arbitrary axes.
  10. Thanks for your help with this bug. We have now resolved the problem and will make the fix available in the next release of Affinity Photo on your platform.
  11. Standard rotation convention is that a positive rotation rotates away from the primary axis towards the secondary axis (conventionally X towards Y) - so a 90 degree rotation will take you from the X axis to the Y axis. This understanding becomes more relevant as you add more axes. Clockwise/anticlockwise are all dependant on the handedness (is that a real word?) of the coordinate system and the method of projection to the visualisation plane. It is true that we are not representing the rotation correctly in Affinity. Our logical axis (as the user perceives) points right (X) and down (Y), yet our positive rotation behaves as though our Y is up. This is something that may well get addressed in the not too distant future (no promises on time). It crept in due to the different behaviours expected from different people when dealing exclusively with either vector or raster content.
  12. The short answer is - to improve performance overall, you'll first want more memory and good size (and faster) primary storage. A faster CPU is also beneficial, but sometimes the higher spec ones won't offer the equivalent performance benefit relative to the price difference. Generally, you'd want to balance the spec of all three anyway - it'd be pointless having the fastest CPU with the minimum memory. Annoyingly, the option of upgrading memory later is being hampered in some machines (and often 3rd party memory is a lot cheaper). We make use of primary storage quite a bit to store bitmap data, and document data, and scratch files for document saving - so a fast hard drive is a must. Then there's GPU performance...
  13. How about also providing the examples of what freezes the app so that we can improve the performance? Snapping is now threaded, and also should time out - but there will be certain permutations that still require the time out test.
  14. You have to understand that cloud storage (whichever brand) is NOT a backup. It is not a safe version of a file stored at some specified point in time. If your local copy of a file becomes broken, for whatever reason, cloud storage will propagate that to all other instances you have, including the server side copy. For this reason you should not view cloud storage as a mechanism to protect historic versions of your files. A backup has to be an intentionally created duplicate copy of a file at a given moment in time. You do not work from a backup - you hold it only for the purpose of archiving know versions. It needs to remain safely separated from your working copy. Cloud storage fundamentally does not achieve this. Some cloud storage system suggest they offer some form of versioning. I'm not sure about the quality of that over a system tailored for the job.
  15. We just need to have a look at the command and see if it can't be applied to multiple layers in one go.
  16. Because you were never snapping to these things. The thing you were actually snapping to was/is obstructed by the selection box handles. If you had two circles on screen - one selected and one not - you would be able to snap a guide to either of them. So seeing the selection box on top of the one circle gives you nothing (other than the visual cue that I mentioned). This is what is meant by visual clutter - UI devices that serve no purpose while an action is taking place. All the handles are there until you drag one to start an action - they then become redundant. For this reason we also offer the option to hide the selection box while transforming objects - because people want to see the document contents while performing actions, not the UI overlay. Yes - in 1.6 we didn't hide the selection box when moving guides, and in 1.7 we now do. That has changed - along with a raft of other major changes in 1.7 to how most of the tools work. All very carefully thought out, and intended to improve usability. I also don't understand what you are saying about having to zoom in to snap things more accurately...????? The whole point of snapping is that it will give you the exact same position regardless of zoom level - if the snapping result shows the snap, the position will be accurate. If you are zooming in to position things, you are not snapping at all. It appears to me that you are fundamentally misunderstanding a lot of how things are working in reality, and have come up with a set of technical superstitions that you are now struggling to shake off. You need to re-read my explanations above - they are correct.
  17. Seriously - I wrote the snapping system, so I can say with 100% confidence that we NEVER snapped to the control handles on the selection box. You were either snapping to the key points on the ellipse circumference, or the mid line of the bounding box of the shape. You can still accurately snap to these positions. That is no different - so I am not sure what it is you cannot do exactly. If I drag out a new ellipse - I can still snap to those key points, and the bounding box and midline. Just as accurate, and still works perfectly fine as far as I can see. When you talk about drawing accurately - the snapping system is still as accurate as it ever was - in some places 1.7 is more accurate than 1.6. Provide a video or something - I think your problem is your understanding of how snapping is working or how you are trying to use the tools. Who else has "confirmed" this bug...? Your explanation so far just indicates that you were using the selection box handles as a visual cue - whether you understood that was what was happening or not.
  18. It's probably always been done like that because defining the rules for how this behaviour would work in terms of the UI and the back-end logic are both very involved.
  19. Unfortunately, the functionality you'd need for achieving this is not as straight forward as you'd think. The knockout effect actually works in the opposite order of the layer drawing. We generally apply effects downwards through the draw stack (layer order) - where as in my example, the red line would need to knock out the black stroke on the yellow line which would need to appear higher in the draw stack.
×
×
  • Create New...

Important Information

Please note there is currently a delay in replying to some post. See pinned thread in the Questions forum. These are the Terms of Use you will be asked to agree to if you join the forum. | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.