Jump to content

  • Log In with Google      Sign In   
  • Create Account

lumberbunny

Member Since 15 Jul 2009
Offline Last Active Jun 19 2013 02:15 AM

Posts I've Made

In Topic: Fly from one camera to another

22 April 2013 - 09:31 PM

I think Rectangle and Hodgman have pointed out the inherent problem with splines: that given the right endpoints, they can produce some really acute turns up to and including pivoting on a point.

 

Like I said, I want constant forward speed with only gradual turns. Think of the camera as having momentum in the direction it is facing and that the only forces that can be applied are centripetal (and those have a maximum magnitude). This way, the camera will never speed up or slow down but will change direction to match the desired end condition.

 

To make it explicit, I'll use Rectangle's example where the start and end cameras are at the same position but with opposite orientations. The solution I imagine would probably look like a car turning around in a cul de sac.


In Topic: Fly from one camera to another

22 April 2013 - 02:11 AM

For parameters like FOV, you'd just lerp them using the fraction. For rotation, you can just slerp them using the fraction.
For position, you could also just lerp them using the fraction, but this would move in a straight line between the two. If you want the camera to move forwards in a curving arc, you could define a spline using the two positions, and the two forward vectors as the tangents at those positions.

 

This is the part of the solution that eludes me. Yes, I could define a spline to lay out the path of motion, but if at the same time I SLERP the rotation, the two will be out of sync and the camera will not appear to be moving forward. I could instead use the derivative of the spline to determine the forward direction of the camera, but there would be nothing to indicate the associated roll. In either case, how would I limit the curvature of the spline and regulate the speed along it?


In Topic: Fly from one camera to another

22 April 2013 - 01:12 AM

That will move from the 1st camera to the 2nd in a straight line, which is not what I want. I want the camera to always move forward but turn gradually to reach the eventual position and orientation.

 

Suppose that there's a Camera class with Position (Vector) and Rotation (Matrix or Quaternion)

 

The first part of the update should be something like:

camera.Position += Speed * camera.Rotation * Vector.Forward 

The next part needs to change the camera rotation (within the limits set for speed of rotation) so that in subsequent updates it will reach its destination and be at the appropriate orientation when it gets there.

 

It would be ideal if the only information needed was the current Camera and the destination Camera, but it would also be okay to calculate a path from Camera1 to Camera2 and step along it, so long as the speed requirments can still be met.


In Topic: Where should I start learning about Finite Element Method?

19 July 2009 - 08:53 PM

Quote:

There is a lot of info out there on Google and plenty of books, but none seem geared towards video games (or real time visual simulation).


You'll be hard-pressed to find any literature on real-time FEA. Even basic FEA involves solving sets of simultaneous equations which is very computationally demanding and so poorly suited for real-time applications. Usually these systems are linear such that all displacements and rotations are accurate only within very small ranges. Additionally, FEA is primarily used for static loading, meaning that nothing is moving and nothing is changing--which would make for a very boring game.

Any or all of these limitations can be overcome provided that you're willing to invest enough time in the project, although there are certainly much simpler and more efficient ways to accomplish the tasks you've listed. However, if you still wish to proceed:

To get started, you'll definitely need to brush up on your linear algebra. (Variational calculus is used to derive the finite element equation, but is not required to use it.) Specifically, the matrix you'll be reducing--called the stiffness matrix--is always positive definite so a Cholesky decomposition can be very helpful when you need to solve the same system under many loading configurations. Basically, you solve for the displacements u of a set of points by employing Hooke's law for whatever material it is you're trying to model.

As an example, let's consider the beam you mentioned. Here is the theory reference for ANSYS, a powerful commerical FEA program. On page 14-2, you'll find the stiffness matrix for a single element of said beam. Hooke's law says that the stiffness matrix K multiplied by the displacement of the beam always equals the forces that you apply.

[K]u = F (I'm using [ ] to denote a matrix and italics to mean vectors.)

Now, all you must do is solve for u using all that linear algebra you've learned. When you start adding more than one element, the displacements and resultant forces of each beam element must be rotated to the global coordinate system from the local coordinate system used by the stiffness matrix.

PARTNERS