I’m releasing an open-source project called UETPFCore, a multi-scale physics and simulation framework built on Unreal Engine 5.7 projects.
The goal is to provide a reusable foundation for projects that need to operate across large spatial and temporal scales (planetary → local), without floating-point drift, while remaining performant enough for real-time use. It’s intended to serve both physics-heavy games and research-oriented simulation workflows to build robust architecture and avoid duplicate effort.
Clear separation between fast approximations and higher-fidelity models
Testable, extensible architecture suitable for long-running simulations
The project is early but functional, released under Apache 2.0, and actively being developed. Our studio is building our flagship game using the framework and are opening up the foundations to other projects for feedback and support.
Keep everything local. World origin shifting. Max distance of 200uu from camera. Or else precision is 0. That’s the engine. It’s built like s*it on purpose and with some reason.
Afterall, if you expect a 1mm precision on an animation executing on a skeletal mesh that is about 2 pixels on screen, then you are the problem. Not the engine. Not it’s creators.
On the other hand, the fact that you cannot exactly reprent the RA and Declination of an object with 1mm precision is indeed a problem. But it is a problem for math as well since even with doubles the equations are error prone. It is a computing problem. One we solve with specific calculators and acceptable margins of error - which also means *don’t use unreal* for this.
Really just don’t. Instead of simulating anything you let the relevant manager run with maths. Nothing is done physically (with objects) unless you absolutely have to.
Idk think of it as a flying space ship. You have origon, travel speed, and direction. You know where and when it’s going to be already, you don’t need it to be constantly placed there and accessible at all times. You don’t really need anything else to be able to get the real result out.
A common pitfall here is id10ts errors of people making BPs and setting the world loc on tick.
Obviously. You don’t do that. You create asset managers that are in charge of your instance management which keep track of items.
You have hard limitations at number of skms derived from overall bone count. Check dev diaries for stuff like subnautica and bannerlord.
Check the dev logs for sea of thieves who ran into engine limitations on instance management.
Then you have the massive Pitfalls of bad graphics/performance where they are just engine level issues you cannot overcome within the engine without jumping ship - for instance to an Nvidia branch. On that one, you have to contend with Chaos being sub-par all around too.
Overall, I’m glad you released this as open-source, but the need for it in a production environment is near 0?
People needing this kind of precision(s) need to seriously consider using better engines that allow for it natively - or writing their own even.
Using Unreal for this purpose is similar to using gingerbread to make yourself a real house… it can be done, just like little ones are made. But should you?
On the other hand it’s perfectly fine to make a gingerbread house with this engine - queue up fortnite…
Part of the problem that needs to be demystified is just the fact that this engine is not the proper tool for eveything like Epic wants the users to think… its good at one thing only really, ok 2: Having consistently bad performance and loads of bugs!
Thanks for the detailed technical feedback. Let me clarify the scope and address your points:
On Precision & Scale
You’re absolutely right about world origin shifting and the 200uu guideline - and that’s exactly what the framework implements. The WorldFrameSubsystem handles origin shifting automatically when transitioning between planetary surface → orbit → interplanetary space.
We’re not trying to achieve millimeter precision at astronomical scales. The use case is games like Starfield, No Man’s Sky, or Star Citizen - where you need:
Ground gameplay at cm precision (standard UE)
Seamless transition to orbit (origin shift)
Skybox/celestial rendering that matches time/position
Physics that “feels right” at each scale
The framework uses approximations appropriate to each context. Main branch uses simplified Kepler orbits for gameplay. That’s by design - gameplay first, not simulation accuracy.
Current implementation: Flat world coordinate transformation with origin shifting
Planned: Spherical planet surface math (in development)
On Simulation vs Real-Time
100% agreed - you don’t physically simulate everything. That’s why the framework has:
TimeSubsystem with configurable update rates
Delta persistence for sparse world changes
Proxy/LOD patterns for distant objects
Math-driven state for anything beyond gameplay range
When I said “longer-running simulation,” I meant game-time progression (day/night cycles, seasonal changes, orbital mechanics) - not real-time scientific simulation. Poor wording on my part.
On Engine Limitations
Valid points about SKM bone limits and instance management. We’re working within those constraints:
Using instanced static meshes for distant objects
LOD hierarchies for populated areas
Smart streaming with World Partition
Knowing when NOT to use skeletal meshes
The Sea of Thieves postmortems from Rare have been very helpful here.
On Chaos Physics
Yes, Chaos has rough edges. But for gameplay physics (not engineering simulation), it’s workable. The framework provides:
Clean abstraction layers over Chaos
Fallback to simplified models when needed
Clear separation of “animation physics” vs “gameplay physics”
If Chaos becomes a blocker, the subsystem architecture lets you swap implementations.
On “Is UE the Right Tool?”
For scientific simulation? No.
For research-grade ephemerides? No.
For games that want:
Planetary exploration with seamless surface ↔ orbit
Physically-driven interactions that feel responsive
Modular architecture that survives years of development
Access to UE’s rendering/animation/audio pipeline
Yes. That’s the niche.
On Production Need
“Near 0” might be true for your current projects, but studios are actively building:
Space exploration games
Planetary simulation experiences
Flight/vehicle sims with realistic environments
Large-scale destruction/physics games
These all hit the same architectural problems. Having a shared, open-source foundation reduces duplicate work.
What This Framework Is
What It IS:
Production-informed architecture patterns for multi-scale simulation
Clean subsystem boundaries for complex systems
A starting point that others can fork/adapt
Open-source reference implementation (Apache 2.0)
What It IS NOT:
A replacement for specialized sim engines
A scientific computing platform
A silver bullet for all UE limitations
Pretending UE is something it’s not
If your game doesn’t need multi-scale coordination or physics-driven world simulation, you don’t need this framework. And that’s fine.
But for teams that do, having a reference implementation beats everyone reinventing the wheel.
The Precision/Simulation Stack
Your feedback encouraged me to clarify where this framework fits:
Layer 1: Scientific Truth (Offline)
├── SPICE for ephemerides
├── Isaac Sim for vehicle dynamics
├── GMAT for trajectory planning
└── Output: Validated state vectors
Layer 2: UETPFCore (Bridge Layer) ← WE FIT HERE
├── Main Branch: Gameplay-friendly approximations
├── UETPFCoreSim Branch: Scientific data integration*
│ └── SPICE ephemerides, deterministic physics (planned)
│ └── Import/interpolate validated data
│ └── Maintain “good enough” accuracy for target use case
Layer 3: UE Rendering/Gameplay (Runtime)
├── Chaos physics for “feel”
├── Visuals, audio, UI
├── Player interaction
└── Real-time constraints
*New: For teams needing validated ephemerides (aerospace training, educational sims, robotics visualization), I’ve started a dedicated branch:
This adds:
SPICE Toolkit integration (NASA/JPL validated ephemerides) Thread-safe ephemerides subsystem Deterministic physics component (planned) USD import/export for Omniverse (planned)
Clear scope: This is for training/education, NOT mission-critical operations or publishable research.
Current Implementation Status
Implemented in Main Branch:
WorldFrameSubsystem (origin shifting)
TimeSubsystem (configurable time scales)
SurfaceQuerySubsystem (physics material queries)
BiomeSubsystem (environmental data)
Delta persistence system (sparse world changes)
Implemented in UETPFCoreSim Branch:
SPICE ephemerides subsystem
Kernel management and validated celestial mechanics
Time format conversions
Planned Development:
Spherical planet surface math
USD pipeline integration
Deterministic physics component
Example content and validation tests
Valid technical points. Your feedback helped clarify documentation and inspired the scientific simulation branch.
UE has limitations, but it’s also improved massively (LWC, World Partition, Lumen, Mass, Nanite). The framework has value because:
Multi-scale games ARE being made (Starfield exists!)
Exploring clean architecture patterns benefits the industry
Reference implementations are valuable
Apache 2.0 means people can fork/adapt
For critical simulation, use specialized tools. For games wanting scientifically-plausible worlds within UE’s constraints, this framework provides a tested architectural foundation.
Thanks again for the reality check on precision expectations and engine limits - that feedback improves documentation and sets realistic expectations.
I’m still not really sure this will be used by many; you see you are dealing with either AAAs who will tear it apart because they hire “talent" that has to think which foot to put a shoe on in the morning (and often gets it wrong) due to the salary they pay them… or indies who don’t really have much of any buisness making something this complicated in the first place (at least without some funding).
I can almost guarantee you will get a grant. I can also prettt much guarantee that epic is going to take it and mangle it themselves as well (hell, they did it to me, they likely just do it to everyone as a matter of course).
The important part anyway is that you keep true to the initial idea here, and keep on exploring this with the help of the rest of the open-source community. On my part, I’ll check it out, see what it’s all about, maybe try and squish some bugs
However, I think you should heavily consider just extruding this from unreal.
Obviously, I hate the darn engine and the id10ts who make it. They never - ever - learn from their mistakes, no matter how many times you smash their head into that steaming ^^doodo^^ they left on your carpet…
And having an open-source system that you can know and integrate into a variety of other engines - while getting very similar results - seems like a real product you could actually bank on.
Havok used to do it. They made mad money from it too…
https://github.com/ThreadedPixelFactory/UETPFCore
SPICE Toolkit integration (NASA/JPL validated ephemerides)
Deterministic physics component (planned)