meta user
network profile
| bio | website | typeandflow.blogspot.com |
|---|---|---|
| location | Brandon, Canada | |
| age | 22 | |
| visits | member for | 2 years, 6 months |
| seen | Oct 21 '12 at 6:10 | |
| stats | profile views | 20 |
|
Feb 10 |
awarded | Yearling |
|
Sep 4 |
awarded | Popular Question |
|
Jul 19 |
accepted | Optimizing gravity calculations |
|
Jul 18 |
awarded | Popular Question |
|
Nov 9 |
awarded | Nice Question |
|
Nov 4 |
comment |
Optimizing gravity calculations This is fundamentally what I'm doing. After I get all pairs involving X, I don't iterate over X again. I find the force between X and Y, X and Z, etc, and apply that force to both objects in the pair. After the loop completes, the ForceOfGravity vector is the sum of all the forces, and that is then converted into a velocity and new position. I'm not sure that the gravity calculation is particularly expensive, and checking if it exceeds a threshold first wouldn't save a noticeable amount of time, I don't think |
|
Nov 4 |
awarded | Commentator |
|
Nov 4 |
comment |
Optimizing gravity calculations Thanks! I may use this :) |
|
Nov 4 |
comment |
Optimizing gravity calculations @JonPurdy that's a good point, but since XNA uses floats natively, I'm gonna stick with those unless it turns out that it's becoming a bottleneck. |
|
Nov 4 |
comment |
Optimizing gravity calculations @SamHocevar Because they still follow geodesics in a gravitational field -- rather than calculating the force on the massless particle (which would result in a non-real acceleration), it just calculates its acceleration using G * m / r^2 (where m is the mass of the massive body). |
|
Nov 4 |
comment |
Optimizing gravity calculations Separating the process into passes is an excellent idea, since the update interval is (as far as I know) a very small fraction of a second. The gravity field texture is AWESOME but perhaps a little beyond my reach right now. |
|
Nov 4 |
comment |
Optimizing gravity calculations I like this idea a lot. I had considered containing the objects in cells, but abandoned it when considering two nearby objects which were technically in different cells -- but I didn't make the mental leap to consider a few adjacent cells, as well as considering the combined mass of other cells. I think this should work really well if I do it right. |
|
Nov 4 |
comment |
Optimizing gravity calculations @chaosTechnician it doesn't have to be very accurate -- in fact if it's only accounting for the few most dominant forces then a system would be more stable, which is ideal. But it's finding out which of the forces are most dominant in an efficient way that I'm having trouble with. Also the gravitation calculation is already approximated, it's just G * m1 * m2 / r^2, where G is just to tweak the behavior. (although I can't just have them following a path, because the user can disturb the system) |
|
Nov 4 |
comment |
Optimizing gravity calculations @Drackir I think you're right. Part of the reason they're separated is because the math is different for massless objects, and part is because they originally didn't obey gravity at all, so it was more efficient to not include them. So it's vestigial |
|
Nov 4 |
asked | Optimizing gravity calculations |
|
Feb 21 |
awarded | Scholar |
|
Feb 21 |
accepted | Understanding DeviceContext and Shaders in Direct3D/SlimDX |
|
Feb 21 |
comment |
Understanding DeviceContext and Shaders in Direct3D/SlimDX Well, I wouldn't use the triangle to build larger objects -- I'd also have a Cube class, etc -- it has a single vertex buffer and a Draw() method which takes the device context. It sets the layout, topology and shaders on the context and then draws all the vertices in the buffer. This isn't good? |
|
Feb 21 |
awarded | Student |
|
Feb 21 |
awarded | Supporter |
