Seeking assistance in evaluating OGRE-Next as a replacement rendering engine for an existing VR project?

[kaestralblades]

Hi there! I hope I'm posting in the right place. I am part of the community for a creative/social VR platform called Resonite:

I am posting here as part of a community-driven research project to search for and adopt a new viable rendering engine for the platform. I am taking part in the crowdsourcing efforts in finding information on what fulfills and doesn't fulfill the game's technical requirements, which are a list put together in a previous also community-driven phase of this research project.

Right now, Resonite runs on a split architecture, where a custom C# game engine (FrooxEngine) is communicating raw render data through an IPC/shared memory mechanism to a very bare Unity process to render to the screen. This is somewhat of a stopgap solution, and while the split process architecture is being kept, we (the development team and the community, the latter of which I am part of) are looking for a new rendering engine as a home.

The research project phase to find viable candidates has now opened and I am currently working on a candidate evaluation document. This is a list of requirements with information on what is currently supported by a candidate rendering engine and what is not, which you can see here (anything with a question mark or a chat bubble emoji are things that we still need to evaluate, for reference):

https://github.com/Yellow-Dog-Man/Rende ... re-next.md

I'm posting here in hopes there will be those more familiar with OGRE-Next willing to help look over my work here, and to see if there's something I've missed? Any input is hugely appreciated, and very grateful in advance for any eyes that can assist me!

[bishopnator]

I think, the decision is more in direction what you are willing to implement and how much code to write. The ogre (and ogre-next) has no strong limitations which will restrict the usage in any project, the question is more about the amount of new code which one must write. If the features available by ogre out of the box are not sufficient, then you will end up with writing a lot of new code. First check if HlmsPbs (HlmsUnlit) is exactly what you want. If the implementation doesn't fulfill your needs and you think you need completely new HLMS implementation, then the complexity grows a lot )there is a possibility of copying existing HLMS implementations and just tweak them to your needs).

Check also the compositors - they are very powerfull, but IMHO too complex if you need certain amount of dynamism which is hard to fulfill with the compositor scripts.

DX12 support is something which probably won't come to the ogre as there is vulkan and according to some posts, the dx12 won't bring anything special compared to vulkan.

Just to get a brief summary - if you can live with built-in features of ogre and writing the scripts, it should be relatively easy to integrate and use the ogre. Otherwise prepare yourself that integrating ogre will take longer time as a lot of new code will be needed to write. The ogre is not a game engine, it is rendering engine usable for any kind of applications which need rendering through gpu.

[dark_sylinc]

What bishopnator said. What I can add:

Foveated rendering support
Radial density mask and foveated VR compute shader assets are present. OpenXR foveation, eye-tracked foveation, and VRS-based foveation were not found.

This is accurate, though some have reported issues with the RDM on OpenGL (looks like a race condition). The problem with VR is that right now remains a niche and advanced features like foveated and VRS depend a lot on the target hardware. And VR also happens to vary a lot (running on a Quest is a whole world of difference vs running from a GeForce 5090). It's not just speed, it's feature and driver stability.

And without someone to pay to maintain these features or the feature becoming popular enough to be everywhere; there is no interest in adding or maintaining these features.

But on the other hand, you can easily get higher performance on OgreNext without any of those fancy features compared to a Unity engine based project that uses those features, because Unity has severe bottlenecks elsewhere.

I'm not saying those features aren't important, but I'm saying context matters.

Now, onto the list:

Double buffering support (cameras see the contents of their own render texture from previous frame)

This is wrong. We have such support. But you won't find it in "Camera". You will find it in the Compositor. The Postprocessing sample "Motion Blur" has access to the content of what was rendered the previous frame.
The HDR sample also does the same, though it's just for accessing a 1x1 texture which contains the luminance calculated the previous frame (for gradual eye adaptation).

Custom renderables and compositor passes make this plausible, but a clean external sorted draw-command submission API was not found.

You can implement your own custom CompositorPass where you can submit all the draw commands you want. Though it's not newbie friendly, and whether that's suits your needs or not, I don't know.

See OgreCompositorPassImgui.cpp in Component which asks IMGUI what to render and then in mImguiManager->drawIntoCompositor() manually submits commands.

OGRE-Next 2.3 documentation describes HLMS auto-instancing and notes that InstanceManager is mainly useful for very large instance counts with the same mesh and material: https://ogrecave.github.io/ogre-next/ap ... ncing.html. Current HLMS paths still include instancing support. Per-object data buffers and texture buffers exist, but arbitrary Resonite-style per-instance material variation would need integration work.

This is wrong. The link to the documentation posted says:

On Ogre 2.1; this section has become almost irrelevant as 2.1 can auto instance meshes automatically; and apply instancing even if the meshes are using different materials

But then the AI looked at the legacy parts and concluded we don't. I'm surprised about this because one, because one of our key features is that our auto instancing is very powerful, flexible and efficient.

TL;DR: OgreNext supports auto instancing for multiple meshes and multiple materials. There are some limitations but those typically boil down to "a different shader would be needed", "different vertex formats require to split the draw call" or "you have so many materials/textures that they didn't fit in a single pool".

Cheers