I would quite like to put a poll together to see what features developers would like to see implemented next in Ogre 2.x. I have been working on bits a here and there, one of which is the particles systems, but nothing really usable yet. So if there was some clear direction from the community it may help motivate me to finish these sort of things. Also it would just be useful to see what the community need!

Anyway ill start a list here, once its got enough stuff in it ill create a poll, so please add anything you may need/want now or in the distant future

GPU Particles systems

GUI System

Reverse depth buffers

Volumetric lighting

Per pixel reflection probes

Area lights (I have not looked into the recently added 'Fake' area lights)

Deferred decals

Android support (Although not even Epic can get this right!)

Order Independent Transparency

Many of these can be implemented as samples of how to do a certain technique using ogre, but do shape the engine as a whole. For example to have GPU particle systems, requires some core engine changes.

Last edited by al2950 on Mon Jul 22, 2019 12:21 pm, edited 1 time in total.

Thank you for your input. I am a little curious of a couple of things. When you say Custom HLMS implementation tutorial, is the Terrain sample not good enough or missing specific things, or perhaps over complicated? Admittedly its not advertised as a custom HLMS sample, but it is!

Your second option should actually be very easy it just requires adding another option to the sort enum and storing a function pointer in RenderQueue

... is the Terrain sample not good enough or missing specific things, or perhaps over complicated? Admittedly its not advertised as a custom HLMS sample, but it is! ...

Whoop, I looked at its name, and thought it is a terrain editor.
Sorry for my neglect, I will need time to study the sample. I have edited my previous post.
Thanks for the information! You are a good admin of this thread.

Integration of a gltf 2.0 importer in OgreMain with UnitTests/Samples to enforce regular compatibility updates.

Volumetric Lighting

GPU particles

Android support

Completion and integration of the 2013 GSOC resource system redesign.

Lastly, integration of a gltf 2.0 importer in OgreMain with UnitTests/Samples to enforce regular compatibility updates.

I'm not going to give it a bullet point, because I am very ignorant to the actual process with which this takes place, but I've been noticing more and more games using many materials on individual models with great performance. I've heard some (namely from the devs of Star Citizen in ATV/RTV) say they are blending the materials together somehow. Whatever that magic is, I'd like that. But maybe Ogre already has that in some form. I don't know.

Oh, did I mention integration of a gltf 2.0 importer in OgreMain with UnitTests/Samples to enforce regular compatibility updates?

I read a bit about Google's new graphics engine Filament (https://google.github.io/filament/Filament.md.html).
There are some nice articles about pbs/materials etc.
Especially the chapter 2.3 Cloth model is interesting... This feature for PBS would be really cool!

I'm not going to give it a bullet point, because I am very ignorant to the actual process with which this takes place, but I've been noticing more and more games using many materials on individual models with great performance. I've heard some (namely from the devs of Star Citizen in ATV/RTV) say they are blending the materials together somehow. Whatever that magic is, I'd like that. But maybe Ogre already has that in some form. I don't know.

This could be talking about several things. Firstly just PBS, which we already have, as it allows you to define a wide range of different material using the same shader, and so you can combine multiple meshes together that previously required multiple shaders and therefore multiple draw calls to render.

Secondly it could be talking about blending different BRDF's together. This is less likely but an example is rendering clear coat materials that have a 'clear coat' layer on top of a base material

I read a bit about Google's new graphics engine Filament (https://google.github.io/filament/Filament.md.html).
There are some nice articles about pbs/materials etc.
Especially the chapter 2.3 Cloth model is interesting... This feature for PBS would be really cool!

This is the best documentation I have seen on PBS... ever! Different BRDF's are not hard to add to Ogre. Just need to make sure users understand that different BRDF's means more shader permutations, which means more state changes, more draw calls and therefore less performance!

This is the best documentation I have seen on PBS... ever! Different BRDF's are not hard to add to Ogre. Just need to make sure users understand that different BRDF's means more shader permutations, which means more state changes, more draw calls and therefore less performance!

Wow! I'm interested in different BRDF too, in particular cloth (section 3.11) and clear coat(section 3.. However, by only implementing BRDFs you only get direct lighting. In most literatures I can find (like filament, Frostbite's course notes in 2014 and Unreal's course notes in 2013), specular reflection of light probes is calculated with pre-filtered importance sampling and split-sum approximation, which is not implemented in Ogre (is Ogre using a simplfied appraoch of doing IBL?).

I don't know how much it affects the render quality, but since it's mentioned a lot of times, it would be great if anyone can implement them (each BRDF needs to be implemented differently, as described in filament) for Ogre. Since you mentioned "per-pixel reflection", I think you might be interested too

Regarding Screen Space Decals:
that's pretty exiting =)
are they cheap? can I use 100s.. like for bullet holes?

I don't know, the code is already working since yesterday so you can just try it!

We're using Forward+ to get the Decals into the shaders, so the same rules apply:

GPU wise, one big decal costs as much as a many small decals distributed across the screen.

CPU wise, more decals = more time culling, but it still helps a lot if they're small.

Different settings for ForwardClustered (width, height, num slices) may give you better/worse performance results, depending on your scene and hardware

Debug mode has a high culling cost in CPU (only Forward Clustered is supported), however it gets better if you enable threading instead of using a single thread. Alternatively you could patch Ogre's build pipeline to force OgreForwardClustered.cpp to be compiled with optimizations even in Debug mode. See override flags for single files.

Decals have width, height and depth, yet decals are 2D. The depth controls how many objects it affects. Try to make them as thin as possible

The math behind it isn't very expensive, so it should run much better than lighting.
In terms of performance cost, emissive < normal < diffuse; i.e. having emissive alone is the cheapest operation. You can have any or all of them enabled depending on what you want to do.
These are global, so e.g. enabling normal mapping for Decals means all decals will pay the price.

Per-pixel reflection probes in Ogre 2.2 are coming together nicely.
In terms of internal management they're SO MUCH EASIER. I had to move some code out of ParallaxCorrectedCubemap into a new class called ParallaxCorrectedCubemapBase, and then create ParallaxCorrectedCubemapAuto for per-pixel cubemaps, which is basically ParallaxCorrectedCubemap with almost all the code removed!

These are WIP pics:

There is no fading (fading params must be user defined, although it can be automated), thus the seams are very noticeable.
Notice that even after gradient/fading/blending gets implemented, sometimes the misalignment is going to be there, just not noticeable for the untrained eye

The following pic shows the lack of fading/blending more exaggerated:

There are 3 probes (this is just a slightly modified LocalCubemaps sample) in total you will see 4 lines:

Where probe 0 meets probe 0 & probe 1 active at the same time

Where probe 0 & 1 at the same time meet probe 1

Where probe 1 meets probe 1 & probe 2 active at the same time

Where probe 1 & 2 at the same time meet probe 2

Again, this is only noticeable because there's no blending going (well, there is but it's broken)

There are a few bugs remaining, most noticeable the edge of the windows on the right are showing jarring green/white aliasing pattern. This is caused by the broken blending and will be fixed soon.

Amazing work!
I have a concern: it seems like it's only going to work with parallax corrected probes?
To me the idea would be that you can place any probe and set the influence area at you will, and the parallax correctedness should be just a "checkbox" if I don't set it true it's just a normal spherical probe. I am pretty sure that's how it works in other engines