[News] Ogre ecosystem roundup #6

[paroj]

https://www.ogre3d.org/2020/07/26/ogre- ... -roundup-6

[frostbyte2]

impressive , good job
regarding the unified-shader stuff- it reminds me of a project i once had in mind to integrate( one of many )
http://synthclipse.sourceforge.net/user ... fragx.html
does this mean i can import shader-toy creations directly to ogre using synthclips shader-toy converter?
also, since you've mention trying to be compatible with bgfx i'm wondering, whats actually stopping ogre from getting a bgfx backend? ( beside pride mixed with nih syndrome )

regarding ogre's road-map , any intention of pushing ogre 1.x rendering techniques further?
i'm not a python expert but i wonder how hard would it be to integrate https://github.com/tobspr/RenderPipeline
panda3d looks very similar to ogre, ogre 1.x might gain advanced rendering without too much hassle

as always, thanks for the hard work, much much appreciated

[paroj]

impressive , good job
regarding the unified-shader stuff- it reminds me of a project i once had in mind to integrate( one of many )
http://synthclipse.sourceforge.net/user ... fragx.html
does this mean i can import shader-toy creations directly to ogre using synthclips shader-toy converter?

from a quick glance of that page: yes. Ogre supports #include in GLSL since 1.12.0 and our preprocessor is more powerful than this:
http://synthclipse.sourceforge.net/user ... essor.html

as it does support macros.

also, since you've mention trying to be compatible with bgfx i'm wondering, whats actually stopping ogre from getting a bgfx backend? ( beside pride mixed with nih syndrome )

no, its mainly these two reasons. Actually I was thinking about going for bgfx to get D3D12 & Vulkan backends, given how involved implementing them is.
I only have two concerns:

• the NIH in Ogre makes it pretty self-contained. bgfx might seem smaller by looking at the main source code, but then there is this: https://github.com/bkaradzic/bgfx/tree/master/3rdparty. The Metal shader generation is then:
  GLSL-(ish) -shaderc-> GLSL -glslang-> SPIRV -spirv-cross-> Metal
• Closely related to the above: pride. We need to figure out, how to integrate the bgfx concepts with the Ogre concepts. Do we want to fulfill the promise of bgfx of GLSL everywhere, or is a Metal specific RTSS backend the better way? (Do Ogre users actually want to write shaders manually at all?)

But we could certainly take the low-level buffer/ texture management code from bgfx. So if anybody comes along with a bgfx RenderSystem I would happily merge it. However, personally I prefer to improving the existing Ogre1 features and meanwhile wait and observe whether bgfx or ogre-next-vulkan is the way to go. (Maybe even use one of the OpenGL on Vulkan layers)
Currently Vulkan does not give us much, if you do not play the buzzword bingo. Ogre1 performance would benefit much more by improving batching. However, I have the feeling that most of Ogre1 users, dont hit any performance barriers anyway..

regarding ogre's road-map , any intention of pushing ogre 1.x rendering techniques further?
i'm not a python expert but i wonder how hard would it be to integrate https://github.com/tobspr/RenderPipeline
panda3d looks very similar to ogre, ogre 1.x might gain advanced rendering without too much hassle

Did you see the Filament shader support in the last roundup:
https://www.ogre3d.org/2020/06/12/ogre- ... -roundup-5

Generally I would rather follow Filament than RenderPipeline as the latter requires OpenGL 4.3, while Filament targets GLES3 and thus is closer to Ogre1, which still supports GLES2.
Basically, RenderPipeline is just a python based shader generator, so you probably can get it running with ogre by just grabbing the final shaders and forwarding them into Ogre. Note though, that it uses some panda primitives which would be a PITA to replace https://github.com/tobspr/RenderPipelin ... ces.py#L29

In the end, we do something similar with the Filament shaders. However, their C preprocessor based architecture makes them more usable for us.