simulation - 就尺寸和质量而言，是否可以进行逼真的n体太阳系仿真？

Question

重要说明：这个问题与“ PhysX”完全无关，后者是一个计算机游戏物理系统（用于诸如球类游戏等街机游戏中的物理）； PhysX是Unity3D和其他游戏引擎的内置系统。 PhysX与此处完全无关。

//////////////////// UPDATE（先读底）///////////////////////

我一直在记录值并搜索确切的问题在哪里，我想我找到了它。
我的代码中有类似的内容

Velocity += Acceleration * Time.deltaTime;
position += Velocity * Time.deltaTime;

加速度现在大约是0,0000000000000009 ..随着代码的流动，速度会按照预期的速度增加，浮子没有问题。
但是在开始时，地球的初始位置是（0,0,23500f）您可以在我最后给出的图表中看到这一点。

好吧，现在当我将速度* timedelta（此时约为0,00000000000000005）添加到23500的位置时，基本上不会添加它。 position仍然是（0，0，23500）而不是（0,0，23500.00000000000005），因此地球不会移动，因此加速度不会改变。

如果我将地球的初始位置设置为0,0,0并仍然将加速度设置为0.0000000000000000009以假设其位置为（0,0,23500）
然后，它“添加”速度* timedelta。
它变成（0,0,000000000000000000005）并保持增加。当float为0时，添加如此小的值没有问题。但是，如果浮点数类似于23500，则不会将小数值相加。

我不知道这到底是统一的问题还是c＃的浮动。

这就是为什么我不能使其以较小的值起作用。如果我能克服这个问题，我的问题将得到解决。

///////////////////////////////////////////////////// //////////////////////////////

我一直在开发n体物理模型来模拟我们的太阳系，所以我一直在收集数据以使其尽可能逼真。但是数据大小存在问题。我搜寻了互联网的每一个细小部分，却找不到一个能解释人们如何克服这一点的单一解释。 （如果他们这样），所以我在这里尝试射击。

因此，为了保持行星之间的距离，半径和“质量”之比固定，我创建了一个Excel文件来计算所有数据。 （因为为什么有人会把“如果地球上有“那个”半径图”放到地球上，那将是什么？）
我将把ss作为附件。它从根本上“标准化”或换句话说“缩放”行星的每个属性到给定的参考。在这种情况下，我将其称为“地球半径”。

我团结一致，您知道，不能统一使用“太大”或“太小”的价值观。所以我不得不将太阳系缩小，“很多！”

所以我用牛顿万有引力定律F = GMm / r ^ 2
为了简单起见，我直接针对所有其他物体的给定物体计算a = GM / r ^ 2。

因此，地球引力加速度“朝着太阳”的真实值大约为0,000006 km / s ^ 2，这即使是一个很小的值，也可以统一使用，但它可以起作用。但是，要获得该值，1我需要将地球的半径（比例）设置为6371单位，将太阳的比例设置为696,342 !，这太大了，无法使其统一。

所以我说，让地球半径为1，以单位为单位。
所以，当半径改变时，一切都改变了，质量，距离...
我保持了行星的密度，并从具有新半径的新体积中计算了质量。
所有计算都在附件中。

因此，当我将地球半径设为1时，朝向太阳的重力加速度变为0,0000000000009
这太小了。当然，Unity不能使用该值。

因此，如果我改为增加地球的半径，那么太阳的质量和半径会变得非常大，然后再一次，我将无法使用它。

我不知道其他人如何解决这个问题，他们如何解决这个问题，但是正如我从这里看到的那样，似乎无法对太阳系进行逼真的n体模拟。 （至少一致）

所以我需要10个代表才能发布图片-_-，我会改为提供链接。
http://berkaydursun.com/solar_system_simulator/data.PNG
还有一个目录是具有n体计算但具有UNREALISTIC值的有效实验太阳系模拟。
它工作得很好，甚至看起来也接近真实，但是不，它没有正确的比率^^
如果您希望 http://berkaydursun.com/solar_system_simulator/，可以在这里进行测试

编辑：哇，我几乎每个段落都以“ So”开头^^

Answer 1

我也做了程序溶胶系统仿真，所以这是我的见解：


渲染

我使用1：1缩放比例的OpenGL。所有单位均以SI为单位[m，s，kg，...]。问题开始于Z缓冲区。通常，Z缓冲区的位宽为16/24/32 bit，这远远超出了您的需要。我正在从0.1m渲染到1000 AU，那么如何克服这个问题？

我确实通过同时结合Z-sorting和Z-buffering的3个平截头进行渲染来管理它（由于透明环和其他效果，Z-sort是必需的）。因此，首先我将最远的部分渲染到zfar=1000AU。天穹投影到z=750AU距离处，然后清除Z缓冲区并渲染对象直至zfar=0.1AU。然后再次清除Z缓冲区并渲染关闭的对象，直到zfar=100000 m。

