[PoC] Rigs of Rods running natively on BGFX & SDL3 (OgreMain completely removed)

[Kiwichek]

Hi everyone,
Over the past week, I've conducted a massive architectural overhaul of the game engine, completely tearing out the legacy Ogre3D infrastructure and migrating the runtime to native BGFX and SDL3.
The application runtime is now entirely free of Ogre::Root, RenderSystem, OgreMain dependencies, plugins, and old configuration files.
Current Milestone & What's Working:

• Platform & Windowing: Fully powered by SDL3 handling high-DPI window events, input pumping, and full-screen transitions. OIS and Win32 WndProc have been completely dropped.
• Core Renderer: BGFX handles initialization, dynamic mesh buffers, and frame submissions natively. The project builds and targets Vulkan/Direct3D backends via static offline shader compilation.
• Resource & Stream Layer: Completely rewritten boundary via miniz and standard filesystem. There is no ResourceGroupManager lookup left in source/main.
• Content Compatibility: Built dedicated CPU-only .mesh and .skeleton chunk parsers. Dynamic FlexMesh instances, FlexBodies, meshwheels/tires, static props, and skeletal animations (including character skinning) translate and submit directly to persistent BGFX parts.
• Environment & Systems: Replaced Caelum/SkyX/Hydrax with a custom camera-oriented BGFX atmosphere pass and a native daylight-blue controller. Custom terrain shaders evaluate two-layer OTC page blend maps entirely on the GPU. Water lines now instantiate a flat native transparent mesh (BgfxWater).
• UI & Particles: MyGUI is running via an engine-owned in-memory stream using BGFX textures instead of the old Ogre RenderManager. Wheel contact effects, exhaust smoke, and vehicle flares use generic native dynamic billboard quad batches.

As you can see from the screenshots, it runs, loads maps (like Simple2), manages complex rigid/soft-body fixtures, handles multi-submesh meshes with proper material overrides, and stays locked at a smooth 144 FPS with standard frame presentation.
Project Status:
This is a strict Proof of Concept (PoC) born out of pure curiosity. The custom asset parser is still quite finicky and causes crashes on certain legacy formats. The deformation/damage vertex pipeline also needs significant refinement as simulation coordinates update at runtime.
I currently have no plans to open-source the codebase or publish a repository, as this was built purely as a personal tech-challenge. Just wanted to share that a lightweight, Ogre-free Rigs of Rods engine is entirely possible.
Cheers!

 

[thomz92]

I'm a little lost on the tech but sounds cool! What are the advantages of dropping Ogre in favor of BGFX for A. Developers and B. End users? @ohlidalp would probably be interested in seeing this...

 

[Kiwichek]

Good questions. Let’s not point fingers, but swapping out a 20-year-old engine monster for a modern API does actual engineering work that massively accelerates the game, instead of just adding cosmetic decorations to a dying framework.

Here is why Ogre is a massive bottleneck compared to native BGFX/SDL3:

**A. For Developers (Real Engineering vs. Script Patching):**
1. **Zero Legacy Bloat:** OgreMain forces you to drag around obsolete math types, heavy resource loops, and rigid scene graphs. BGFX gives you clean, pure graphics abstraction. You write your own lightweight CPU chunk parsers, bypass the entire Ogre scene manager, and feed raw vertex data straight to the GPU.
2. **Offline Shader Pipeline:** BGFX handles shader compilation offline (GLSL, SPIR-V, DirectX blobs). You don't have to spend years maintaining broken runtime script parsers or keeping dead, abandoned libraries like Caelum and Hydrax on life support.

**B. For End Users (Raw Performance vs. Cosmetic Updates):**
1. **Massive Performance Boost:** Completely dropping Ogre's bloated rendering pipeline removes massive CPU overhead. Frame presentation becomes incredibly tight, drastically improving raw FPS (easily locking a smooth 144 FPS in dense scenes, as seen in the screenshots).
2. **No Hardware Nightmares & Native macOS:** No more broken DirectX 9 SDK dependencies or ancient Cg shader errors on newer Windows builds. It runs flawlessly on modern OS out of the box. More importantly, since BGFX and SDL3 target Metal natively, this entire architecture can be fully compiled and run smoothly on macOS without any ugly Wine wrappers or emulation layers. It just runs.
3. **Optimized Memory Footprint:** By completely eliminating Ogre's runtime proxy textures and leaky overlay systems, RAM utilization is predictable and stable.

