Expose JPH::PhysicsSystem::SetGravity / GetGravity - #23
Merged
Conversation
Wraps the existing JPH::PhysicsSystem::SetGravity(Vec3Arg) and GetGravity() methods 1:1, mirroring the to_jph / to_jpc helper pattern used throughout JoltC.cpp. Vec3 conversion uses the existing helpers in JoltC.cpp lines 162-167. Motivation: the Jolt physics system's gravity is read by the integrator every step (it's not a per-body property — bodies have a GravityFactor multiplier on top). Until now there was no way to set or read system gravity from C-binding consumers, forcing them to either accept the hard-coded default (0, -9.81, 0) or apply gravity manually as per-body forces. Added in two places: - JoltC/Functions.h: declarations next to AddConstraint/RemoveConstraint - JoltCImpl/JoltC.cpp: implementations following the same `to_jph(self) -> JPH::PhysicsSystem*` -> method-call pattern as the existing PhysicsSystem wrappers PR submitted from Solidor777/JoltC:custom-gravity for upstream review. The Titan engine carries this patch locally on its mirror fork until upstream merges; once merged we sync from upstream and the local diff dissolves.
Merged
4 tasks
LPGhatguy
added a commit
to SecondHalfGames/jolt-rust
that referenced
this pull request
May 11, 2026
## Summary
Two coupled bugs surfaced while cross-compiling `joltc-sys` to Android
(aarch64-linux-android via NDK r26d clang from a Windows host).
### 1. `cfg!(windows)` is a HOST-OS check, not a target-OS check
`build.rs` runs on the host. When the host is Windows and the target is
Android, the existing `if cfg!(windows) { config.cxxflag("/EHsc"); }`
unconditionally appends the MSVC-only `/EHsc` flag. NDK clang then
receives `/EHsc` as a path argument and errors with `no such file or
directory: '/EHsc'`.
**Fix:** read `CARGO_CFG_TARGET_OS` and gate `/EHsc` on the actual
target.
### 2. Native Android cross-compile setup is missing
Building for Android via the standard `cargo ndk --target
<android-triple> check -p joltc-sys` flow currently fails because
`joltc-sys` does not set:
- `CMAKE_TOOLCHAIN_FILE` (NDK's `build/cmake/android.toolchain.cmake`).
- `ANDROID_ABI` (the toolchain reads it as a CMake `-D` variable; env
var is ignored).
- The CMake generator (cmake-rs defaults to MSBuild on Windows hosts;
the NDK toolchain only supports Ninja / Makefiles).
**Fix:** when `target_os == "android"`, derive `ANDROID_ABI` from
`CARGO_CFG_TARGET_ARCH` (`aarch64` → `arm64-v8a`, `arm` → `armeabi-v7a`,
`x86` / `x86_64` 1:1), resolve the NDK from `ANDROID_NDK_HOME` /
`ANDROID_NDK_ROOT` / `ANDROID_NDK`, force `Ninja`, and pin
`ANDROID_PLATFORM=android-21`.
## End-user contract after this change
```sh
export ANDROID_NDK_HOME=/path/to/ndk # or ANDROID_NDK_ROOT / ANDROID_NDK
cargo ndk --target aarch64-linux-android check -p joltc-sys
```
The standard cargo-ndk + `nttld/setup-ndk@v1` GitHub Action workflow
Just Works.
## Validation
- Locally validated on Windows host → aarch64-linux-android with NDK
r26d. Full `JoltPhysics + JoltC + joltc-sys + rolt` cross-compile
completes in ~20s. Downstream Rust crate (Titan engine's
`titan-jolt-3d`) builds against the cross-compiled libs.
- `armv7-linux-androideabi` is **not addressed by this PR** — it hits an
unrelated `JoltC` `LAYOUT_COMPATIBLE` static_assert (`JPC_*Settings`
16-byte alignment vs `JPH::*Settings` 8-byte alignment on 32-bit ARM).
That looks like a JoltC-side ABI bug for 32-bit targets; happy to track
separately.
- Desktop targets (Win/Linux/macOS) are unaffected — Android branch is
gated on `target_os == "android"`, and the `/EHsc` change only narrows
the existing condition (Windows targets still get it).
## Test plan
- [x] `cargo check -p joltc-sys` on Windows host (default target,
x86_64-pc-windows-msvc) — `/EHsc` still applied; existing behavior
unchanged.
- [x] `cargo ndk --target aarch64-linux-android check -p joltc-sys` on
Windows host — succeeds with only `ANDROID_NDK_HOME` set.
- [ ] `cargo ndk --target aarch64-linux-android check -p joltc-sys` on
Linux + macOS hosts — reviewer to validate; should be the simpler case
(no `/EHsc` hot path).
- [ ] `cargo check -p joltc-sys` on Linux/macOS — unaffected; existing
CI covers.
Opened from the same Titan-engine fork that submitted
SecondHalfGames/JoltC#23 (the `JPC_PhysicsSystem_SetGravity` export).
Both PRs are independent — happy to address review feedback on either.
---------
Co-authored-by: Lucien Greathouse <me@lpghatguy.com>
Solidor777
added a commit
to Solidor777/JoltC
that referenced
this pull request
May 13, 2026
…s#23 (gravity) # Conflicts: # JoltC/Functions.h
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds C wrappers for
JPH::PhysicsSystem::SetGravity(Vec3Arg)andGetGravity(), exposing per-system gravity control to JoltC consumers (joltc-sys, rolt, downstream Rust bindings, LuaJIT bindings, etc.).Motivation
Jolt's
PhysicsSystemstores gravity internally and the integrator reads it every step. Without a C wrapper, consumers are locked to Jolt's default(0, -9.81, 0)and cannot implement gameplay features like low-gravity power-ups, alien-planet biomes, or per-region gravity overrides. Per-bodyGravityFactoris a scalar multiplier and cannot redirect gravity, so it does not substitute.Implementation
JoltC/JoltC/Functions.h— declarations placed next toAddConstraint/RemoveConstraint(line ~1626).JoltC/JoltCImpl/JoltC.cpp— implementations using the existingto_jph(self) -> JPH::PhysicsSystem*+to_jph(JPC_Vec3)/to_jpc(JPH::Vec3)helper pattern (lines 162-167 ofJoltC.cpp).17 lines total. No allocations, no behavioral changes to existing APIs — purely additive.
Test plan
titan-jolt-3dcrate, which vendors joltc-sys + rolt) callsJPC_PhysicsSystem_SetGravityper step; bodies accelerate along the supplied gravity vector. New unit test verifies+Xgravity moves a body along+X.Opened from a downstream-vendoring fork; happy to address review feedback or split the change if preferred.