为了完成这项工作，您必须拥有尽可能精确的投影矩阵。 The gluPerspective has unprecise cotangens，所以它需要修复有关的元素（让我花很长的时间来发现它）。 Z near值取决于Z缓冲区的位宽。如果编码正确，则即使缩放10000x也可以正常工作。我从矿井主视图实时地将该程序用作矿井望远镜:)的对象导航/搜索器。我结合了3D星星，天体，船，真实地面（通过DTM和卫星纹理）。它甚至可以输出红蓝浮雕：)。可以从表面，大气，空间...（不仅限于地球）进行渲染。没有其他第三方库，则使用OpenGL。看起来是这样的：







如您所见，它在任何海拔高度或变焦下都可以正常工作，就像这样atmosphere scattering shader
模拟

我没有使用n体重力模拟，因为为此，您需要很多非常难以获取的数据（以所需的精度几乎是不可能的）。计算必须非常精确地完成。

我改用开普勒方程，请看以下内容：


Solving Kepler's equation
C++ implementation。


如果仍要使用重力模型，请使用NASA的JPL层。我认为他们那里也有C / C ++的源代码，但它们使用的地图与我的地图不兼容，因此对我来说不可用。

通常，开普勒方程具有较大的误差，但不会随时间增加太多。重力模型更精确，但其误差会随着时间而增加，您需要不断更新天体数据以使其正常工作。


[edit1]集成精度

您当前的实现是这样的：

// object variables
double  acc[3],vel[3],pos[3];
// timer iteration
double dt=timer.interval;
for (int i=0;i<3;i++)
 {
 vel[i]+=acc[i]*dt;
 pos[i]+=vel[i]*dt;
 }

问题是，当您添加非常小的价值和非常大的价值时，它们就是
在添加之前移至相同的指数，这将舍入大量数据
为了避免这种情况，只需将其更改为：

// object variables
double          vel0[3],pos0[3]; // low
double          vel1[3],pos1[3]; // high
double  acc [3],vel [3],pos [3]; // full
// timer iteration
double dt =timer.interval;
double max=10.0; // precision range constant
for (int i=0;i<3;i++)
 {
 vel0[i]+=acc[i]*dt; if (fabs(vel0[i]>=max)) { vel1[i]+=vel0[i]; vel0[i]=0.0; } vel[i]=vel0[i]+vel1[i];
 pos0[i]+=vel[i]*dt; if (fabs(pos0[i]>=max)) { pos1[i]+=pos0[i]; pos0[i]=0.0; } pos[i]=pos0[i]+pos1[i];
 }

现在，将 xxx0集成到 max，并将整个内容添加到 xxx1

四舍五入仍然存在，但不再累积。您必须选择 max值，以确保积分本身是安全的，并且添加的 xxx0+xxx1也必须安全。因此，如果一次拆分的数字相差太大，则拆分两次或更多次...


像： xxx0+=yyy*dt; if (fabs(xxx0>max0))... if (fabs(xxx1>max1))...


[Edit2]星


The Colors of the Stars我见过的最好的恒星可视化
Star B-V color index to apparent RGB color所有明星目录均使用B-V索引
Using Stelar catalogs那里也有星名交叉引用链接
Skybox: combine different star data


[Edit3]进一步提高Newton D'ALembert集成精度

迭代积分的基本问题是基于当前身体位置施加基于重力的加速度将导致更大的轨道，因为在积分步骤 dt期间位置发生了一些变化，这在天真的积分中没有考虑。为了解决这个问题，请看下面的图片：



假设我们的身体处于圆形轨道并且处于0度位置。我没有使用基于当前位置的加速度方向，而是使用了 0.5*dt之后的位置。这会增加一点点加速度，从而导致更高的精度（与开普勒轨道相对应）。通过这种调整，我得以成功地从开普勒轨道转换为牛顿D'Alembert用于2体系统。 （下一步是对n体执行此操作）。只有来自不受潮汐影响和/或卫星影响的2个身体系统才可能与来自太阳系的真实数据进行粗略的关联。要构造自己的虚构数据，可以使用开普勒圆轨道和等重力来平衡重力：

G = 6.67384e-11;
v = sqrt(G*M/a);                           // orbital speed
T = sqrt((4.0*M_PI*M_PI*a*a*a)/(G*(m+M))); // orbital period

其中， a是圆形轨道半径， m是体重， M是焦点体重（太阳）。为了使精度保持在可接受的公差范围内（对我而言），积分步骤 dt应为：

dt = 0.000001*T

因此，要放置新的测试主体，只需将其放在：

pos = (a,0,0)
vel = (0,sqrt(G*M/a),0)

当主要焦点（太阳）位于：

pos = (0,0,0)
vel = (0,0,0)

这会将您的身体置于圆形轨道上，因此您可以将开普勒与牛顿D'Alembert进行比较以评估模拟的精度。