It's a complete architectural rewrite, not a chatbox redesign. Curious to see what @ohlidalp thinks about this approach.

I'm a little lost on the tech but sounds cool! What are the advantages of dropping Ogre in favor of BGFX for A. Developers and B. End users? @ohlidalp would probably be interested in seeing this...

 

[thomz92]

Like I said, just an average user with no coding experience here - but two more questions:

1. I think a lot of these overhaul discussions eventually run into the fact that current users (and the few modders) like current (and legacy) content and want stuff to work like it's always worked. It sounds like you have this in mind with the "content compatibility" section of your first post, though?

Content Compatibility: Built dedicated CPU-only .mesh and .skeleton chunk parsers. Dynamic FlexMesh instances, FlexBodies, meshwheels/tires, static props, and skeletal animations (including character skinning) translate and submit directly to persistent BGFX parts.

2. How would this approach compare to a full upgrade to the latest and greatest Ogre or Ogre-Next? Does it have any effect on how easy it is to add all the fancy graphics effects of modern games? I picture the latest Ogre as having ready made tools for that, but I really don't know what I'm talking about.

 

[Fili86RaceFace]

In practical terms, what will the real advantages be compared to the current version? Will mod creation be easier? For instance, will modifying a skin be better? Will resolutions be higher? Ultimately, will the game take up more hard drive space? Will the mods be larger in size?

 

[Kiwichek]

Like I said, just an average user with no coding experience here - but two more questions:

1. I think a lot of these overhaul discussions eventually run into the fact that current users (and the few modders) like current (and legacy) content and want stuff to work like it's always worked. It sounds like you have this in mind with the "content compatibility" section of your first post, though?



2. How would this approach compare to a full upgrade to the latest and greatest Ogre or Ogre-Next? Does it have any effect on how easy it is to add all the fancy graphics effects of modern games? I picture the latest Ogre as having ready made tools for that, but I really don't know what I'm talking about.

You're asking the right questions, and this cuts straight to the core of engine architecture:

**1. About Content Compatibility (Old Mods):**
Yes, exactly. Keeping legacy content working was my #1 priority. That's why I didn't just write a generic demo. I built a dedicated CPU-only `.mesh` and `.skeleton` chunk parser from scratch. It reads the raw binary data of existing community mods (trucks, terrains, objects), bypasses Ogre entirely, and streams the data directly into BGFX persistent vertex buffers. The goal is 100% transparent backward compatibility: old mods load exactly as they are, but they render through a modern pipeline with zero Ogre overhead.

**2. Why not just upgrade to the latest Ogre / Ogre-Next?**
Upgrading to Ogre-Next sounds easy on paper, but it’s an architectural trap for a project like RoR:
* **Breaking Legacy Content:** Ogre-Next completely rewrote its internals (V1 vs V2 objects, HLMS shader manager). If RoR upgraded to Ogre-Next officially, **every single legacy mod would break instantly**. You would lose 15 years of community content unless someone converted every single mesh and material script manually.
* **The "Ready-Made Tools" Myth:** Ogre-Next does have modern rendering features, but it still forces you into its massive, heavy ecosystem. It doesn't give you fancy graphics "out of the box" without rewriting your whole codebase to fit their new pipeline anyway.
* **Why BGFX Wins:** BGFX is a lean API abstraction layer. It doesn't force a Scene Graph or a bloated material framework on you. Because I control the pipeline directly, adding modern graphic effects (like PBR materials, advanced screen-space reflections, or modern shadow maps) is actually *easier* and more lightweight. You write the shaders directly for the BGFX backend, instead of fighting Ogre’s massive runtime pipeline.

In short: Ogre-Next forces you to throw away old mods to get modern features. This BGFX approach protects legacy content while unlocking modern rendering performance.

 

