peterbone

Members
  • Content count

    26
  • Joined

  • Last visited

Community Reputation

133 Neutral

About peterbone

  • Rank
    Member
  1. Arc calculation

    Attached is a Windows demo of what I'm trying to do. This is an old version. Drag the green dot to change the line angle and drag with Ctrl to bend it. It will always stay the same length. Notice that the cursor moves away from the end as you bend it, and the end jumps when you go back to bend a bent line. That's what I'm trying to fix. If I get my new method to work with a numerical method then I'll post it as well.
  2. Arc calculation

    ferrous, when dragging P2, the cursor won't always stay on P2 if it's dragged to a different radius. Notice in my diagram that Pc is not at P2. The cursor will be at P2 to start dragging but not necessarily during the drag. This allows the arc to stay circular with a constant length. My app works similarly when dragging a straight line to change it's angle to keep its length constant. This is for a vector graphics drawing / animation app. I want an intuitive way to position and bend constant length lines.
  3. Arc calculation

    That's the nice bit about this technique. If you want to draw e.g. a Bezier curve given the user-dragged point and some other control points, you have to do extra work to calculate the curve.   If you want to draw the curve after having simulated those particles, you just connect the dots. They already form a curve. They form an approximation to a curve. Drawing it requires multiple calls to a drawing function instead of just one for the arc.   I know I didn't mention this previously, but I also need to store the bent line in memory in a scalable and compact way. The arc lends itself to this much better.
  4. Arc calculation

    That sounds like a nice alternative Crossbones. Although I'll have to think carefully about how many particles there should be at different scales and also how to quickly draw the curves from the set of particles. I may need to draw hundreds of these curves per frames, so just drawing an arc may be the faster method.
  5. Arc calculation

    Thanks for your help. Raigan, P2 is unknown. Ferrous, yes r is unknown too. I've already played with Bezier curves but they require even more numerical solutions because the length is not constant. You need a numerical method to work out the length and another to move the control point until the length is the value you want.   I think the way I'll have to do it is to work out the endpoint P2 with no curvature (a1=a2), then work out the angle to the cursor (Pc) from P2, then work out P2 again, and repeat until it converges. I think it will converge quickly this way.   I've already done it a different way where a2 is calculated from Pc and the midpoint of the unbent line. The problem with this is that the cursor leaves P2 while dragging when the line is bent. When you go back to adjust P2 again it will jump to different position.   Edit: I've added an image to my post above.
  6. Arc calculation

    I'd like a user to be able to bend a line by dragging the end. The line will be an arc when bent. The length of the arc (L) needs to stay constant. The other end of the line, not being dragged, is at known point P1 and angle a1, which shouldn't change when the other end P2 is being dragged. The way I want it to work is that the angle at P2 (a2) should be such that that end of the line points towards the cursor when being dragged (Pc). The difficulty is that I can't work out P2 without knowing a2 and and I can't a2 without knowing P2. I have an expression where the only unknown is the radius r of the arc, but can't solve for it because of the complexity. I want to try to avoid numerical solutions. Has anyone done anything like this before? Is it possible to solve for r?  
  7. Arc line calculation

    Thanks Alvaro. I will consider numerical solutions but I prefer the simplicity of a formula. My main reason for posting here was to check if I had missed something in the maths that would lead to a simple formula. It seems that that is not the case, so I will look at numerical solutions.   This is not actually for a game. I'm developing software for creating animations. Objects are constructed from primitives such as lines, circles and images and then moved using pin joints. Bendy lines will be a new primitive. They need to stay the same length because they will be bendy, not stretchy. If a bendy line is used for an archer's bow for example, you wouldn't expect it to change length.   The number of times the calculation needs to be performed depends on the animator. In a complex scene there could be thousands of these arcs needing to be drawn at up to 33fps when the animation is played. I would prefer to do the calculations on the fly.
  8. Arc line calculation

    I know I could use a numerical method, but I'll try everything before I have to resort to that. This needs to be fast.   I've thought about using a quadratic bezier curve, but even keeping them a constant length requires a numerical method to work out the length and another numerical method to offset the control point to get it to the length you want. I thought about using arcs because it's easier to keep a constant length. The constant length is the most important aspect. It shouldn't just appear to be the same length - it needs to be exact.
  9. Arc line calculation

    I'd like to make it possible for a user to drag the end of a line so that it bends in 2D. The line will be an arc when bent (section of a circle). The start point of the line will be fixed in terms of its position and angle/direction. The length of the line/arc will also remain constant. The angle/direction at the end of the line will point to some point P (the cursor position). That should be enough to define the arc fully. However, it seems non-trivial to work out the parameters of the arc. This is because to work out the position of the end of the arc requires knowledge of the radius or angle at the end of the line and visa-versa. If I could just work out the radius the rest is easy.   Here are some relations: angle at end = angle at start + length/radius circle centre is perpendicular to start direction at distance radius from start position circle centre is perpendicular to end direction at distance radius from end position end direction is vector from end position to point P.   I need an equation for radius in terms of the arc start position, direction, arc length and point P. Putting the equations into Maxima to find a closed form solution using 'solve' didn't seem to come up with anything.
  10. I'm looking for 2D coordinates for alpha-numeric characters made from simple polylines in a basic font. I'm most interested in the number characters. I could make them myself but thought that some data like this must already be available somewhere. Does anyone know where I can find this?
  11. Slow software renderer blitting

    This sounds like a good idea enabling me to draw to the off-screen bitmap with the CPU and use the GPU for blitting. How would I go about drawing my bitmap to a texture?
  12. Slow software renderer blitting

    Thanks. This is what I suspected but I'm not exactly sure what you mean by 'opaque'. Does this mean there's no way to write to the DDB data from outside of the device? I assume this means there's no way to write a software renderer that blits quickly. Pete
  13. Slow software renderer blitting

    Someone must know about this. Why can't I access the raw data in a DDB when GDI can. Is it the device that does the actual drawing and GDI is just the interface between the application and the device? Peter
  14. I have written a software rasterizer (a 3D software renderer). I rasterize to an off-screen bitmap by writing to the bitmap scanlines and then blit the bitmap to the screen. The problem is that the blitting is slow because I have to set the pixel format of the bitmap to a 32 bit DIB in order to write to the scanlines - it then has to convert to the pixel format of the device (monitor) when blitting. If I set the bitmap pixel format to device dependant it will blit very quickly but then I can't write to the scanlines correctly - even if my screen colour depth settings are 32 bit. Is it possible to write to the scanlines of a device dependant bitmap without using hardware? The GDI routines in Windows are capable of doing this so how do they do it? Are they using hardware? Thanks Peter Bone
  15. Sphere collision response

    Thanks, that's helpful. A second order equation makes it sound like a differential equation. I assume you mean a quadratic. I guess that after moving the spheres to the computed collision time, the calculation for collision response will be the same as you gave before? If you knew this method, why do you not use it in your code? Just wondering. I'm a bit confused by your code. Where is m_position defined? Should it be m_centre? Pete