dmounty

Members
  • Content count

    483
  • Joined

  • Last visited

Community Reputation

122 Neutral

About dmounty

  • Rank
    Member
  1. 2D vector to barycentric coordinate

    So you've got a 2D vector equation in two unknowns? Well that's 2 simultaneous linear equations. You just solve them and you've go s and t. If the point is outside the triangle, the same formula will work (as the decomposition in terms of those vectors is unique). Basically it's just simple maths... write it out on paper (with each coordinate listed individually) and it'll probably become obvious.
  2. Why does this math work?

    Well the solution is pretty obvious. Think about it like this. Setting y to zero just projects the vector down onto the x/z plane. This is necessary to make sure you get the angle in the x/z plane (otherwise the y component being non 0 would affect the magnitude of the z coordinate and hence give an incorrect angle). An obvious example would be if the point was very high. Normalizing would give very small z and x coordinates (hence incorrect values). Now think about the next calculation. The key is, that the pitch is the angle from the x/z plane to the point (effectively). You can imagine, that irrespective of the yaw, the y coordinate of the position would remain unchanged (for fixed pitch). Just imagine the triangle whose angle you are measuring. Look at it in the plane perpendicular to x/z containing your yaw line. That plane defines the triangle you are looking at. Obviously the y coordinate is all that matters. It all boils down to this. In polar coordinates (unlike cartesians) the axis are dependant on oneanother (ie the azimuthal, elevation and r unit vectors are different at any point). This means that you need to be careful when/where you project (when your coordinates are in cartesians). Anyway, I hope this is explain sufficiently well. EDIT: had a sentence in twice
  3. Ellipsoid collision detection

    As people have said, ellipsoid collision detection is not that easy (compared to spheres). Also the interaction of two ellipsoids is not so easy either. You could however fake an ellipsoid by putting a number of overlapping spheres together. Think of your egg example. One large sphere, then move up half the radius place another sphere that's a 2/3rds the radius then move half way up that radius and place another sphere 2/3rds the radius. You'd have 3 spheres embedded in oneanother, whose surface would approximate an egg (for collision and contact parameter purposes. Obviously the more spheres you use, the better the approximation. In fact any figure can be approximated in this way... In essence it's something like a fourier decomposition (in VERY vague terms). The chances are 5 spheres could make collison that would not be noticably different from an ellipsoid; 3 spheres would probably be fine in most situations. I think a scheme like this could work pretty nicely. You could even make a refined version if you needed to... or even use this method as a mathematical starting point to calculate the actual parameters. In any case, I've used schemes like this before and they seem to work well enough.
  4. ok... so let me check I understand you... you have a polygon in world space (and texture coordinates for each vertex) and a point in world space which lies on the polygon? Well... there is one point I need to make. If it is not a triangle, then this is more complicated.. but I'll tell you what to do for a triangle. Imagine it have verticies v0,v1,v2 with texture coords t0,t1,t2 respectively and the intersection point is P. You have to solve: A*(v1-v0)+B*(v2-v0)+v0=P for A and B. Now this requires the point P to be in the plane v0,v1,v2 otherwise an exact solution won't exist. The two options are to project it all into a 2D plane (of the triangle) and solve there, or use an iterative solving method on the 3D case (and get an approximate answer). I'd recommend the projection, anyway... once you have A & B (however you got them)... the texture coordinate of P is simply: A*(t1-t0)+B*(t2-t0)+t0 Easy huh. I hope this is what you wanted. Good luck :)
  5. B-Spline question

    Imagine a cubic spline... in general it's a parametric function in cubic form. You usually define it to run from 0 to 1 (in t) to go from start to end point. Clearly as a cubic there are 4 unknowns... thus 4 facts about the curve must be known in order to define it properly. If you wished... you could solve for a curve that passed through 4 arbitrary points (in some order) but this would leave you in an unfortunate position. The cubic required to pass through those points may extend way beyond the bound box of the points. Secondly (and this is important when you consider a common use of splines) you have no control over the direction in which the spline crosses the start and end points. This means that if you made two splines end to end using 4 points for each to define points they must cross... having them meeting end to end only guarantees spacial continuity... unfortunately the gradient is unlikely to match. This is a very bad thing in general. That is why control points were chosen instead of points through which the curve must pass. They effectively determine the gradient of the curve at the start and end. This gradient control lets you decide (in the case of a single spline) how far and in what direction the spline deviates from a straight line in it's traversal... but more importantly lets you make sure that splines that match start to end can have gradient continuity at the junction (avoiding gradient jumps). Obviously splines can be defined over any set of basis functions, but (as I'm sure you know) any function can be approximated by sufficiently many linear sections... and the number of required sections to define it well decreases with the order of the polynomial. 3rd order is just nice and easy to work with (and is the first polynomial for which you can use this gradient continuity thing). You can imagine that a 5th order splines could let you define a start, end and middle with gradients, but the chances are two cubics end to end (one from start to middle and one from middle to end) would approximate it pretty well. ie higher than 3rd order gives few benefits.. and under 3rd order means you can't ensure gradient and special continuity at joints. Anyway, I'm not really sure I've answered your question.. but I hope this helps :).
  6. closed hulls

    well... a convex hull (which I presume is what you mean) may unfortunately not reflect the geometry of your object very well at all (if it has large concavities). The simplest method would be to make sure all your objects were suitable for your shadow rendering. I guess you could find the boundary edges and triangulate them making a patch to close the object but that could be a bit complicated (possibly multiple boundaries).
  7. I've not actually looked at your code.. but since you said it looks like your not rotating about the centre of the triangle.. then that's probably your problem. If your triangle will rotate about the local origin.. so if your triangle is not defined to have it's barycentre at the origin, then it won't rotate around the correct point. I hope this helps anyway :)
  8. What you are doing seems reasonable.. but your use of one giant image for the background layer seems a little unweildy... imagine you want a world 10 screens by 10 screens (not giant). If that was 32-bit... the image would be 117mb. I think what you'll really have to do (if you want to make a more general system) is have the background built of tiles (like zelda did). That way all your background is built out of tiles. You could place objects in the world tile units (non integers) for a less resolution dependant placement scheme. so to render the world, you draw the tiles within the "camera view" which is just a rectangle in world (tile) coordinates. If you are drawing it all with quads (ie 3d accelerated) you could easily let the view zoom in/out too. As you said though... you need to subtract the camera location from the world coordinates to get screen placement, or... if you are were doing it in OpenGL... actually move the world so it matches the camera, and use coordinates in their current state. As for the placement of object that are on top of the background... if you are using world coordinates and moving the camera, you obviously don't need to do anything special (except obviously only draw tiles/objects that should be visible). Otherwise you need to offset the coordinates to screen coordinates. You could store the world in a quadtree of screen sized blocks (for maximum zoom out) and then you'd only need to check tiles in a limited part of the world for visibility (and hence allow a virtually unlimited world size with virtually no additional performance cost). To be honest I'd recommend you go for the 3D (opengl) approach for drawing. OpenGL works very nicely with SDL and will give you a lot more flexibility. If you do wish to do it in 2D... the maths is just as easy... just get a piece of paper and think about it. You'll find it's not that complicated at all. Tile based backgrounds are really going to be your best bet though (unless you want unfeasably high memory requirements). Anyway, I hope this helps as I think I've been rembling a bit.