[Kiwichek]

In practical terms, what will the real advantages be compared to the current version? Will mod creation be easier? For instance, will modifying a skin be better? Will resolutions be higher? Ultimately, will the game take up more hard drive space? Will the mods be larger in size?

Good practical questions, Fili. Here is how this architectural shift actually triggers a revolution for modders:

1. **Will mods or the game take up more hard drive space?**
**No, completely the opposite.** The game executable shrinks significantly because we throw away dozens of megabytes of fat, legacy Ogre DLLs. For your existing mods, the file size remains exactly the same. BGFX reads current textures and binary meshes through my custom parser without duplicating data or requiring any heavy re-exports.

2. **How this makes modding WAY easier (Blender integration & Assimp):**
This is where the real magic happens. Because the engine is completely free of Ogre's rigid `.mesh` binary constraints, we can now easily integrate **Assimp** (Open Asset Import Library) into the pipeline.
What does this mean in practice?
* **Direct 3D Formats:** The engine can theoretically read modern, universal formats like `.obj`, `.fbx`, or `.gltf` directly. No more wrestling with ancient, broken Ogre command-line exporters.
* **Blender Plugin:** Writing a direct `.truck` / 3D mesh sync plugin for Blender becomes a matter of just a couple of days. You could literally press "Export" in Blender and see your truck instantly update in the engine.
* **Visual Modding Tools:** Because BGFX pairs flawlessly with modern ImGui, creating a standalone, hardware-accelerated visual editor (a mini-Blender specifically for RoR trucks and nodes) is now completely feasible.

3. **Will resolutions be higher?**
BGFX doesn't artificially cap your texture sizes like the old Ogre setup often did due to runtime memory leaks or ancient DirectX 9 limits. If you feed the engine high-resolution 4K/8K textures, BGFX streams them efficiently through `bimg` without choking the CPU.

Ultimately, for a modder, your legacy files work exactly as they always did, but the door is now wide open for modern, seamless tools that make the old modding workflow look like the Stone Age.

 

[thomz92]

Sounds great to me - but again, what do I know

A couple more questions:
1. Would you have the time and be willing to contribute?
2. Either way, what would be the best path forward for the open source RoR community to move in this direction?

 

[Kiwichek]

Sounds great to me - but again, what do I know

A couple more questions:
1. Would you have the time and be willing to contribute?
2. Either way, what would be the best path forward for the open source RoR community to move in this direction?

Thanks for the interest! Actually, since my last post, I’ve made even more progress: I completely ripped out **OpenAL** and replaced the entire audio backend with **miniaudio** (single-header, lightweight, zero runtime issues). On top of that, I’ve successfully refined the CPU-side `.mesh` and `.skeleton` chunk parser—virtually 100% of community legacy assets are now parsing, transforming, and rendering flawlessly without a single Ogre dependency.

To answer your questions:

**1. Would I have the time and be willing to contribute?**
I do this strictly in my spare time as a hobby—sometimes the motivation is there, sometimes it’s not. To be honest, I wouldn't mind seriously committing to this project and pushing it forward. However, the licensing issue is what really suffocates me. Navigating the GPL limits and constraints on a massive core rewrite like this makes it highly discouraging to integrate into the current open-source structure right now. For now, it stays as a private experimental branch on my local machine.

**2. What is the best path forward for the open-source RoR community to move in this direction?**
If the current dev team wants to survive, they need to stop doing cosmetic updates and initiate an aggressive dependency-stripping phase. The biggest mistake is trying to swap out the renderer while the entire game logic is tightly coupled to it.

The ideal roadmap for the community should look like this:
1. **Isolate the Math & Types:** Re-engineer the codebase to completely banish Ogre math classes (`Vector3`, `Quaternion`, `Matrix4`, `ColourValue`) from the physics, simulation, and script engine. Replace them with standard, engine-owned value types.
2. **Write Bounded CPU Readers:** Stop relying on Ogre's automated resource systems. Write independent, bounded CPU parsers for legacy truck, material, and binary mesh formats so the simulation engine can process data without touching a graphics API.
3. **Decouple the Threads:** Separate the rigid simulation thread entirely from the frame presentation loop.

