Contributing
Vite exists because UE 4.27 can be made fast and stable. Contributions that compromise either defeat the point. The rules below are unusually restrictive for a game engine fork, and that is deliberate.
In this section
Topic | Covers |
|---|---|
Core principles, forbidden constructs, technical and performance rules | |
Prefixes, attribution, branch hygiene | |
Bringing UE5 and upstream features into 4.27 | |
Contributing to these docs |
Before you start
Contribution workflow
Read the coding guidelines. Several common C++ patterns are banned outright, and finding out after you have written the code is expensive.
Check whether the change is already covered. The compile-time switches and engine default changes pages document a lot of existing work.
Work on a branch. Push work-in-progress to alternative branches with a note on what remains, and make other forkers aware of it.
Verify: compiles cleanly under MSVC, Clang compliant, no crashes on startup, shutdown or the Tech Showcase project, no log spam, no ABI changes.
Work through the review checklist before opening the pull request.
The three rules that reject most pull requests
- ABI stability
Do not modify ray tracing payload bitfields, shader-visible enums or flags, packed bitmasks used by RHI or RenderCore, reflection system bitmask definitions, or any CPU/GPU shared struct layout. Breaking these breaks PSO caching, ray tracing stability, serialization and cross-vendor GPU behaviour. ABI violations are rejected immediately, regardless of how good the rest of the change is.
- Performance baseline
Changes are evaluated against an ARM-class ~1 GHz CPU baseline. Measuring on your desktop and finding it fast does not clear the bar. See Performance Targets.
- Copyright cleanliness
Contributions must be original work or permissively licensed (MIT, Apache 2.0, BSD, Zlib). Code copied from UE5 into a 4.27 fork sits under Epic's licence, which is a different question from a permissive licence — see Backporting.
What makes a good contribution
Contributions that fit Vite well tend to share a shape:
Measurable. A profiling capture before and after, on representative content, beats an argument.
Guarded. Anything not needed in shipping is behind a compile-time switch or a console variable, and off by default when it costs something.
Narrow. A change touching one subsystem is reviewable. A change touching the renderer, the physics layer and the build system is not.
Documented. New console variables, switches and defaults need a documentation page or a section in an existing one.
Getting set up
See Build from Source and Toolchain Requirements. Note that engine development requires a source build — installed builds cannot compile engine C++.