# dmounty

Member

483

122 Neutral

• 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. ## Calculating 2D texture coords from a 3D point in a polygon

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 :)

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. ## Moving a triangle forward in OpenGL (win)

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. ## Scrolling Background Help C++ and SDL

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.