Once the simulation, file loading, and physics loop become 100% renderer-neutral, dropping in BGFX, SDL3, or any modern graphics API becomes a trivial task. Trying to upgrade Ogre or patch it while it's intertwined with every subsystem is a dead end.

 

[ohlidalp]

I currently have no plans to open-source the codebase or publish a repository...

Awww! And for a second there I thought I could finally retire.

Welp, I wish I had your energy level & attention span, then I'd go about it pretty much the same way. Indeed BGFX is one of the few C++ frameworks you can use with pride. My attention span is pretty bad (always been) so the best I can do is to iterate in bits. I actually gave this a thought 4 years ago and most of the points still hold - TLDR there's no rush ditching OGRE, better to iterate it out, keeping things stable in the process. I'm curious about so many things, but I'll refrain from quoting to manage vertical space:

• .mesh/.skeleton fileformat - You make it all sound so easy I've seen Ogre's code on this - fair amount of old bugs in the old binary formats commented and worked around there. Indeed we just use the bare bone functionality and none of the most bugged oldschool rendering feats, so you've likely didn't even hit any diverging paths youself. Still I wonder how much time and energy it took yo
• filesystem: what's the "standard filesystems" you said you used? Last time I checked fopen()/fstream couldn't handle Unicode paths on Windows. I suspect BGFX abstracts this away though. What platforms you've actually ran on anyway?
• OGRE ResourceGroups: I always thought a programmer will end up using or implementing something like this either way. How did you handle the media references in our mods? It's naked filenames that may point to either their own bundle, a skinzip, an addonpart or gamefiles. Lookup needed anyway I guess? Also our cache update is abysmally slow because all in-memory processing runs sequentially in our code, not because OGRE mandates it.
• SDL3: we have a port almost ready to go https://github.com/RigsOfRods/rigs-of-rods/pull/3431, dating back to https://github.com/RigsOfRods/rigs-of-rods/pull/2983
• caelum/skyx/hydrax: Their code is OOP-blabberish, but otherwise it's just setting up and managing meshes/textures/light sources, nothing icky. I'm a fan of HydraX's projected-grid approach, I wonder if your port uses that too? I'm currently in the process of making new sky from Caelum sources+media, mixing in SkyX's vclouds.
• visual editing: I actually tried to make a blender-like N/B editor as early as 2015, but I failed, my last attempt to ressurect that code was https://github.com/RigsOfRods/rigs-of-rods/pull/1357
• imgui: I'm the one who brought it here, bit by bit - my original rants https://github.com/RigsOfRods/rigs-of-rods/pull/1333
• imgui-powered editing: I'm well aware of the strengths and I use it whenever I can: https://github.com/RigsOfRods/rigs-of-rods/pull/2976
• myGUI: The most OOP-fetishist C++ I've ever seen, even mimicking C# delegates, I hate it with passion. Nonetheles I'm actually extending it's support for dashboards because that's what our modders work with. Fact is, even OGRE is guilty of C# fetishism by mimicking it's concept of Properties, but I digress.
• Cg shaders: this is only a roadblock because I can't work with shaders - I'm a self taught coder doing enterprise work for living, I only sort of learned them properly in recent months.
• nicemetal.cg with chrome: our chokepoint, I tried to replicate it within OGRE's RTSS extensible shader generator, but I ran into constraints. So you're saying you got the same visuals to work together with receiving depth shadows? Show me a screenshot. Of all the things you claim this single one is not trivial to believe.
• math bloat: I know, I was actually forced to introduce https://github.com/RigsOfRods/rigs-of-rods/blob/master/source/main/utils/Vec3.h#L27 to be able to test https://github.com/RigsOfRods/rigs-of-rods/pull/3354 in debug. OGRE is really more of a Python lib than C++ lib in this regard.
• scene graph: Very 80-s approach, but I'd say "meh" if it wasn't actually biting me in places far off the world origin: https://github.com/RigsOfRods/rigs-of-rods/pull/3034 - but given my limited capacity I opted for the ugly hack of `RoR::FalselyMovingMesh` which is actually a stationary mesh moved around it's origin via skeletal anim.
• Skeletal anim - I know, I know, we run on OGRE's default software skinning, and our flexbody/cab/flexwheel whatnot is all copypasta of the same degenerate case of skeletal animation. Been on my mind for long time, but never got tackled.
• Simbuffers - This one I'm curious about: did these survive in your port? The original codebase (see https://github.com/ohlidalp/rigs-of-rods/tree/retro-0407) had physics and visuals mixed together, I iteratively separated it but that's as far as I got. I'm hoping eventually the simbuffers become something of an "renderer integration layer".
• MessageQueue - the thing I'm most proud of introducing. Solved so many sequencing issues. I dare to assume you kept this?
• Blender plugins: I did have such aspirations... once https://github.com/ohlidalp/ror-blender/commits/master/
• Assimp: Well, duh! OGRE has it and we've had BgFX asset test (the scifi helmet prop) like 4 years ago? Screenshot is somewhere in Discord#development history. I see glfx as the future mesh format for rigs of rods.

