PhysX3D is a highly efficient numerical computer simulation which can calculate the gravitational n-body-problem. The n-body-problem is about predicting the complex movement of many particles based on the interactions between each pair of two particles. Every particle does affect every other particle. In the gravitational n-body-problem only the force of gravity is being considered.
The numeric simulation is linked to the most efficient CPU-based 3D graphics engine ever written in Java, which I developed myself completely from scratch. It can display the flight paths, osculating Keplerian orbits, particle groupings, particle velocities, the dynamic gravitational potential and the dynamic warping of space as well as several other graphical extensions like the day-night-cycles of planets in multiple star systems. The graphics engine also supports stereoscopic 3D for 3D monitors or head-mounted displays.
Paths
Velocities
Groups
Calculation Features:
- | Velocity Verlet integrator with adaptive timestepping |
|---|---|
- | 64 bit double precision calculation |
- | CPU multithreading |
- | GPU acceleration for higher particle number problems |
- | simulation data and configuration (settings, units, graphics) is being read from a file system (.txt) |
- | adjustable simulation speed |
- | time and date tracking |
- | collision detection |
Display Features:
- | free camera mode, follow camera mode, automatic counterrotation of camera |
|---|---|
- | stereoscopic 3D rendering for 3D monitors or head-mounted displays |
- | paths |
- | velocities |
- | groups |
- | osculating Keplerian orbits |
- | grid(): dynamic gravity potential visualization with filter for gravity waves |
- | cube(): dynamic visualization of warped space |
- | dynamic visualization of the 3D Barnes-Hut Tree (not used for force calculation) |
- | blooming effect |
- | polygon graphics with dynamic lighting by multiple moving light sources |
- | body rotation about an arbitrary axis |
Initially I developed PhysX3D in Java, including my leightweight 3D graphics engine. However, in late 2017 I traslated the major source code parts into C++, starting with Line3D. I wanted to know which programming language is faster and which additional optimizations could be made in C++. It turned out that Java is extremely well optimized, but in C++ extensions like SSE2 or AVX2 could make the algorithm twice as fast (basically the CPU can calculate several operations as one vector operation). Another big difference is memory management. Java completely lacks the ability to free allocated memory. This means that while the Java version requires up to 500MB RAM, the C++ version only needs a maximum of 135MB, usually about 10MB. Furthermore, OpenCL in C++ provides some extra optimizations like vector data types and explicit memory transfer over the PCIe bus. This way, in the C++ version the GPU kernel runs 30% faster.
The overall numeric performance is indicated by the amount of possible integration steps per second plotted in the diagram below (Setup: Lenovo Y50-70 Laptop).
C++ |
Java |
|
|---|---|---|
| Pros | + more functionality | + simple to learn |
| + explicit memory management | + very well optimized | |
| + better support for extensions like OpenCL | + exactly as fast as C++ in non-vectorizable loops | |
| + more opotions for optimization (for example AVX2) | + much better compatibility across multiple operating systems | |
| + no additional software required | + displaying simple graphics is extremely fast | |
| + console is always available and easy to use for debugging | ||
| Cons | - just opening a window takes more than 100 lines of code | - no explicit memory management, slow garbage collector |
| - pointers are not easy to learn | - much higher RAM usage | |
| - bad compatibility across different operating systems | - arrays are always allocated on the heap | |
| - methods have to be written in the right order or in an extra header file | - requires Java Runtime Environment | |
| - no default console when programming a graphic interface |
| Java | 100% |
|---|---|
| C++ GDI+ | 1% |
| C++ GDI | 33% |
| C++ Direct2D | 58% |
Since version 16.2, the integration is implemented using Velocity Verlet, since it enables the usage of variable time steps and does maintain the total energy and angular momentum. In order to maintain constant simulation speed and to use all the available computational power, the time intervals for the integration vary by size depending on the processors speed. A very effective algorithm (similar to prediction models for next-day energy consumption of large companies) is used for predicting the size of the next time step based on the time the last computation took as well as the last time step. Since I used double variables in Java, the round-off error of 2⋅10-16 makes the error in total energy stay below 10-7. Velocity Verlet itself is a second order integrator and thus produces a global O(t2) error.
The n-body-problem represents a workload which can be parallelized, meaning it can be splitted upon all available processing cores except for one, which is reserved for the graphical output. Thus, running on an 8-core processor the n-body computation can make use of seven cores. Whereas a small number of bodies requires very fast clock speeds and cannot be splitted into more threads than there are bodies, a large number of bodies is a highly parallelizable workload and multi-core processors can be utilized. Parallel threads have to be synchronized at multiple points within each calculation step, so at small body numbers the performance of multithreading is inferior to singlethreading. At large body numbers multithreading becomes superior to singlethreading by a factor of 3.8 on an Intel Core i7-4720HQ. Multi-core processors will benefit even more from multithreading.
Since version 15.3 GPU acceleration has been successfully implemented via aparapi. aparapi is a Java extension which translates the compiled Java bytecode into OpenCL which is then executed on the GPU. In GPU mode the double orbital state vectors are converted into float arrays which can then be accessed in the Kernel provided by aparapi. Only the part impacting performance with n2 is being executed on the GPU and the newly calculated orbital state vectors are returned back to the CPU. At high body numbers the performance is increased by a factor of 113 running on the Nvidia GeForce GTX 960M (1.71Tflops, 640 shader units @1.336GHz) compared to CPU multithreading on the Intel Core i7-4720HQ (0.33Tflops, 8 threads @2.56GHz).
The Nvidia GeForce GTX 960M can handle 54 Billion force calculations per second at 5000 bodies or more. This means that one single force calculation does require roughly 44 floating point operations. In the source code, a single force calculation requires about 33 floating point operations, not taking into account array transfers to the VRAM and back as well as memory latencies. This proves that my implementations in Java and C++ have reached the optimization limit.
PhysX3D is completely written in Java, so it is compatible with any system that supports Java. It has been successfully examined on a variety of different computers ranging from a Raspberry Pi 2 over several laptops to a Linux Cluster with four 16-core AMD Opteron processors offering 0.59Tflops. In all tests it was able to utilize the entire computational power provided by the systems. The Nvidia GeForce GTX 960M as well as the Intel HD Graphics 4600 have been successfully tested for GPU acceleration. Also tests on a ZOTAC GeForce GTX 1080 AMP Extreme (9.78Tflops, 2560 shader units @1.911GHz) have been conducted. Any GPU with OpenCL support will be compatible.
Just for fun I also benchmarked PhysX3D on the Nvidia GeForce GTX Titan Xp (14.48Tflops, 3840 shader units @1.404-1.885GHz), which is currently the second fastest consumer GPU in the world. This graphics card can handle 340 Billion force calculations per second.
Mathematical problems like the n-body-problem cannot be solved analytically and thus require a numerical method in order to be approximated. So, what is an integrator?
An integrator is an algorithm that, at a discrete time step, gets the positions, velocities and acclelerations of all particles as input and calculates the positions and velocities of all particles one time step later as ouput.
x(t), v(t), a(x(t)) ⟶ x(t+∆t), v(t+∆t)
This is the most important part of the entire program. There are many ways to do it, so I tested all major types of (explicit) integrators in order to find the most efficient one.
| Integrator | Description | Algorithm | Order | Evals | Performance |
|---|---|---|---|---|---|
| Euler | Initially, PhysX3D started with the straightforward Euler method, which is easy to implement, but compared to other integration methods it is not competitive at all and moreover results in instability very fast. |
x(t+∆t) = x(t) + v(t) ∆t + ½ a(x(t)) ∆t² v(t+∆t) = v(t) + a(x(t)) ∆t |
O(t1) | 1 | 1x |
| RK4 (Type RK) |
In version 13.0 I implemented Runge-Kutta 4th order to replace Euler. RK4 is much more stable than Euler and furthermore it can handle large integration steps while still keeping the overall error low. One "disadvantage" of RK4 is that it requires four evaluations of the acceleration function (the acceleration between every pair of two bodies has to be computed four times) making a single calculation step take the quadruple calculation time of one Euler step. Despite that, the superior accuracy of RK4 makes its performance better than Euler by a factor of about 300. |
kx1 = v(t) kv1 = a(x(t)) kx2 = v(t) + ½ kv1 ∆t kv2 = a(x(t) + ½ kx1 ∆t) kx3 = v(t) + ½ kv2 ∆t kv3 = a(x(t) + ½ kx2 ∆t) kx4 = v(t) + kv3 ∆t kv4 = a(x(t) + kx3 ∆t) x(t+∆t) = x(t) + ⅙ (kx1+2⋅kx2+2⋅kx3+kx4) ∆t v(t+∆t) = v(t) + ⅙ (kv1+2⋅kv2+2⋅kv3+kv4) ∆t |
O(t4) | 4 | 303x |
| RKN4(5) (Type RKN) |
In version 15.8 I experimented with Runge-Kutta-Nyström 4(5)th order. RKN4(5) solves the second-order ordinary differential equation of gravity as one instead of splitting it into two first-order ordinary differential equations and then solving them alternating like RK4 does. RKN4(5) requires at least five evaluations of the acceleration function to work and a sixth evaluation for estimating the local error which can then be used for stepsize-control. Stepsize-control is an algorithm which automatically calculates the optimal stepsize for the minimum local error based on the dynamically changing system. For example, it drastically decreases the simulation speed in case of close encounters to maintain accuracy and it increases the speed when all bodies are far apart. This means that with stepsize-control enabled the simulation speed cannot be maintained as constant. Surprisingly, when the stepsize is chosen above the ideal stepsize, RKN4(5) with the original integration coefficients presented by Fehlberg is inferior to RK4 by a factor of 2 in terms of the global energy error. In version 15.9 I tried another variant of Runge-Kutta-Nyström 4(5)th order with a different set of coefficients (D. G. Bettis). This turned out to be 3 times as accurate as RK4 when only using five evaluations of the acceleration function. It is also twice as stable at large stepsizes than RK4. With this variant of RKN4(5) it is even possible to do stepsize-control with only five evaluations, even though a little different as described in the paper since their claim of f5 of the previous step to be equal to f0 of the next step turned out to be wrong thru my investigations. So for stepsize-control I am using the truncation error in position which does not require the sixth evaluation. The optimal stepsize can be used as a dynamic limit for the maximum stepsize and thus the simulation speed. |
Constants ακ, γκλ, Cκ, Ċκ f0 = a(x(t)) f1 = a(x(t) + ∆t α1 v(t) + ∆t² γ10f0) f2 = a(x(t) + ∆t α2 v(t) + ∆t² (γ20f0+γ21f1)) f3 = a(x(t) + ∆t α3 v(t) + ∆t² (γ30f0+γ31f1+γ32f2)) f4 = a(x(t) + ∆t α4 v(t) + ∆t² (γ40f0+γ41f1+γ42f2+γ43f3)) x(t+∆t) = x(t) + v(t) ∆t + (C0f0+C1f1+C2f2+C3f3+C4f4) ∆t² v(t+∆t) = v(t) + (Ċ0f0+Ċ1f1+Ċ2f2+Ċ3f3+Ċ4f4) ∆t |
O(t5) | 5 | 922x |
| Verlet | In version 16.2 I tested the Velocity Verlet (also called Störmer-Verlet) integrator in its one-step formulation. Verlet is much easier to implement than RKN4(5). Symplectic integrators like Verlet are the holy grail for gravity simulations. Velocity Verlet is a second order integrator and thus requires two function evaluations per step, but the first evaluation is the same as the last one from the previous step, so it can be implemented using only one evaluation per step, just like Euler. But what makes Verlet so special? The Verlet integration does conserve both the total energy and the total angular momentum, apart from the round-off error. This makes it more stable than even RKN4(5) by a factor of about 1000 and also the total energy error will not increase over time (besides round-off error which settles in the order of 10-7 for the total energy). On top of that, since Velocity Verlet only requires one single evaluation of the acceleration function per step, it is ideal for simulations with large particle numbers, because the body positions can be updated five times as often as with RKN4(5). However, Verlet does not provide a method for stepsize control directly, so a geometric approach could be used in the future. |
x(t+∆t) = x(t) + v(t) ∆t + ½ a(x(t)) ∆t² v(t+∆t) = v(t) + ½ (a(x(t))+a(x(t+∆t))) ∆t |
O(t2) | 1 | 940000x |
| FR (Type CM) |
Version 16.3 was used to test the Forest-Ruth 4th order symplectic integrator. Like Verlet it is symplectic, so the total energy of the system should in theory be conserved, but in reality there is energy loss at large time steps. Also FR only requires three evaluations of the acceleration function due to the constant c1 being chosen to be zero. Unfortunately, it does not provide better performance than Velocity Verlet at large time steps. |
Constants ci, di v1 = v(t) x1 = x(t) v2 = v1 x2 = x1 + d1 v2 ∆t v3 = v2 + c2 a(x2) ∆t x3 = x2 + d2 v3 ∆t v4 = v3 + c3 a(x3) ∆t x4 = x3 + d3 v4 ∆t v5 = v4 + c4 a(x4) ∆t x5 = x4 + d4 v5 ∆t x(t+∆t) = x5 v(t+∆t) = v5 |
O(t4) | 3 | 123x |
| RKN3NEW (Type RKN) |
Version 16.5 was used to test the RKN3NEW integrator, which is a symplectified version of the standard Runge-Kutta-Nyström 3rd order integrator. It is described to have minimal phase-lag (the constants define those properties). At large time steps however the total energy is not being preserved as well as with Verlet. |
Constants ακ, γκλ, Cκ, Ċκ f0 = a(x(t)) f1 = a(x(t) + ∆t α1 v(t) + ∆t² γ10f0) f2 = a(x(t) + ∆t α2 v(t) + ∆t² (γ20f0+γ21f1)) x(t+∆t) = x(t) + v(t) ∆t + (C0f0+C1f1+C2f2) ∆t² v(t+∆t) = v(t) + (Ċ0f0+Ċ1f1+Ċ2f2) ∆t |
O(t3) | 3 | 303x |
----------------------------------------------------------------------------------------------------------------------------------------------------------------------- date | version name | code | improvements in physics | gain | improvements in graphics ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- 12.04.2014 -------------------- project launched -------------------- 22.04.2014 Gravity 194 implementation of simple Euler method in 2D primitive text-based graphical output 01.05.2014 PhysX2D 307 2D graphics 06.06.2014 Barnes-Hut-Sim. 729 addition of the third spatial dimension orthogonal 3D graphics with mouse rotation and zoom failed attemt of implementing the Barnes-Hut algorithm flight paths as dots 18.10.2014 PhysX3D v0.0 520 improvement in efficiency by avoiding to pause the calculation +10000% coordinate system relativistic mass flight paths as lines 07.08.2015 PhysX3D v1.0 2211 sphere space restriction velocity vectors, groupings retarded gravitational potential perspective 3D-graphics with adjustable field of view seperated calculation and graphics threads keyboard interaction adjustable simulation speed camera switching between bodies possibility to print data output visibility and occultation collision detection grid() and cube() methods for visualising gravity more demo programs relativistic grid() with filter for gravitational waves autorotation velocity-distance-diagram addition of class Launcher for primitive GUI 15.11.2015 PhysX3D v2.0 2337 multithreading in n-body-calculation +150% 29.12.2015 PhysX3D v3.0 2329 automatic decision between single- and multithreading shortened code due to finishCalc() more demo programs 18.01.2016 PhysX3D v4.0 2333 frame buffer for more fluid graphics 21.02.2016 PhysX3D v5.0 2811 configuration methods configurePhys() und configureOut() improved coordinate transformation in convert() solar system from JPL database dynamic osculating Keplerian orbit calculation 27.03.2016 PhysX3D v6.0 3212 substential error fixes in relativistic calculation improved coordinate transformation in convert() linear interpolation in relativistic calculation free camera and improved keyboard interaction extended JPL solar system addition of blooming-effect automatic counterrotation 31.03.2016 PhysX3D v7.0 3260 code outsourcing into relCalc() for more efficiency +20% improved filter for gravitational waves improvement of sphere() for more efficiency +10% 03.04.2016 PhysX3D v8.0 3246 error fixes improved mouse interaction time dilation 12.05.2016 PhysX3D v9.0 3264 change of grid() method from force to potential more efficiant graphics polygon graphics with dynamic lighting 12.05.2016 PhysX3D v9.1 3296 failed attemt to improve efficiency by using "actio=reactio" -10% 26.08.2016 PhysX3D v10.0 3552 addition of date and time tracking stereoscopic side-by-side graphics for VR (from v9.0) 31.08.2016 PhysX3D v11.0 3621 rotation data of planets and moons in JPL solar system full-screen-mode and fixed offset problem extended insert() method of PhysX class rotation of bodies around an arbitrary axis graphical visualisation of planetary rings possibility of many light sources improved efficiency in drawing single pixels improved nomenclature of demo programs and user manual simplification and improvement of the GUI 06.09.2016 PhysX3D v12.0 3638 complete separation of physics and graphics +20% improved mouse interaction adjustment of initial-guess the size of a time step improvement of Launchers automatic detection of the amount of CPU cores fixing an error regarding exported .jar file 06.09.2016 PhysX3D v12.1 3637 failed attemt to improve efficiency by avoiding subtractions -30% 12.09.2016 PhysX3D v13.0 3722 replacement of Euler method by Runge-Kutta 4th order +2000% (from v12.0) improvement of sphere() for more efficiency +5% error fixing in collision detection substantial improvement in efficiency due to micro optimisation +130% 16.09.2016 PhysX3D v14.0 3714 improvement in multithreading +15% addition of CPU and RAM usage monitor RAM limitation to 500MB using System.gc() small improvement of convert() improvement of user manual 13.09.2016 PhysX3D v14.1 3731 failed attemt to improve RK4 -20% 02.10.2016 PhysX3D v14.2 3723 improved garbage collection due to variable recycling +10% improvement of osculating orbit calculation (from v14.0) english designation of solar system bodies improved blooming effect improved configuration of PhysX and Window class extended spacecraft catalogue in the JPL solar system more possibilities for simulating parts of the solar system supplement of planetary rotation data 16.11.2016 PhysX3D v14.3 3749 avoidance of unnecessary memory access improvement of synchronized output data option to pause and resume the n-body-calculation locked camera position when not in free mode 02.10.2016 PhysX3D v15.0-2 experimental implementations of GPU computation via aparapi 25.11.2016 PhysX3D v15.3 4021 successful implementation of GPU computation via aparapi +700% (from v14.3) method for generating galaxies 22.10.2016 PhysX3D v15.4 experimental model for gravity in toroidal space 02.12.2016 PhysX3D v15.5 4007 faster square root from aparapi Kernel +720% improvement in drawing shapes via subtype polymorphism (from v15.3) removal of GPU FP64 requirement improvement in blooming effect memory management 11.02.2017 PhysX3D v15.6 4018 huge improvement in startup time and memory usage improvement of convert() by combined rotation matrix micro optimisation in orbit calculation parallel sorting algorithm for visibility / occultation method for calculating the error of total energy improved movement and rotation of free camera 70% faster orbit plotting with combined rotation matrix faster sphere rendering with combined rotation matrix avoidance of re-calculating output data when paused improved VR perspective in free camera mode improved memory usage of VR mode option to change line thickness 20.03.2017 PhysX3D v15.7 4618 bug fixes zoom adjustment for free camera mode better simulation time tracking simplification and memory improvement of convert() faster StrictMath.sin/cos/tan functions 40% faster blooming effect extended spacecraft catalogue in the JPL solar system i,O,w instead of euler angles for osculating orbits extended asteroid catalogue in the JPL solar system calculation and visualization of eccentric anomaly 30.03.2017 PhysX3D v15.8 4367 tests of RKN4(5) with adaptive stepsize read simple programs from .txt files without hardcoding 09.04.2017 PhysX3D v15.9 4271 tests of RKN4(5) with coefficients from D. G. Bettis 15.04.2017 PhysX3D v16.0 3218 replacement of RK4 by RKN4(5) (D. G. Bettis) +200% automatic initial zoom limit of speed at close encounters via stepsize-control smoothed fps for on screen display removal of tidal friction and relativistic calculation continuous zoom export of configuration and programs to editable file system improved internal configuration methods 16.04.2017 PhysX3D v16.1 3584 experimental implementation of Barnes-Hut algorithm in 3D visualization of 3D Barnes-Hut tree 30.07.2017 PhysX3D v16.2 3296 replacement of RKN4(5) by Velocity Verlet integrator +102000% added galaxy supercluster simulation more accurate date and time tracking 30.04.2017 PhysX3D v16.3 3324 experimental implementation of FR 4th order integrator -99.98% 08.06.2017 PhysX3D v16.4 3374 test of Richardson extrapolation on Velocity Verlet -99.97% (from v16.2) 31.05.2017 PhysX3D v16.5 3333 experimental implementation of RKN3NEW integrator -99.96% (from v16.2) 05.06.2017 PhysX3D v16.6 3267 failed attempt to improve multithreading (from v16.2) 09.07.2017 PhysX3D v16.7 3347 failed attempt to implement motion blur (from v16.2) 30.07.2017 PhysX3D v16.8 3273 failed attempt to improve multithreading (from v16.2) 03.08.2017 PhysX3D v16.9 3666 version for benchmarking all different integrators of previous versions (from v16.2) 06.09.2017 PhysX3D v17.0 3297 failed test of aparapi 1.4.0 (from v16.2) 25.11.2017 PhysX3D v17.1 3314 much faster GPU kernel (shared memory optimization) +92% more compact code with inner classes (from v16.2) removal of CPU usage monitor (up to 50% faster graphics) lower memory usage fixed off center rendering in vr mode lines and polygons in screen corners are now rendered 04.11.2017 PhysX3D v17.2 3317 experimental version for frame time analysis for v17.1 (from v16.2) 05.11.2017 -------------------- transition to C++ -------------------- 05.11.2017 PhysX3D v17.1 2410 cloning of PhysX3D to C++ 24.06.2018 PhysX3D v18.0 2401 CPU vectorization in C++ +115% 26.08.2018 PhysX3D v18.1 2428 slightly faster GPU kernel (improved memory coalescence) +8% better detection of the fastest available GPU 18.04.2018 PhysX3D v18.2 2432 minor bug fix improved mouse rotation
# Configuration ###############################################################################################################################################################################################################################################################################################################
# Every line starting with a "#" is a comment. When the first character in the file name is a "#", the file will be ignored.
# The first 3 lines not starting with a "#" are reserved for configuration and cannot be removed. Every additional line will be read as a new body.
# Every line must contain the proper amount of "," to seperate the values. There is no "," after the last cell of the line. Empty cells will be filled with the default values automatically.
# All set values must be in the right format indicated by the default values. (boolean: true/false, integer: 0/+0, double: 0/0.0/+0.0E+0). The color rgb values must be within the interval [0, 255].
# The number of spaces and tabs as well as the position of the "," does not matter. Line breaks to seperate complete lines with the proper amount of "," will be ignored.
# Basic Settings ######################################################################################################################
# enable GPU acceleration error tolerance monitor fps coordinate system size path length grid resolution cube resolution
# default: true, 1E-3, 60, 500.0, 3, 30, 10
# ''''''''''''''''''''''''''''| ''''''''''''''| ''''''''''''''| ''''''''''''''''''''''| ''''''''''''''| ''''''''''''''| ''''''''''''''|
, , , , , ,
# Units ###############################################################################################################################
# time [s] mass [kg] length [m] size [m] (scale radius) gravitational constant [m^3/kg*s^2]
# default: 1.0, 1.0, 1.0, 1.0, 50.0
# ''''''''''''''''''''| ''''''''''''''''''''''| ''''''''''''''''''''''| ''''''''''''''''''''''| ''''''''''''''''''''''''''''''''''''''|
, , , ,
# Initial Time and Date ###############################################################################################################
# year month day hour minute second millisecond
# default: 0, 1, 1, 0, 0, 0, 0
# ''''''''''''''''''''| ''''''''''''''''''''''| ''''''''''''''''''''''| ''''''''''''''| ''''''''''''''| ''''''''''''''| ''''''''''''''|
, , , , , ,
# Initial State of Bodies #####################################################################################################################################################################################################################################################################################################
# name color (r,g,b) radius star? ring? mass x position y position z position x velocity y velocity z velocity axis inclination axis right ascension rotation period
# default: -, 255, 255, 255, 1.0, false, false, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, infinity
# ''''''''''''''''''''| ''''''''''''''| ''''''''''''''''''''''| ''''''| ''''''| ''''''''''''''''''''''| ''''''''''''''''''''''| ''''''''''''''''''''''| ''''''''''''''''''''''| ''''''''''''''''''''''| ''''''''''''''''''''''| ''''''''''''''''''''''| ''''''''''''''''''''''| ''''''''''''''''''''''| ''''''''''''''''''''''|
| Java version | C++ version | |
|---|---|---|
| Code Lines: | 3314 | 2432 |
| Integration Method: | Velocity Verlet | Velocity Verlet |
| Latest Version: | 17.1 (25.11.2017) | 18.2 (18.04.2018) |
| Java version | C++ version | |
|---|---|---|
| CPU: | 2 GHz Dual-Core | 2 GHz Dual-Core |
| RAM: | 500 MB | 135 MB |
| GPU: | optional, OpenCL support required | optional, OpenCL support required |
| Software: | Java Runtime Environment | Windows 10 64-bit |
PhysX3D v17.1 Java.rar (just unzip the folder, no installation required)
PhysX3D v18.2 C++.rar (just unzip the folder, no installation required)
Copyright © 2014-2022 Moritz Lehmann