[2.x] Wish list

[al2950]

Hi all

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
• Velocity buffer (eg for motion blur)
• 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.

[xrgo]

My wishlist in priority order:

• Every VR optimization known to mankind
• GPU particles (I need nice and cheap rain asap xD)
• Per pixel reflection probes
• Android Support
• Volumetric lighting (a very cheap one)

[hyyou]

My wishlist :-

• Custom HLMS implementation tutorial : create PBS from scratch
• a way to let me sort Ogre::Item myself (e.g. for custom depth-sort)

Edit: strike out. Thank to al2950 for the information (2 post below). XD

[rujialiu]

My wishlist:

• Deferred decals
• Per pixel reflection probes
• Temporal Anti-Aliasing(TAA), which requires Velocity buffer
• Improve Screen-Space Reflection with TAA
• Volumetric lighting
• Subsurface scattering (SSS)
• Dedicated Cloth BRDF

[al2950]

My wishlist :-

• Custom HLMS implementation tutorial : create PBS from scratch
• a way to let me sort Ogre::Item myself (e.g. for custom depth-sort)

Hi

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

[hyyou]

... 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.

[TaaTT4]

My two cents (in no specific order):

• Velocity buffer
• TAA
• Reversed depth buffer
• Auto calculation of optimal render distance (eg based on pixel coverage)
• VR optimizations

[Mako_energy]

• 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?

[Lax]

Hi all,

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!

Best Regards
Lax

[al2950]

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!

[rujialiu]

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

[rujialiu]

My two cents (in no specific order):

• Velocity buffer
• TAA
• Reversed depth buffer
• Auto calculation of optimal render distance (eg based on pixel coverage)
• VR optimizations

I'm interested in TAA too. But there are so many literatures so I'm not sure which one suites Ogre best. Do you have any suggestions? Personally I like this one: https://github.com/playdeadgames/temporal

[TaaTT4]

I'm interested in TAA too. But there are so many literatures so I'm not sure which one suites Ogre best. Do you have any suggestions? Personally I like this one: https://github.com/playdeadgames/temporal

I'm sorry but I didn't have time to study the subject in yet (for the moment, I'll stick with MSAA + SMAA).
Thanks for sharing that link, I didn't know it! Other interesting resource about the topic are https://assetstore.unity.com/packages/e ... tack-83912 (if you want to lurk a bit from the latest iteration of Unity) and https://developer.nvidia.com/postworks for a pre-built solution.

[rujialiu]

I'm sorry but I didn't have time to study the subject in yet (for the moment, I'll stick with MSAA + SMAA).
Thanks for sharing that link, I didn't know it! Other interesting resource about the topic are https://assetstore.unity.com/packages/e ... tack-83912 (if you want to lurk a bit from the latest iteration of Unity) and https://developer.nvidia.com/postworks for a pre-built solution.

Thanks! We're also using MSAA + SMAA now. I've studied a bit on this subject, but not enough to implement it

[spookyboo]

• Divide Ogre even more into a small core + (supported) components (resource system, ...)

[al2950]

• Divide Ogre even more into a small core + (supported) components (resource system, ...)

Ambitious! I think you might be talking about a Ogre V3.x!

[xrgo]

-ScreenSpace Decals

... omg! https://bitbucket.org/sinbad/ogre/commi ... 2-1-decals

[rujialiu]

More wishes:

• LTC-based area lights
• Lights with IES profiles
• Improved GI

By IES lights I mean this:
https://docs.unrealengine.com/en-us/Eng ... htProfiles

By LTC-based area lights, I mean this:
https://eheitzresearch.wordpress.com/415-2/
The link above is the original paper. It's then further optimized and solved many practical issues:
https://blog.selfshadow.com/publication ... -advances/
In 2017 it even supports disks and line lights, but I only need quad lights for now

The math may look scary but the implementation is short.

For GI, currently we have Instant Radiosity but Irradiance Volumes, but we want better fully-dynamic GIs. Good candidates include:

• Light Propagation Volumes
• Many-lights GI
• Voxel Cone Tracing

Here "Many-lights GI" includes many techniques, including RSM, ISM etc.
A good introduction: http://drz.disneyresearch.com/~jnovak/p ... index.html

[dark_sylinc]

Regarding Screen Space Decals:




Now what's missing is to port these shaders to HLSL & Metal, merge with 2.1 and then port to 2.2.

[rujialiu]

Yeah!!!

[xrgo]

Regarding Screen Space Decals:

that's pretty exiting =)
are they cheap? can I use 100s.. like for bullet holes?
can they be attached to dynamic objects? (like a car, and if the car moves the decal will stay attached)
cheers!!

[dark_sylinc]

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:

1. GPU wise, one big decal costs as much as a many small decals distributed across the screen.
2. CPU wise, more decals = more time culling, but it still helps a lot if they're small.
3. Different settings for ForwardClustered (width, height, num slices) may give you better/worse performance results, depending on your scene and hardware
4. 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.
5. 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.

can they be attached to dynamic objects? (like a car, and if the car moves the decal will stay attached)
cheers!!

Decals derive from MovableObject, which means they can be attached to SceneNodes, thus can move, rotate and translate.
They can also be SCENE_STATIC or SCENE_DYNAMIC.

[TaaTT4]

I would like to add another entry to my presents list for dark_SANTACLAUS_sylinc
Hashed alpha testing: https://casual-effects.com/research/Wym ... proved.pdf

[dark_sylinc]

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:

1. Where probe 0 meets probe 0 & probe 1 active at the same time
2. Where probe 0 & 1 at the same time meet probe 1
3. Where probe 1 meets probe 1 & probe 2 active at the same time
4. 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.

[xrgo]

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