In conclusion, your clear-cut migration to BGFX is no doubt the ideal approach, but nobody on this project has the capacity to go that route unfortunately. I think my approach is fairly similar in spirit, just adjusted for small iterations while maitaining the experience at all times. Note also that I put emphasis on physics and gameplay before visual fidelity, and our simulation leaves a lot to be desired, I'll follow up on that.

Anyway thanks for reaching out, it's always refreshing to see a fellow developer doodling on the codebase. Looking forward to your response.

 

[Kiwichek]

Hi @ohlidalp, thanks for the incredibly detailed and respectful response! Honestly, seeing a core dev who has been fighting this codebase for years analyze my PoC with this level of depth makes the entire 7-day sprint worth it.

To answer your specific points and doubts about how this architecture operates under the hood without Ogre:

**1. .mesh / .skeleton files & Diverging Paths**
You hit the nail on the head regarding the bugs in legacy formats. My parser doesn't try to fix Ogre's old bugs inside the mesh data; it bounds-checks chunk lengths explicitly. For example, legacy v1.30/v1.40 chunks with incorrect parent lengths are caught via explicit stream boundary tracking. By confining the parser strictly to reading raw vertex blocks, index streams, and basic skeleton hierarchies, it doesn't matter what OgreMain used to do at runtime—the raw float/index payloads are simply extracted and piped directly into persistent BGFX buffers.

**2. Filesystem & Unicode on Windows**
Standard `std::filesystem:ath` natively handles Windows `wchar_t` wide-character paths. For reading files from ZIP archives without standard file streams, the entire storage layer is backed by `miniz` running on raw byte buffers. Since the game loop only sees custom engine-owned memory streams, Windows-specific `fopen` Unicode issues disappear completely. BGFX isn't abstracting this; it's handled at the engine's custom IO layer before BGFX even sees the data.

**3. Resource Groups, Cache, and Media References**
I completely ditched `Ogre::ResourceGroupManager`. Instead, a custom `NativeResourceManager` indexes directories and ZIPs into logical groups using a fast internal string catalog. Mod media references are resolved lazily using normalized canonical paths. The "abysmally slow" cache issue you mentioned is bypassed because sequential in-memory lookups are avoided—the assets are indexed recursively at startup via explicit directory roots, making file discovery extremely fast.

**4. Sky, Clouds, Caelum, and Hydrax**
I completely purged Caelum, SkyX, and Hydrax from the build tree. Instead, I wrote a lightweight, camera-oriented atmosphere pass directly in BGFX that draws the horizon/zenith gradient and sun disc dynamically based on a custom daylight controller. For Hydrax's projected grid, I replaced it with a flat, engine-managed transparent mesh (`BgfxWater`) mapped to the terrain's `WaterLine`. Dynamic clouds are running on native procedural textures without the massive Ogre listener overhead.

