Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 16 Dec 1999
Offline Last Active Mar 23 2014 03:26 AM

Posts I've Made

In Topic: Which math classes should I pick from these options:

23 March 2014 - 03:27 AM

I doubt you would ever use any of that as a professional programmer. It's even more doubtful that anyone will hire because you had them. That you have the degree is really the most important thing. A degree actually in computer science is even better. A degree in computer science with a high GPA even better. So take the one's that easiest. It isn't just that it helps you GPA but that none of them are actually easy. Part of what you should be trying to figure out is what are you good at, what you have an aptitude for, what you learn easiest. It isn't taking easy classes, it's pursuing what you excel at.

In Topic: Turn Object around Point

28 October 2011 - 12:50 PM

You have the position and orientation of the object. The position is a translation and the orientation is a rotation. If the object is orbiting a point then you calculate the position with a rotation, but what you get is a translation vector. If you're rotating the object about a point other than it's origin then then you translate that point to the origin, rotate the object, translate it back. Though there's a translation in there it starts and ends at the same place so it's really just a rotation. Generally people use uniform scaling so that's just a scalar. You keep those seperate. So you can have an object rotating as it orbits a point while growing larger and shrinking back with it all being easy to keep track of. You could combine all that into a single matrices, but some of the cells are going to be equations since time is a factor. That would get all nasty and ugly, but simply a vector the position, a matrix for the orientation and a number for the scale keeps things nice and simple.

As your scene gets more complex it helps to break it into a heirarchy. Picture the typical amusement park ride. Oh my God there's stuff going everywhere. These are all orbiting that and the whole group is orbiting this other. If you break it down into a heirachy though each individual piece is simple. That's why you get a standard of view, world and object space. That's generally needed just for a static scene of any reasonable complexity with nothing moving. When things start moving relative to another you start needing to break those object space down into subspaces. You have clown on a golf cart on a cruise ship juggling three balls in the air. If we know where the golf cart is on the cruise ship and where the cruise ship is in the world then we can say where in the world the golf cart is. The position of the golf cart relative to the ship might be somewhat complex relative to the cruise ship, but relative to the world even more so. So you break it down to keep it simple.

In Topic: Right Angle of a plane/rectangle

15 October 2011 - 05:33 PM

Ax+By+Cz=D is the equation of a plane. What you're calling right angles is commonly referred to as normals. (A,B,C) is the normal for the plane. D*(A,B,C) is the closest point on the plane to the origin. If A^2+B^2+C^2=1 then (A,B,C) is a unit normal. A point (X,Y,Z) lies in the plane if AX+BY+CY=D. If it's less than D it lies on one side, if it's greater than D it lies on the other. If D is always positive the less is always closer to the origin than the plane and greater is further away. Three points define a plane, i.e. V1, V2, V3. N=(V2-V1)x(V3-V1) where x is the cross, or vector, product of the two vectors, is a normal for that plane. It may point towards or away from the origin though. If N.V1 where . is the dot, or scalar, product of two vectors is negative it points towards the origin and you should use -N instead. If it's zero it's arbitrary, but it helps be consistant so one rule is it can only lie in four of the eight octants defined by the coordinate planes or is one of the positive coordinate axes. The four octants are the ones sharing edges with two positive coordinate axes. That way there is no uncertainity as to what the sign of the dot product means.

So there you have an equation of a plane defined by it normal and how to find it. Your rectangle is a region within the plane. That can be viewed the same though. Even though the edge is a line the normal gives you a plane. Rather than direction and distance from the origin it's direction and distance from the closests place on the plane to the origin. That allows you to create coordinates within the plane. If it truly is a rectangle then that rectangle is axes aligned within that coordinate plane. So it's just a<=X<=b and c<=Y<=d to see if the point lines in or on the edge of the rectangle. Rectangles are a bit restrictive, but if you just view an edge combined with the normal defines a plane it's all basically the same except the bounds check is a little more complex. You have to check it's on the right side of all the planes bounding the region or lies within one or more planes, i.e. a vertex is in two planes. The restriction then is simply a convex polygon. If it's concave, i.e. there's indentations, then you can be on the wrong side of some planes and still in the polygon. Easiest there is break a concave polygon into multiple convex ones.

Ray tracing a mesh is a bit silly though. Dot products and cross products in three space can do a whole lot as long as it's a flat surface. The advantage of ray tracing is infinite detail for curved surfaces. With curved surfaces you need calculus, specifically derivatives. A fair simple application can expand significantly what you can do, i.e. tori, ellipoids, quadradic surfaces. It's basically the same as above. To do computer graphics of any reasonable complexity you have to use linear algebra and derivatives is no more complex. This plenty to learn though without getting into complex surfaces. Even so eventually you hit a point where the only "more" to do is more complex scenes. When you get there if seems impossible remember there's calculus.

In Topic: Sticky FPS Ellipsoid-Polygon Collision Detection

31 July 2011 - 04:45 AM

You cannot move closer than 1 to the wall, but if you are already closer than 1 then you can't move more than 1 away. If there's as an opposing wall the same is true for it. If you are further than 1 from the opposing wall and less than 1 away from the near wall then you are stuck between two planes 1-d wide where d is the distance between the two walls. If they are reasonably far apart you can move parallel to the wall. If they were, say, a nanometer apart you likely couldn't move. Why? Because you can't steer precisely enough. You have to be within a tiny fraction of a degree of exactly parallel to move.

If you move the player away from the wall, but not far enough it's the same effect. Moving them one little nanometer too little means they effectively can't move at all. Why would you move them one little nanometer too little? Precision error. It should have been move them a millimeter plus what you calculated. That way if you calculate to move them 0.999999999m away rather than 1.000000000m away it doesn't really matter because you'll move them 1.000999999m away and they aren't stuck moving between two planes 0.000000001m apart. That does not solve your problem with edge collision detection though, it just masks it. They should have never been so close they needed to be moved to start with.

Is that number too big? Too small? How would I know? If that's a time it could be a microsecond or a nanosecond depending upon whether 1.0 is a second or a millisecond, or it could be century for all I know. There is a minimum e such that x-e != x. The scale of e depends upon the scale of x. This is floating point, there is no right value. Rather what there is are points in your calculation where you can say you only need a limited precision in real world units. If you only need to be within a mm then subtract 1 mm. It's crude, it works. If 1m is as close as they can get to that object then it doesn't matter if they are stopped at 1.001m. They can't tell a 0.01% differance without instrumentation. Use a value down to the micrometer and then use a sliding vector that's not quite orthogonal and you can end up a micrometer too close and now you're stuck.

In Topic: Sticky FPS Ellipsoid-Polygon Collision Detection

30 July 2011 - 02:12 AM

My first guess would be precision. It should be equal, but it's not. Instead it's just really, really close. An example is

float A = 0.1f;

float B = 0.00003f

float C = A + B;

C -= 0.10003f;
C should be zero, but it isn't.