Page 1 of 1


Posted: Sat Apr 23, 2016 9:35 pm
by white_waluigi
The JSON update:

Windows (Should run right out of the box): ...

Linux (Should run right out of the box): ...




Its almost been a year hasn't it? Well I barley had time to work on it, it has been a stressfull time. I will try to update a lot more frequent from now on, I promise. But I did implement quite a bit I think:

-JSON Materials:

The main feature I think. Users are able to create a list of all necessary ressources for the material they wish to create. All textures, Parameters, Settings, etc. Then they can combine them in a piece of shadercode to create a completely new effect. In the Demo you will find some basic water, a glowing statue and creepy mask that can only bee seen through a mirror.

-Shadow improvements
-Lots of bug fixes
-bigger Demo world to show off the Directional PSSM Shadows
-Fully dynamic Datablocks

Next I'll probably work on Screen Space Reflection, imporving JSON materials, fancier Demo, optimization and the ability to create custom light materials, so users can create all kinds of crazy lighting effects. Also some decent documentation.

Also I have uploaded the Source code to github now, so people can look at the progress or lack thereof in real time. If anybody is interested, I can make the code build able with CMAKE, so others can experiment with the code.

I'm looking forward to your feedback!

***********************February 2017******************************************************

After way too long, here's the newest version of my Deferred Shading HLMS along with a new Demo.

Here's the Windows version:!eZ42XLYC!IUqhgMF-n3nK ... wXcqreaCjA

Here's the Linux Version +Source!SUpV2DYY!C33-W0U7BLbc ... JoGDPsjoLc


implemented features