**5. MyGUI, C# Delegate Fetishism & Dashboards**
I completely agree with you on MyGUI's OOP/C# mimicry design. To clean this up, MyGUI's old Ogre platform layer was replaced by an in-memory byte stream provider. Dashboard layouts are collected into clean ImGui/BGFX draw lists, rendered directly into a BGFX Render-To-Texture (RTT) framebuffer, and resolved by custom material overrides. No proxy textures, no runtime copies.

**6. Cg Shaders & nicemetal.cg**
Shaders are completely detached from runtime parsing. Everything is compiled offline via BGFX’s shaderc into API-specific blobs (Direct3D, SPIR-V). The rigid Cg runtime is gone. Material overrides handles blending, transparency, and diffuse color tinting directly inside the BGFX fragment shader pipeline, preventing the "constraints nightmare" you ran into with RTSS.

**7. Math Bloat & Scene Graph**
Replacing Ogre math was the most tedious part, but it's done. Physics, simulation, and inputs now use zero-overhead, engine-owned vector, matrix, and quaternion structs. As for the scene graph, I threw it away. Object world transforms are kept as simple flat records of position, orientation, and scale. No more allocating dummy `Ogre::SceneNode` pointers just to move static props or event boxes.

**8. Skeletal Anim, FlexWheels & SimBuffers**
The old copy-pasted copy of skeletal software skinning was completely refactored. The custom chunk reader pulls skeleton bone weights directly from the bytes, and a lean CPU-skinning loop blends the vertex normals/positions before pushing them to dynamic BGFX vertex buffers. SimBuffers are kept in a strictly isolated, renderer-neutral integration layer—the physics loop computes the raw node arrays independently, and the graphics pipeline updates the BGFX buffer transforms on a dedicated per-frame lifecycle.

**About the License (GPLv3):**
You asked what suffocates me about the license. Since RoR is GPLv3, any major structural rewrite like this legally demands that the source code of the entire fork be made public under the exact same license terms. Spending a week doing hard engineering to build a clean, proprietary-grade BGFX architecture just to be legally forced to open-source the whole repository under GPLv3 is a bit discouraging. That's why I'm keeping it as a private local hobby project for now.

But I'm really glad to see that the core team appreciates the direction. If anything, this PoC proves that the architectural roadmap is 100% possible if the codebase stops trying to fix Ogre and starts cutting it out completely.

 

[Tree]

is this vibe coded?

 

[thomz92]

Spending a week doing hard engineering to build a clean, proprietary-grade BGFX architecture just to be legally forced to open-source the whole repository under GPLv3 is a bit discouraging. That's why I'm keeping it as a private local hobby project for now.

On the other hand, what good is it doing sitting on your computer? @ohlidalp and the devs could use a breathe of fresh air I'm sure.

But no pressure. It's nice of you to offer some pointers! I appreciate the current dev effort as well.

 

[Kiwichek]

Awww! And for a second there I thought I could finally retire.

Welp, I wish I had your energy level & attention span, then I'd go about it pretty much the same way. Indeed BGFX is one of the few C++ frameworks you can use with pride. My attention span is pretty bad (always been) so the best I can do is to iterate in bits. I actually gave this a thought 4 years ago and most of the points still hold - TLDR there's no rush ditching OGRE, better to iterate it out, keeping things stable in the process. I'm curious about so many things, but I'll refrain from quoting to manage vertical space:

