   Subract Vector of Lenth X from Vector(A,B) without normalization?
  I am working on a sphere/triangle intersection algorith, so after I intersect the ray(sphere's path) with the triangle, I need to subtract the sphere's radius from the direcion vector to get the position where the sphere colides with the triangle. In obtaining the vector to subtract, Is it possible to do it without normalizing the ray's direction and multiplying it by the sphere's radius? I am looking to get rid of the sqrt if possible.possible?thanks =D   
  Back-stepping along the ray a distance equal to the sphere radius won't (in general) give you the correct collision point.Is that what you're doing? Or did I misunderstand your post?   ;  Yes! exactly. I understand what you are saying. Brain fart =/ lolbut the plan is to use the method described here:http://www.cs.virginia.edu/~gfx/Courses/2003/ImageSynthesis/papers/Acceleration/Fast%20MinimumStorage%20RayTriangle%20Intersection.pdfwhich basically simplifies to:'D() = covert to double    Dim Edge1 As VECTOR    Dim Edge2 As VECTOR    Dim Orig As VECTOR    Dim Dir As VECTOR    Dim Tvec As VECTOR    Dim Det As Double    Dim U As Double    Dim V As Double    Dim T As Double   Edge1.X = D(BX) - D(AX)    Edge1.Y = D(BY) - D(AY)    Edge1.Z = D(BZ) - D(AZ)   Edge2.X = D(CX) - D(AX)    Edge2.Y = D(CY) - D(AY)    Edge2.Z = D(CZ) - D(AZ)   Dir.X = D(RX) - D(OX)    Dir.Y = D(RY) - D(OY)    Dir.Z = D(RZ) - D(OZ)   Tvec.X = D(OX) - D(AX)    Tvec.Y = D(OY) - D(AY)    Tvec.Z = D(OZ) - D(AZ)   Det = Dot(Edge2, Cross(Dir, Edge1))   U = Dot(Tvec, Cross(Edge1, Dir)) / Det    V = Dot(Tvec, Cross(Dir, Edge2)) / Det   T = Dot(Tvec, Cross(Edge2, Edge1)) / Det   'IX.Text = CStr(Edge1.X * U + Edge2.X * V + D(AX))    'IY.Text = CStr(Edge1.Y * U + Edge2.Y * V + D(AY))    'IZ.Text = CStr(Edge1.Z * U + Edge2.Z * V + D(AZ))   'OR   IX.Text = CStr(T * Dir.X + D(OX))    IY.Text = CStr(T * Dir.Y + D(OY))    IZ.Text = CStr(T * Dir.Z + D(OZ))after I intersect the triangle, I need to find the spot where the sphere actually collides. I made a very limited collision algorithmonces that only worked in concave rooms. All I did was test the sphere against all the triangle faces like this://Intersect the velocity ray with the triangle, then//project sphere's radius backwards onto the velocity vectorhypoteneus = (triangle_face_normal * sphere_radius) dot inverse_normalized_velocity_direction)//check if the endpoint of the velocity vector is beyond the limit of where it would hit the triangle planeif(lengthOf((tri_intersection - vel_origin) - (hyptns*velocity_direction)) "<" lenth_of_velocity_ray){ sphere hits triangle, redirect }That was all fine and dandy with 6 concave walls of a box shaped room......but I fear that it will fail epically on a larger scale.I have read this paper many times:http://www.peroxide.dk/papers/collision/collision.pdfbut I still don't understand his method exactly.EDIT- I suppose I could leave these two terms squared and just compare them without using sqrt,(tri_intersection - vel_origin) - (hyptns*velocity_direction)^2lenth_of_velocity_ray -> velocityray^2but that still leaves me having to calculate and normalize the triangle's normal for each triangle =([Edited by - CPPNick on May 10, 2010 1:28:41 PM];  So basically:Let spheres velocity = AB  sphere's velocity direction = D  (Dn normalized)  sphere's radius = r  triangle's instersection = I  triangle's normal = Nif( ((I-A) - ((N * r) • -Dn) * D)2 < (B - A)2{  //sphere collides with triangle}this means that I have to store, and rotate or recalculate the normal for each triangle for each frame, and also normalize the sphere's direction each frame.Isn't there an easier way to do this?EDIT:after re-reading the collision paper from peroxide.dk again, I am starting to understand what he is doing there. I also realized that just because the sphere's velocity ray doesn't hit the center of the triangle, it doesn't mean that the sphere itself wont hit the inside of the triangle:so this means that we should be checking for collision between the(sphere's center - (sphere's radius * triangle normal))I could still use a little help on this though[Edited by - CPPNick on May 11, 2010 12:26:19 PM];Quote:I have read this paper many times:http://www.peroxide.dk/papers/collision/collision.pdfbut I still don't understand his method exactly.I think the best advice I can offer is to continue to study that paper (as well as other references that cover this topic, such as those by Dave Eberly), and see if you can figure it out. If it's still not making sense, post whatever questions you have about the algorithm here, and someone should be able to help you.The problem, more or less, is that any dynamic sphere-triangle test is going to end up looking *something* like what's described in the Fauerby paper. There are various different ways the test can be expressed (see some of the recent threads on this topic for some examples), but however it's done, there's a minimum amount of work that has to be done in order to determine whether (and when) there is an intersection. In other words, there aren't really any 'shortcuts' (not that I'm aware of at least) that will allow you to simplify the problem to any significant degree.There is continuous GJK, which has a different flavor than some of the other methods. I haven't implemented this method myself, but I get the impression that it's not exactly trivial. GJK has the advantage of genericity, but IMO, it might be overkill for this particular problem.The more 'traditional' solutions will all look somewhat similar (IMX, at least), and involve doing the same work in one form or another, more or less. The Fauerby code kind of brute-forces it (IIRC), and tests against all of the triangle vertices and edges if there is no collision with the interior. A more sophisticated implementation will only test against specific features as necessary (e.g. as determined by examination of the relative configuration of the test segment relative to the Voronoi regions of the triangle).Quote:this means that I have to store, and rotate or recalculate the normal for each triangle for each frame, and also normalize the sphere's direction each frame.As for this, normalizing the sphere's direction each frame should not be an issue. Also, if you have a decent broad phase in place, any per-triangle work that you have to do (e.g. rotating the normal) shouldn't be an issue either. (In other words, if it's performance that you're worried about, I recommend getting it working first, and *then* worrying about performance.)   ;  ok, thanks for the feedback.Quote:In other words, there aren't really any 'shortcuts' (not that I'm aware of at least) that will allow you to simplify the problem to any significant degree.thanks for this..I know the edge test is done with a quadratic formula, and intersecting a ray with a cylinder. I would have never thought of that on my own, so I wanted to make sure I wasn't missing anything here.I'm found an hour long video about the GJK algorithm, which I have never heard of before, Unless I learn something substantial from it, I will just go ahead and make the thing work =)(the video)EDIT - wowzers...I don't know where this dude gets off calling 52 minutes of explanation simple, but I think Ill stick with regular collisions lol[Edited by - CPPNick on May 11, 2010 1:59:02 PM];  Great video, thanks for posting it   