- Dynamic materials
- Light geometry based Deferred Shading
- Normal, Specular, Alpha, Diffuse and Glowmaps
- Custom shader code for Materials
- Dithering Transparency
- Debug Views
- Shadows (not finished)
- Configurable Textureunits (partial)
- Animated Textureunits (partial)
- Antialiasing (FXAA that doesn't suck)
- Reflectivity (Spheremaps for now)

Missing features

- Custom Material Templates
- Rendering other HLMS Materials afterwards (rebuilding the depth Buffer)
- Full Vertex Shader (its pretty basic right now)
- More Lighting Techniques
- Light Materials
- Unreal Style Material Propertys with custom shader code
- DX support

Simple filtered depth shadows. Uses HLMS standard SHadow System.Most of my time went into this, since it was a bit of a pain to figure out how to make it work.
There are a few Problems that I have with Shadows right now. I can't figure out how to make it work with Alpha Textures, since HLMS-Shadowcasters don't have any UVs and I can only use 1 Material for every shadowcaster. Also I coldn't make native depth textures work like in HLMS-PBS, but I'l figure that one out in time. And the filtering is broken on Intel GPUs, and I have no Idea why.


Simple FXAA post processing, nothing special really, looks good enough. I'm thinking of linking it to Ogres FSAA, so if that one isn't 0, the FXAA gets enabled, since FSAA with DS is a pain in the ass.

Texture Units

If extended the Texture Unit with some basic animation features, like translating the Texture Matrix, rendering animations with multiple Textures.
You can also choose which UV the Texture gets mapped to.


Basic Spheremap that gets mixed with the diffuse component.

Things that are planned for the immediate future

More advanced Lighting

The current lighting is basicly the same I used for my old Deferred Shading project, It really needs to be updated, I'll probably steal a lot of code from HLMS_PBS

Ligth Materials

It becomes clear that the Lights need to be more configurable, to allow for things like Volumetric Lighting, Sunrays, Gobol lighting, HDR, Shadow Bias, Shadow Filtering, Shadow depth etc...
I'll probably implement it as soon as I figured out how to make JSON Materials work. I'll probably use getUserAny for this

JSON Materials

I think JSON is the best format to use for the Materials and Later, material templates. Probably the next thing I'll work on

And the rest of the implemnted section

Known Bugs:

-Crash on Exit
-Shadows broken on Intel Cards
-won't run on <16.04 because of boost 1.58
-Petter Panning on a lot of objects in the Demo

If you have any ideas, questions or Bugs, please report them in this thread

**********************23 Apr 2016*********************************************

Heres the Demo for my HLMS implmentation of Deferred Shading. I know it took forever (I wanted to be this far back in November), mainly because I kept running into Problems and starting from scratch twice.
But I think I added some interesting concepts for dynamic and expandable Materials, which Im going to explain further down in this thread.

Also my HLMS still needs a lot of work, this is just a little Demo of how far I got.

implemented features

- Dynamic materials
- Light geometry based Deferred Shading
- Normal, Specualr, Alpha, Diffuse and Glowmaps
- Custom shader code for Materials
- Dithering Transparency
- Debug Views

Missing features

- Shadows
- Custom Material Templates
- Configurable Textureunits
- Animated Textureunits
- Antialiasing
- Rendering other HLMS Materials afterwards (rebuilding the depth Buffer)
- Full Vertex Shader (its pretty basic right now)
- More Lighting Techniques
- Reflectivity (SSR and/or Cubemaps)
- Unreal Style Material Propertys with custom shader code
-DX support

I might add more stuff here later

Here are some Screenshots:

Heres the Download Links (Please report Bugs, they are debug builds for the moment, I have a nasty reallease bug atm, also, crash on exit, Linux versions includes full source)

Windows:!SwQkzJjT!BAkglgoStTfm ... C6w6u6HrZE
Linux+Source:!6g5SzDJD!l3P8DxmuRgq7 ... HK5X1rAoZE

Heres some Info on the Stuff thats already here:

Light geometry based Deferred Shading

Everytime a lght geds added, LightManager will create a CustomRenderable called a DSLight. This DS Ligth will have have a Mesh that stretches over any area that the corresponding Light could reach. This custom renderable will receive a standard DS Datablock with the LightDatablock Template . Within this, it will put all the propertys needed to render the Light as Vec4 Params.
HLMS will also bind the GBUffer-Texture to them.
Currently thers a little Problem when the User adjusts the Light Range or deletes a Light at runtime.
Since I have no way to detect if a Light was modified or removed, I can't alter its settings.
Also, later I'd like to add the Gbuffer-Texture as an AutoParamTextureUnit, same with the Shadowmaps, to make Custom Light Materials possible.
So Users can also implement custom Templates for Custom Ligths without changing the acutal HLMS_DS source code.

dynamic Materials

Since they are dynamic, they can't use the const buffer pool, so they are just Const Buffers. They are composed of a number of TextureUnits, AutoParams, Property Params, Vec4 Params and PieceParams. These are defined in the Datablock the Users sends the HLMS. For each on theres a corresponding type in the Materialtemplate. Materialtemplates are either a C++ Class or a DatablockTeamplate (later is not implmented yet). Theres a Lightdatablock template and a GBufferdatablock Template. They add the types they support in a function called initializeParamTypes(). For the Gbuffertemplate these are i.e diffuse, glow, glowmap, diffusemap etc. and for Lighttemplates these are Lightpos, LightDiffuse, LigthSPecualr, SpotLightAngle etc. These Types are then read as Values from the Datablock data and Send to the GBuffer, if the Material is dirty.
Vec4Params are Parameters which are compromised of 4 or less float values i.e diffuse, TextureParams are Textures i.e NormalMap, PropertyParams are Propertys i.e IS_AMBIENT_LIGHT and PieceParams are Pieces i.e custom_post_material.
This way, its much easier to add more Parameters to Materials without having to edit much code.
Later these Materials should be extendable using some form of css textfile.
A User could create Unreal Style Materials where he would define all the Needed textures, all the settable propertys, automatic paramters (time for example) and the necassary shader code that would modify the material properties to create a new Material within Deferred Shading, inside a file and another user could load it by setting a template paramter in a standard DS Datablock.

Dithering Transparency

Ugly as hell way to create Transparency. Later I'd like to make sure users can use other HLMS to create Forwarded Alpha Materials so it actually looks decent. Once I was done I was really dissapointed by the Visual quality of dithering. I could be kinda usefull to phase in distant objects as you move closer to them, Far Cry 3 style, create 0-1 alpha Materials (leaves) or maybe to create a cheap teleporter effect.

Debug Views

You use f6 and f7 to switch between different Debug Modes for the Renderer.

Heres some Info on Stuff I wan't to add


The way I wan't to add shadows (and other automatic or intern textures) is a little bit special. I'd like to create AutoParamTextureUnits for that. These are TextureUnits which are automaitcly added and updated, simsilar with the existing Vec4AutoParams. So that other Materialtemplates could easily include or exclude them for whatever reason.
So Screen Space Refection Materials for instance could bind a SSRAutoParamTextureUnit, which includes a rendered version of last frames fully rendered scene and use it to create a reflection effect on the ground.
Currently I'm not entirely sure how to implement this, but I have a rough idea, is definitly the next thing on my list.

Configurable Textureunits

The current Problem I have with texture Units (and Datablocks in general), is that you can only have one property and one Value. For TextureUnits in particular, this removes a ton of features from the 1.0 version of Ogre, i.e animations, Filtering, texture_coordingates, etc. . I had to awkwardly use nested one-line Datablocks to create AutoParams.
I think I would be a good idea to allow a datablock like that:

datablock a{
param {
paramb valb
paramc valc
paramd vald


So that those things could be added back into the HLMS. It might also prove usefull for Datablock Templates.


Will probably need to be a postprocessing anti aliasing at the end of the Compositor chain. Hardware AA in DS is not a good idea.

I'll probably extend this thread later, because I forgot a million things.
Please post, bugs, suggestions and whatever crazy ideas you might have
Also please excuse the shitty models, I made almost all of them and I'm not an artist

Re: HLMS_DS Demo

Posted: Tue Apr 26, 2016 12:58 pm
by al2950
Awesome work :D

I will be very interested in looking through what you have done, although I dont really want to go down the deferred route, I am more interested in Forward+ type renderers, but I am waiting for compute shaders to be declared 'stable ish' ie merged into 2.1.

Re: HLMS_DS Demo

Posted: Tue Apr 26, 2016 8:02 pm
by white_waluigi
I don't think its a case of one or the other, since most engines that use DS use a hybrid system, where stuff like walls, floors, characters etc are deferred and particles, special marterials and anything transparent is Forward+, so you get prefomance and flexibility.
My plan is for users to be able to use both and for HLMS_DS to somehow redirect materials to HLMS_PBS if necessary, similar to ogres old ds implementation.

Re: HLMS_DS Demo

Posted: Fri May 06, 2016 9:42 pm
by frostbyte
slowly but surely...great work...thank you very much...good to have you on our side (-:
deffered indeed suffer from hige bandwidth requirements making it not very suitable for mobile( or even integrated gpu... ) but still the more option we have
the i realy appriciate your work and code sharing...thanks again (-:
i did'nt realy mess with hlms, so i wonder did you find it was easier to work with/more flex/better perfromance with hlms compared to old way?
keep on the good work...

Re: HLMS_DS Demo

Posted: Sat May 07, 2016 11:54 am
by white_waluigi
Its a lot better and more flexible than creating weird, on-the-fly materials derived from other materials, like in the originl HLMS implementation, which was really just a hack more than anything.
But unfortunatly most of the time if wasted programming this thing was just having stuff not working with no idea why and me leaving the project alone for a few weeks at a time. So I bit more documentation would certainly help.
One Problem I had is that for some HLMS Paramters I had to use makeshift one line css like this: file:texture.png,filter:none,UVindex:1 I think it would be usefull for a user if this was possible:
test ds{
normal_map {
file normal.png
filter none
uvindex 1
diffuse_map {
file diffuse.png
uvindex 0
autoparam1 {
type time
time 2000
pulse on
specualr 0.3 0.4 0.3

just for convenience sake, it would also be possible for HLMS to replicate the original material systems Texutre UNit, complete with blending and texture animation

But other than that, so far, it seams like a huge step forward for Ogre

I can't really comment on the preformance though since I've never properly benchmarked either of them.

Yeah mobile might be a bit of problem, especially when rendered in 1080p, I think one solution might be tinkering with the texture format, making the lighting less accurate but savig tons of vram (my implmentation needs 4 Gbuffers at screensize with all 4 channels) or using compressed textures, although that will lead to heavy artifacts due to lossy compression.

Re: HLMS_DS Demo

Posted: Fri Jun 10, 2016 1:34 pm
by white_waluigi
Did you just amke an accout for that?
Either way, thanks a lot.

Re: HLMS_DS Demo

Posted: Thu Jul 28, 2016 7:34 pm
by white_waluigi
28. July Update (view main Post)

Re: HLMS_DS Demo

Posted: Fri Jul 29, 2016 5:36 pm
by white_waluigi
updated download links, they work now

Re: HLMS_DS Demo

Posted: Sun Jul 31, 2016 5:01 pm
by frostbyte
hi, great progress...
just in case you missed my post...
i figured this might be somehow helpful( especially on advanced features... ) since it's deferred
yeah, i know...its python and panda...
but if you'll read the code a little bit you'll see that it basicaly comes down to shader work
tobspr( the developer ) wrote a plugin system for panda thats basically does what HLMS does( he use #include instead of @piece etc.. )
on top of that he wrote this impressive deferred-render-pipeline...might be a nice refference code...
thanks...have fun (-:

Re: HLMS_DS Demo

Posted: Sun Jul 31, 2016 9:02 pm
by white_waluigi
Welp that puts my crappy little demo to shame.
But honestly so far I've been focusing on flexibility and extanbility instead of the actual lighting which still is very barebones.
But I'll definitly have a look at his stuff and steal some code if thats ok with their license.
unfortuantly this level of rendering quality will probably take a while considering im currently still trying to finish my material template system, making it compitable with HLMS_PBS and making animations work.
But thanks a lot for the link, it definitly helps to have a reference point.

Re: HLMS_DS Demo

Posted: Sun Jul 31, 2016 10:49 pm
by xrgo
this is great! many features and flexibility, Ogre really needed this! kudos
Have compared similar scenes between deferred and forward3D? I would love to see some comparison with different amount of lights! I see the new screenshots gives you ~28fps and the old ones ~270fps, why is that? what are your pc specs?

keep it up! =D

Re: HLMS_DS Demo

Posted: Mon Aug 01, 2016 2:19 am
by white_waluigi
So far I have not really experimented with perfomance, since I barley optimised the shadercode, but I'll definitly do it once the basic renderer is completed and optimzed.
Yep, because I ran it on my laptop, while the last one was from my pc. still runs as well on my PC, I forgot about the fps numbers.
My laptop can't even run tf2 at 60 fps so I'm not sure how much magic I can work there, but I'll give my best.

In case your wondering about what I mean with flexibility:

I want people to be able to create material template files that describe a material type
So someone can create a generic water material for example, and another user can load it into HLMS_DS and tweak things like waveheight, flow direction, color, etc...
Similar to how Unreal Engine for works, just as a text file instead of a visual editor.
I'll probably elaborate on that once i've started implementing that.

Re: HLMS_DS Demo

Posted: Mon Aug 01, 2016 3:01 am
by frostbyte
oh need to apologize...we are very THANKFUL for your AWSOME work...
its very good that you focus on preformance/flex/extend and native ogre integation...
advanced features can/will come later once you have a stable ground

i must say that all of this advanced Render-pipeline stuff made my gpu( 660m ) sound very misrable at about 5fps...
i think its very impressive but targeting mainly high-end gpus...
if anything...i would steal the cool car model...( btw: render-pipline project is licenced MIT )
don't forget, all great software started small...
thanks again...cheerz (-:

Re: HLMS_DS Demo

Posted: Mon Aug 01, 2016 3:01 pm
by white_waluigi
Always got to hear tht people care about what your working on, thanks for the kind words.
And exactly I want this thing to be as configurable but simple to use as possible, so it can be configured to not be pretty but still run on my laptop, but still be able to cranked up enough to look decent on my powerhouse PC.

Re: HLMS_DS Demo

Posted: Fri Feb 10, 2017 4:55 pm
by white_waluigi
JSON Update! See Main Post!

Re: HLMS_DS Demo

Posted: Wed Feb 15, 2017 1:31 am
by frostbyte
hi, nice of you to keep us in mind inspite of having stressful times
tbh i'm not using 2.1 in my project yet( stressful year :wink: ) but i like checking out the advances made with it, and explore the benefits( wait&watch mode )
your project is one of my favorites for three reasons...
1)users will probably use it one day as a code reference in writing a complete rendering pipeline using hlms
2)DS inspite its flaws is still vital since the alternatives aren't always better ... ed-shading
3???)json-material? it looks like its a way to hook into the rendering pipeline without messing with the hlms implementation
does it function similarly to "lowLevel" materials in the forward+ pipeline
maybe you can write a short doc regarding what they are, how they fit/function inside the pipeline and how to use them? ( documenting is good )
i'm a big fan of code remarks "//this code do that thing"....

moving the project to github is great( its my favorite toy store :D ),
i think you should have the main branch contain only source code with a cmake- project and put the binary linux/windows dist in the "releases" section along with a zip file of the source they were build with( e.g Relase1_0 : DSOgreV1_0_linux.tar.gz,, )

anyway keep up the good work, i'm always happy to see new cool demos of stuff which i might one day use in my project
mean while, i have some new "reading" stuff for you,its the prettiest area-light demo i've seen, based on BGFX its fast and work nice even with HD4000, as a pro-bonus the guy also wrote a super fast/cool "ground truth" gpu ray-tracer just for fun :D
bgfx Demo (executable + code) is in the Downloads section( named )

and here is a link to my new favorite "candy store" ( hint: type "pbr" or "pbs" in the searchBar )

i wish you a cool relaxed 2017 , have func 8)

Edit: trying to be useful at least as a tester i've confirmed that while the old demo run perfect on my integrated intel HD4000( windows )
the current demo crash after screen init with this log:
(168.67 KiB) Downloaded 132 times

Re: HLMS_DS Demo

Posted: Wed Feb 15, 2017 12:42 pm
by white_waluigi
Thanks a lot, and yes I probably should have explained the JSON feature better and in the next post there will be more code comments and a proper documentation for JSON Materials.

Heres how they work: Users create a Json file for their material, with all the smapler and blendblocks they need. Then they create a list of all resources (mostly Textures) their materials need and setup some paramters (in the case of water, wave size, water color, specularity, etc...). Then they write the shadercode necessary for their Material inside the JSON file. This shadercode will be able to affect these GBuffer paramters: Diffuse, Spcularity, Reflectivity (for SSR), Normals, depth Glow and Opacity. This allows them to create very varied materials without having to rewrite anything about the render pipeline. Other users can inherit the JSON file and change paramters and textures or even shaders if they need to. Later I will also create a JSON Material system for lights, so the behaviourt of ligths can be changed, so its possible to create Gobo lights, PBS lights or Toon shaded lights.

I'll clean up the github page soon, and make sure its buildable with CMake, so people can experiment with it.
Thanks a lot for the links. I'll make sure to replace my crappy models with this stuff.

I'll find a laptop with an Intel chip and make sure it runs. Its probably not a huge bug if the old version ran, thanks a lot for the feedback.

Quick Update

Posted: Sat Aug 19, 2017 9:34 am
by white_waluigi
I didn't really have time in the last few months to create a full update but I did make a few changes to it just so you know I am not dead:

- Cmake Integration
- Implementation Forward Materials
- Refracting Transparency
- Full JSON Forward Material Support

Most of the basics are currently implemented, the next things on my list are DX support, Pointlight Shadows, Light Materials ("As soon as I find a convenient way for the user to assign Light Materials to Lights") and finally a new Demo with a bit more interactivity.
You can build the CMake Project simply by setting the Ogre sdk path (build/sdk) and the ogre deps path.
Theres currently a problem on Windows if you used boost to build ogre, I'm gonna try to iron that out as soon as the latest boost gets buildable on Windows again.