V2 Lod implementation request.

[Lax]

Hi dark_sylinc,

I'd like to raise a feature request regarding the MeshLodGenerator. The current MeshLodGameState sample notes that the mesh must be in v1 format because the MeshLodGenerator hasn't yet been ported to v2 interfaces, with the suggested workaround being a v1 → generate LODs → v2 round-trip conversion.

In my engine (NOWA-Engine, built on Ogre-Next) I've made a deliberate architectural decision to use Ogre::Item and v2 meshes exclusively — v1 is completely gone from the pipeline. The v1 round-trip workaround is therefore not viable for me: it introduces significant load-time overhead, complicates the asset pipeline, and reintroduces a v1 dependency I've specifically eliminated.

What I'd like to request is native MeshLodGenerator support directly for v2 meshes, without requiring any conversion step. Concretely:

• Port the MeshLodGenerator to operate on v2 VertexArrayObject / VertexBufferPacked structures natively
• Allow LOD levels to be generated and stored directly on an Ogre::MeshV2 instance
• Ideally expose this through the same or a parallel API to the existing MeshLodGenerator so existing tooling patterns transfer cleanly

I'm happy to test against a development branch if that's useful. Is this something on the roadmap, or would a community contribution be the right path here?

Thanks

Best Regards
Lax

[dark_sylinc]

That sounds cool!

Is this something on the roadmap, or would a community contribution be the right path here?

Community Contribution.

Start with a draft PR so that critique can start early and avoid any critical blocker.

[Lax]

Hi @dark_sylinc,

Update on this: the draft PR is up at https://github.com/OGRECave/ogre-next/pull/580. Quick summary of what it does and what I found along the way:

Two new classes (LodInputProviderMeshV2, LodOutputProviderMeshV2) slot into the existing LodInputProvider/LodOutputProvider strategy pattern, so MeshLodGenerator can read/write directly against a v2 Mesh's SubMesh Vaos — no v1 mesh involved anywhere.
Turns out the runtime side (camera-distance LOD switching for Item) already works end-to-end for v2 — I'd assumed otherwise partway through and want to flag that I was wrong about that, in case it's useful context. The actual gap was purely on the generation side.
MeshLodUpgrader now generates LOD for v2-native source meshes too, not just v1.
Added a sample (Sample_MeshLodV2) comparing a procedurally-built v2 mesh against Sinbad (v1-imported-then-LOD-generated-natively) side by side.

Three things I'd specifically like your read on before going further:

LodConfig's API shape — I added a parallel meshV2 field rather than changing the existing mesh field's type, to avoid breaking the v1 API. Open to a different shape if you'd prefer.

Manual (mesh-swap) LOD levels and independent (non-shared) shadow-mapping Vaos are explicitly unsupported for the v2 path in this first pass — both fail loudly rather than silently doing the wrong thing. Worth scoping into a follow-up, or should this PR cover them?

Mesh::removeLodLevels() was previously a no-op stub (commented-out body) — I implemented it for real since MeshTool's "drop LOD" option needs it to actually work. Wanted to flag that explicitly since it's existing dead code I'm reviving, not something I added net-new.

Here the result:

Best Regards
Lax

[Lax]

Hi all,

so how does it work?
I created a PR a while ago.
Does it come onto an list of topics?

Best Regards
Lax

[dark_sylinc]

I was gonna do that today. Then I forgot. "Was I forgetting something? AHA!" Thanks for the reminder

[Lax]

Hi @dark_sylinc,

i fixed, what you mentioned. So i think you can merge that into Ogre-Next.

Best Regards
Lax

[Lax]

Hi @dark_sylinc,

what is the state of this task?
I adapted like you asked and since August nothing happened. The last state is:

No conflicts with base branch
Changes can be cleanly merged.

https://github.com/OGRECave/ogre-next/pull/580

Best Regards
Lax

[dark_sylinc]

I thought I had already merged it.

I looked at the PR and the reason was a failed clang format. Do you know how to run it or shall I do it? (go to cd .github/workflows/ then python3 run_clang_format.py --fix_broken_files it assumes clang-format-18 is installed, if you have in a specific folder then just edit the python script to point to an absolute path)

[Lax]

Hi @dark_sylinc,

it would be nice, if you could run it. My ogre source is out of date i think.

Best Regards
Lax