Simplified language on the main page

README.md

@@ -6,7 +6,7 @@
 
 # Jolt Physics
 
-A multi core friendly rigid body physics and collision detection library suitable for games and VR applications, used by Horizon Forbidden West.
+A multi core friendly rigid body physics and collision detection library. Suitable for games and VR applications. Used by Horizon Forbidden West.
 
 [![Horizon Forbidden West Cover Art](https://jrouwe.nl/jolt/Horizon_Forbidden_West.png)](https://www.playstation.com/en-us/games/horizon-forbidden-west/)
 
@@ -16,49 +16,49 @@ A multi core friendly rigid body physics and collision detection library suitabl
 
 For more demos and [videos](https://www.youtube.com/watch?v=pwyCW0yNKMA&list=PLYXVwtOr1CBxbA50jVg2dKUQvHW_5OOom) go to the [Samples](Docs/Samples.md) section.
 
-## Design Considerations
+## Design considerations
 
-So why create yet another physics engine? First of all, this has been a personal learning project and secondly I wanted to address some issues that I had with existing physics engines:
+Why create yet another physics engine? Firstly, it has been a personal learning project. Secondly, I wanted to address some issues that I had with existing physics engines:
 
-* In games we usually need to do many more things than to simulate the physics world and we need to do this across multiple threads. We therefore place a lot of emphasis on concurrently accessing the physics simulation data outside of the main physics simulation update:
-	* Sections of the world can be loaded / unloaded in the background. A batch of physics bodies can be prepared on a background thread without locking or affecting the physics simulation and then inserted into the world all at once with a minimal impact on performance.
-	* Collision queries can run in parallel with other operations like insertion / removal of bodies. The query code is guaranteed to see a body in a consistent state, but when a body is changed during a collision query there is no guarantee if the change is visible to the query or not. If a thread modifies the position of a body and then does a collision query, it will immediately see the updated state (this is often a problem when working with a read version and a write version of the world).
-	* It is also possible to run collision queries in parallel to the main physics simulation by doing the broad phase query before the simulation step. This way, long running processes (like navigation mesh generation) can be spread out across multiple frames while still running the physics simulation every frame.
-* One of the main sources of performance problems we found was waking up too many bodies while loading / unloading content. Therefore, bodies will not automatically wake up when created and neighboring bodies will not be woken up when bodies are removed. This can be triggered manually if desired.
-* The simulation runs deterministically, so you could replicate a simulation to a remote client by merely replicating the inputs to the simulation. Read the [Deterministic Simulation](https://jrouwe.github.io/JoltPhysics/#deterministic-simulation) section to understand the limits of this.
-* The simulation of this physics engine tries to simulate behavior of rigid bodies in the real world but makes approximations in the simulation so should mainly be used for games or VR simulations.
+* Games do more than simulating physics. These things happen across multiple threads. We emphasize on concurrently accessing physics data outside of the main simulation update:
+	* Sections of the simulation can be loaded / unloaded in the background. We prepare a batch of physics bodies on a background thread without locking or affecting the simulation. We insert the batch into the simulation with a minimal impact on performance.
+	* Collision queries can run parallel to adding / removing or updating a body. If a change to a body happened on the same thread, the change will be immediately visible. If the change happened on another thread, the query will see a consistent before or after state. An alternative would be to have a read and write version of the world. This prevents changes from being visible immediately, so we avoid this.
+	* Collision queries can run parallel to the main physics simulation. We do a coarse check (broad phase query) before the simulation step and do fine checks (narrow phase query) in the background. This way, long running processes (like navigation mesh generation) can be spread out across multiple frames.
+* Accidental wake up of bodies cause performance problems when loading / unloading content. Therefore, bodies will not automatically wake up when created. Neighboring bodies will not be woken up when bodies are removed. This can be triggered manually if desired.
+* The simulation runs deterministically. You can replicate a simulation to a remote client by merely replicating the inputs to the simulation. Read the [Deterministic Simulation](https://jrouwe.github.io/JoltPhysics/#deterministic-simulation) section to understand the limits.
+* We try to simulate behavior of rigid bodies in the real world but make approximations. Therefore, this library should should mainly be used for games or VR simulations.
 
 ## Features
 
 * Simulation of rigid bodies of various shapes using continuous collision detection:
-	* Sphere.
-	* Box.
-	* Capsule.
-	* Tapered-capsule.
-	* Cylinder.
-	* Convex hull.
-	* Compound.
-	* Mesh (triangle).
-	* Terrain (height field).
+	* Sphere
+	* Box
+	* Capsule
+	* Tapered-capsule
+	* Cylinder
+	* Convex hull
+	* Compound
+	* Mesh (triangle)
+	* Terrain (height field)
 * Simulation of constraints between bodies:
-	* Fixed.
-	* Point.
-	* Distance (including springs).
-	* Hinge.
-	* Slider (also called prismatic).
-	* Cone.
-	* Rack and Pinion.
-	* Gear.
-	* Pulley.
-	* Smooth spline paths.
-	* Swing-twist (for humanoid shoulders).
-	* 6 DOF.
+	* Fixed
+	* Point
+	* Distance (including springs)
+	* Hinge
+	* Slider (also called prismatic)
+	* Cone
+	* Rack and pinion
+	* Gear
+	* Pulley
+	* Smooth spline paths
+	* Swing-twist (for humanoid shoulders)
+	* 6 DOF
 * Motors to drive the constraints.
 * Collision detection:
 	* Casting rays.
 	* Testing shapes vs shapes.
 	* Casting a shape vs another shape.
-	* Broadphase only tests for quickly determining which objects may intersect.
+	* Broadphase only tests to quickly determine which objects may intersect.
 * Sensors (trigger volumes).
 * Animated ragdolls:
 	* Hard keying (kinematic only rigid bodies).
@@ -67,7 +67,7 @@ So why create yet another physics engine? First of all, this has been a personal
 	* Mapping a high detail (animation) skeleton onto a low detail (ragdoll) skeleton and vice versa.
 * Game character simulation (capsule)
 	* Rigid body character. Moves during the physics simulation. Cheapest option and most accurate collision response between character and dynamic bodies.
-	* Virtual character. Does not have a rigid body in the world but simulates one using collision checks. Updated outside of the physics update for more control. Less accurate interaction with dynamic bodies.
+	* Virtual character. Does not have a rigid body in the simulation but simulates one using collision checks. Updated outside of the physics update for more control. Less accurate interaction with dynamic bodies.
 * Vehicles
 	* Wheeled vehicles.
 	* Tracked vehicles.
@@ -82,23 +82,23 @@ So why create yet another physics engine? First of all, this has been a personal
 	* Collision with simulated rigid bodies.
 	* Collision tests against soft bodies.
 * Water buoyancy calculations.
-* An optional double precision mode that allows large worlds.
+* An optional double precision mode that allows large simulations.
 
-## Supported Platforms
+## Supported platforms
 
-* Windows (VS2019, VS2022) x86/x64/ARM32/ARM64 (Desktop/UWP)
-* Linux (tested on Ubuntu 22.04) x64/ARM64
+* Windows (Desktop or UWP) x86/x64/ARM32/ARM64
+* Linux (tested on Ubuntu) x64/ARM64
 * FreeBSD
-* Android (tested on Android 14) x86/x64/ARM32/ARM64
+* Android x86/x64/ARM32/ARM64
 * Platform Blue (a popular game console) x64
-* macOS (tested on Monterey) x64/ARM64
-* iOS (tested on iOS 15) x64/ARM64
+* macOS x64/ARM64
+* iOS x64/ARM64
 * WebAssembly, see [this](https://github.com/jrouwe/JoltPhysics.js) separate project.
 
 ## Required CPU features
 
-* On x86 the minimal requirements are SSE2 but the library can be compiled using SSE4.1, SSE4.2, AVX, AVX2, or AVX512.
-* On ARM64 the library by default compiles with NEON and FP16, on ARM32 it can be compiled without any special CPU instructions.
+* On x86/x64 the minimal requirements are SSE2. The library can be compiled using SSE4.1, SSE4.2, AVX, AVX2, or AVX512.
+* On ARM64 the library uses NEON and FP16. On ARM32 it can be compiled without any special CPU instructions.
 
 ## Documentation
 
@@ -106,14 +106,17 @@ To learn more about Jolt go to the latest [Architecture and API documentation](h
 
 To get started, look at the [HelloWorld](HelloWorld/HelloWorld.cpp) example. A [HelloWorld example using CMake FetchContent](https://github.com/jrouwe/JoltPhysicsHelloWorld) is also available to show how you can integrate Jolt Physics in a CMake project.
 
-Some algorithms used by Jolt are described in detail in my GDC 2022 talk Architecting Jolt Physics for 'Horizon Forbidden West' ([slides](https://gdcvault.com/play/1027560/Architecting-Jolt-Physics-for-Horizon), [slides with speaker notes](https://jrouwe.nl/architectingjolt/ArchitectingJoltPhysics_Rouwe_Jorrit_Notes.pdf), [video](https://gdcvault.com/play/1027891/Architecting-Jolt-Physics-for-Horizon)).
+Some algorithms used by Jolt are described in detail in my GDC 2022 talk: Architecting Jolt Physics for 'Horizon Forbidden West' ([slides](https://gdcvault.com/play/1027560/Architecting-Jolt-Physics-for-Horizon), [slides with speaker notes](https://jrouwe.nl/architectingjolt/ArchitectingJoltPhysics_Rouwe_Jorrit_Notes.pdf), [video](https://gdcvault.com/play/1027891/Architecting-Jolt-Physics-for-Horizon)).
 
 ## Compiling
 
-* The library has been tested to compile with Cl (Visual Studio 2019-2022), Clang 10+ and GCC 9+.
-* It uses C++17 and only depends on the standard template library.
-* It doesn't make use of compiler generated RTTI or exceptions.
-* If you want to run on Platform Blue you'll need to provide your own build environment and PlatformBlue.h file due to NDA requirements (see Core.h for further info).
+* Compiles with Visual Studio 2019+, Clang 10+ or GCC 9+.
+* Uses C++ 17.
+* Depends only on the standard template library.
+* Doesn't use RTTI.
+* Doesn't use exceptions.
+
+If you want to run on Platform Blue you'll need to provide your own build environment and PlatformBlue.h due to NDA requirements. This file is available on the Platform Blue developer forum.
 
 For build instructions go to the [Build](Build/README.md) section. When upgrading from an older version of the library go to the [Release Notes](Docs/ReleaseNotes.md) or [API Changes](Docs/APIChanges.md) sections.
 
@@ -121,7 +124,7 @@ For build instructions go to the [Build](Build/README.md) section. When upgradin
 
 If you're interested in how Jolt scales with multiple CPUs and compares to other physics engines, take a look at [this document](https://jrouwe.nl/jolt/JoltPhysicsMulticoreScaling.pdf).
 
-## Folder Structure
+## Folder structure
 
 * Assets - This folder contains assets used by the TestFramework, Samples and JoltViewer.
 * Build - Contains everything needed to build the library, see the [Build](Build/README.md) section.
@@ -135,15 +138,14 @@ If you're interested in how Jolt scales with multiple CPUs and compares to other
 * UnitTests - A set of unit tests to validate the behavior of the physics engine.
 * WebIncludes - A number of JavaScript resources used by the internal profiling framework of the physics engine.
 
-## Bindings For Other Languages
+## Bindings for other languages
 
 * C [here](https://github.com/michal-z/zig-gamedev/tree/main/libs/zphysics/libs) and [here](https://github.com/amerkoleci/JoltPhysicsSharp/tree/main/src/joltc)
 * [C#](https://github.com/amerkoleci/JoltPhysicsSharp)
-* [Java](https://github.com/aecsocket/jolt-java)
 * [JavaScript](https://github.com/jrouwe/JoltPhysics.js)
 * [Zig](https://github.com/michal-z/zig-gamedev/tree/main/libs/zphysics)
 
-## Integrations in Other Engines
+## Integrations in other engines
 
 * [Godot](https://github.com/godot-jolt/godot-jolt)
 * [Source Engine](https://github.com/Joshua-Ashton/VPhysics-Jolt)