SpaceCraft_ToDo - ProkopHapala/SimpleSimulationEngine GitHub Wiki

See SpaceCraft combat simulator project

Numerical accuracy on GPU

• Projective dynamics solver of linear system $A {\vec p}={\vec b}$ is not sufficiently stable on GPU in single precision float.
• This is because we substract large similar numbers $\sum p_j k_{ij}$
• we can solve this by searching just for displacement $\vec d = {\vec p} - \vec p_0$ from some reference position $\vec p_0$
• This means solving system $A \vec d = b - A {\vec p}_0 = {\vec r}_0$
• We can simply calculate resudual right hand side ${\vec r}_0 = {\vec b} - A {\vec p}_0$ on CPU in double precision
  • ${\vec r}_0$ as well as ${\vec d}$ are expected to be small
• Then we solve $A {\vec d} = {\vec r}_0$ on GPU in single precision float arithmetis using some higly paralelizable solver such as Jacobi or Gauss-Seidel.
  • We can accelerate both Jacobi and Gauss-Seidel by momentum (or Chebyshev) acceleration.
    • Momentum acceleration $x_k=y_k+\beta v_{k-1}$ where:
      • $y_k = J x_{k-1}$ is result of current Jacobi (or Gauss-Seidel) iteration ( i.e. matrix J represent the application of one Jacobi or Gauss-Seidel iteration step)
      • $v_k = x_k - x_{k-1}$ is momentum from the previous iteration
• When we calculate $\vec r_0 = \vec b - A \vec p_0 = \vec b - \vec b_0$ on CPU it is simple, but inefficient. We can further increase performance if we calculate it on GPU, however naieve explicit evalution of both $\vec b$ and $\vec b_0$ independednly is inefficient.
  • Instead we can use error cancelation when calculating $b_i - b^0_i = \sum_j( b_{ij} - b^0_{ij} )$ together. We can substitute for the definition of both:
    • $b_i = \sum_j k_{ij} l^0_{ij} h_{ij}$, where $h_{ij}=(p^0_j-p^0_i)/l_{ij}$ is normalized direction between points $i,j$ and $l^0_{ij}$ is the rest length of the edge connecting the points.
    • $b^0_i = \sum_j k_{ij} p^0_j$
    • $b^0_i - b_i = \sum_j k_{ij} ( p^0_j + l^0_{ij} h_{ij} ) = \sum_j k_{ij} p^j_i$, where $p^j_i$ is position of particle $i$ which would optimize bond $i,j$.
    • we can define small displacement $s^j_ij = p^j_i - p^0_i = p^0_j + l^0_{ij} h_{ij} $

Better sliders

• Current sliders seems to deform wheels (introducing considerable strain)
  • this seems to be bacause they are not placed accuractely enough respecting the wheel radius
    • This is perhaps also because the anchor points are in vertexes, rather than in the middle of edge
      • we should make popper anchor-points which are placed accurately and connected to the girder by sticks

Truss Generation

• Make generator of the parabolic antena or plazma nozzle
  • it should originate from tiangular (hexagonal) grid ( i.e. triangle-fan, where each triangle is patch of smaller trinagles )
• Make triangular plates with support truss, in varuous shapes
  • triangle
  • rhombus
  • trapezoid
  • hexagon
  • circle (or any other sooth curve (with cutted edged)
• Build Girder-truss from simple skeleton rather than independend pieces welded together

New Truss builder

• The problem of old spacecraft truss-builder used with Lua EditSpaceCraft.h is that the girders are not firlmy attached to central node in all degrees of freedom (bending, torq) and they wiggle.
• We have new way how to build truss in ConstructionBlock.h
• SpaceCraft.h and BlockBuilder in ConstructionBlock.h are functionally equivalent and should be merged together. In particular these are node-points connected by sticks.
• Howe ver the problem is that the Nodes in SpaceCraft.h are dimension less an does not hold structure (like attachement points). Nevertheless thiscan be corrected by searching for nearest attachemen faces byt direction vectros of the edges

Unify Mesh strcutures

• We have really man Mesh Drawing functions (duplicating the code)
• The final Mesh class should be MeshBuilder2.h
• We copied functionality for UVdrawing from DrawOGL3.h and from Draw3D_Surf.h into DrawUV.h
• All the other mesh builders and drawing classes should be gradualy eliminated