Fast inner loop
Python scripts, hot-reload, and editor-side tooling reduce iteration friction without downgrading the runtime core.
Independent Engine Stack
A game engine built for teams who would rather own the stack.
Rebel with a cause.
Infernux is a C++17 and Vulkan engine with a Python-facing production layer. It is designed for fast iteration, scriptable rendering, transparent architecture, and zero dependence on someone else's pricing model.
Engine Position
Not an experiment. A controllable engine core.
Rendering, physics, asset workflows, editor panels, play mode isolation, undo and hot-reload already exist inside one coherent stack.
pipeline.py
class StudioPipeline(RenderPipeline):
def render(self, context, cameras):
for camera in cameras:
culling = context.cull(camera)
graph = RenderGraph("FrameGraph")
gbuffer = graph.add_pass("GBuffer")
lighting = graph.add_pass("Lighting")
outline = graph.add_pass("Outline")
lighting.read("gbuffer_normal")
outline.read("depth")
context.apply_graph(graph.build())
context.submit_culling(culling)They said Python belongs in tools, not engines. They said serious rendering must be hidden behind proprietary editor UX. Infernux answers with a different proposition: readable internals, scriptable graphics, and a production path you can actually control.
Three operating principles
A better engine is not just faster. It is more legible, more iterable, and more sovereign.
The project is shaped around engineering control rather than platform lock-in. Each layer exists to reduce hidden cost for teams building real games and real tools.
Transparent render architecture
The render stack is structured, inspectable, and scriptable. It is meant to be extended, not worshipped from a distance.
No business trap
MIT licensing and repository-first development keep the cost model simple: the work is in the code, not in negotiating with a vendor.
Engine surface
The current engine already spans runtime, editor, rendering, and pipeline tooling.
This is the part old landing pages usually flatten into a feature dump. Here it is arranged as working capability blocks that speak to how teams actually build projects.
Runtime
Rendering core
Forward and deferred rendering, PBR materials, cascaded shadows, 8 post-processing effects, shader reflection, and RenderGraph-based pass scheduling.
Simulation
Physics integration
Jolt-backed rigidbodies, colliders, queries, collision callbacks, layer filtering, and scene-synchronized transforms.
Tooling
Editor framework
12 panels: Hierarchy, Inspector, Scene View, Game View, Console, Project, UI editor, Toolbar, gizmos, multi-selection, undo/redo, and play-mode scene isolation.
Scripting
Python gameplay layer
Component lifecycle similar to Unity, serialized fields visible in Inspector, decorators, input APIs, coroutines, prefab system, and script hot-reload.
Pipeline
Asset and project pipeline
GUID-based AssetDatabase, .meta sidecar files, dependency tracking, scene serialization, standalone game build via Nuitka, and a PySide6 project launcher.
Extension
ML-ready scripting surface
Python means direct access to CV, data, and ML libraries for gameplay logic, tools, analysis, and offline pipelines.
Why it matters
Infernux is not trying to imitate every engine. It is choosing a specific operating model.
The important distinction is not only technical. It is about who gets to decide how the render pipeline, tooling surface, and project economics evolve.
Stack anatomy
Project and tools
PySide6 launcher, editor panels, authoring workflows, UI editor, project management.
Gameplay and render authoring
Python components, RenderGraph authoring, post-process scripting, runtime behaviors.
Binding seam
pybind11 modules connect engine services to a script surface that remains direct and debuggable.
Native core
Scene systems, renderer, physics, resources, platform abstraction, and runtime data ownership.
Working loop
1
Author
Write gameplay or render logic in Python with serialized, editor-visible configuration.
2
Assemble
Build passes, resources, and injection points through a RenderGraph description instead of hard-coded one-off paths.
3
Execute
Push the graph into the C++ backend where Vulkan scheduling, barriers, memory aliasing, and submission are managed.
4
Iterate
Inspect results in editor views, tune data, hot-reload scripts, and loop again without restarting the project.
Studio workflow
Built for the day-to-day engineering path, not only for screenshots of the editor chrome.
The website should not pretend the engine begins and ends at a hero headline. The useful unit is the actual workflow from project bootstrap to runtime validation.
Start a project
Create or open projects through the launcher, keep dependency boundaries explicit, and manage assets with stable IDs.
Author systems
Compose scenes, scripts, materials, and render passes while staying inside a consistent data model.
Inspect and tune
Use Scene View, Inspector, console filters, selection tools, and editor-side UI to shorten iteration distance.
Validate runtime
Run the scene with play-mode isolation, profile the render graph, verify scripting hooks, and keep the loop tight.
Where the project stands
The current release is a serious technical preview, not a promise deck.
This framing matters. It sets the correct expectation for contributors and makes the roadmap page useful instead of decorative.
Today
Runtime and editor foundation
v0.1
Rendering, physics, audio, scripting, prefabs, game UI, editor authoring, asset workflows, standalone build, and scene tooling are all in place.
Next
Animation, advanced UI, cross-platform
v0.2 β v0.4
Upcoming milestones focus on expanding content scope: animation systems, advanced UI controls, and cross-platform support.
Build something that belongs to you.
Infernux exists for teams who want source access, architectural clarity, and a workflow they can actually reshape. If that sounds like the right direction, start with the docs, inspect the code, and push the engine further.