• .mesh/.skeleton fileformat - You make it all sound so easy I've seen Ogre's code on this - fair amount of old bugs in the old binary formats commented and worked around there. Indeed we just use the bare bone functionality and none of the most bugged oldschool rendering feats, so you've likely didn't even hit any diverging paths youself. Still I wonder how much time and energy it took yo
• filesystem: what's the "standard filesystems" you said you used? Last time I checked fopen()/fstream couldn't handle Unicode paths on Windows. I suspect BGFX abstracts this away though. What platforms you've actually ran on anyway?
• OGRE ResourceGroups: I always thought a programmer will end up using or implementing something like this either way. How did you handle the media references in our mods? It's naked filenames that may point to either their own bundle, a skinzip, an addonpart or gamefiles. Lookup needed anyway I guess? Also our cache update is abysmally slow because all in-memory processing runs sequentially in our code, not because OGRE mandates it.
• SDL3: we have a port almost ready to go https://github.com/RigsOfRods/rigs-of-rods/pull/3431, dating back to https://github.com/RigsOfRods/rigs-of-rods/pull/2983
• caelum/skyx/hydrax: Their code is OOP-blabberish, but otherwise it's just setting up and managing meshes/textures/light sources, nothing icky. I'm a fan of HydraX's projected-grid approach, I wonder if your port uses that too? I'm currently in the process of making new sky from Caelum sources+media, mixing in SkyX's vclouds.
• visual editing: I actually tried to make a blender-like N/B editor as early as 2015, but I failed, my last attempt to ressurect that code was https://github.com/RigsOfRods/rigs-of-rods/pull/1357
• imgui: I'm the one who brought it here, bit by bit - my original rants https://github.com/RigsOfRods/rigs-of-rods/pull/1333
• imgui-powered editing: I'm well aware of the strengths and I use it whenever I can: https://github.com/RigsOfRods/rigs-of-rods/pull/2976
• myGUI: The most OOP-fetishist C++ I've ever seen, even mimicking C# delegates, I hate it with passion. Nonetheles I'm actually extending it's support for dashboards because that's what our modders work with. Fact is, even OGRE is guilty of C# fetishism by mimicking it's concept of Properties, but I digress.
• Cg shaders: this is only a roadblock because I can't work with shaders - I'm a self taught coder doing enterprise work for living, I only sort of learned them properly in recent months.
• nicemetal.cg with chrome: our chokepoint, I tried to replicate it within OGRE's RTSS extensible shader generator, but I ran into constraints. So you're saying you got the same visuals to work together with receiving depth shadows? Show me a screenshot. Of all the things you claim this single one is not trivial to believe.
• math bloat: I know, I was actually forced to introduce https://github.com/RigsOfRods/rigs-of-rods/blob/master/source/main/utils/Vec3.h#L27 to be able to test https://github.com/RigsOfRods/rigs-of-rods/pull/3354 in debug. OGRE is really more of a Python lib than C++ lib in this regard.
• scene graph: Very 80-s approach, but I'd say "meh" if it wasn't actually biting me in places far off the world origin: https://github.com/RigsOfRods/rigs-of-rods/pull/3034 - but given my limited capacity I opted for the ugly hack of `RoR::FalselyMovingMesh` which is actually a stationary mesh moved around it's origin via skeletal anim.
• Skeletal anim - I know, I know, we run on OGRE's default software skinning, and our flexbody/cab/flexwheel whatnot is all copypasta of the same degenerate case of skeletal animation. Been on my mind for long time, but never got tackled.
• Simbuffers - This one I'm curious about: did these survive in your port? The original codebase (see https://github.com/ohlidalp/rigs-of-rods/tree/retro-0407) had physics and visuals mixed together, I iteratively separated it but that's as far as I got. I'm hoping eventually the simbuffers become something of an "renderer integration layer".
• MessageQueue - the thing I'm most proud of introducing. Solved so many sequencing issues. I dare to assume you kept this?
• Blender plugins: I did have such aspirations... once https://github.com/ohlidalp/ror-blender/commits/master/
• Assimp: Well, duh! OGRE has it and we've had BgFX asset test (the scifi helmet prop) like 4 years ago? Screenshot is somewhere in Discord#development history. I see glfx as the future mesh format for rigs of rods.

In conclusion, your clear-cut migration to BGFX is no doubt the ideal approach, but nobody on this project has the capacity to go that route unfortunately. I think my approach is fairly similar in spirit, just adjusted for small iterations while maitaining the experience at all times. Note also that I put emphasis on physics and gameplay before visual fidelity, and our simulation leaves a lot to be desired, I'll follow up on that.

Anyway thanks for reaching out, it's always refreshing to see a fellow developer doodling on the codebase. Looking forward to your response.

i droped https://github.com/Kiwichek/rigs-of-road

 

[thomz92]

i droped https://github.com/Kiwichek/rigs-of-road

WOW! Thank you! Excited to see what this does to the project.