Advanced Effects
Re: Advanced Effects
You can always port to IrrBAW for compute shaders
Re: Advanced Effects
Good lord.. is that how screen space reflections look like without filtering??
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
Re: Advanced Effects
I regularly download your BAW implementation devsh!
It's just a question of time before I go 64 bit.
I have harsware issues.
My board was the first 64 bit ASUS to come out and not very compatible lately..
But for now..
While studying and thinking the G-Buffer concept over I came up with the following:
Any opinions?
Am I on the right track?
It's just a question of time before I go 64 bit.
I have harsware issues.
My board was the first 64 bit ASUS to come out and not very compatible lately..
But for now..
While studying and thinking the G-Buffer concept over I came up with the following:
Any opinions?
Am I on the right track?
Re: Advanced Effects
First off its not geometry shaders that draw to G-Buffer, its pixel shaders.
You want to render to (compose your deferred results in) 16bit Float ARGB, this is the max you want and need.
For bonus points, when you don't want alpha, you can render to RGB9_E5 (shared exponent) even though its a non-renderable format by having your own GLSL function to pack RGBA32F to RGB9_E5 (as a uint - a GLSL equivalent of uint32_t).
If you're using PBR, you do not need Albedo outside the range of [0,1].
To support HDR and 10bit Displays use a RGB10_A2 format (i think its renderable).
People usually put greyscale specular in the alpha.
Depth is already implicitly present in the depth attachment of every FBO, its accessible as a texture from a shader! No need to output it again.
For good precision and no z-fighting use DEPTH32F and for bonus points reverse-Z with glDepthRange of [0,1] instead of [-1,1]
You want to use the full 24bits for Normals, now it doesnt matter how you store them.. but full 24bits please, or you will see quantization error in reflections and highlights.
Best method is to use standard RGB8 with a special lookup texture (Crytek method which uses 98% of the available precision) which finds you an unnormalized integer vector with the least angle deviation from your original.
We already have an implementation of this in IrrBAW when we compress mesh normals from XYZ 32bit Float down to RGB30_A2.
PAY ATTENTION HERE, YOU DO NOT STORE THE NORMALIZED (UNIT LENGTH) NORMAL AS A FIXED PRECISION UINT! - THIS WAY ONLY 2% OF THE VALUES GET USED
Whats beautiful about this method is that interpolation still works (as opposed to other mappings which have singularities).
Now if you store normals in 24bits, you have 8 bits left for some specular stuff.
As for specularity/shininess/roughness, Unreal did a good mapping for CGX which maps the steps of shininess to the [0,1] range nicely.
Your G-Buffer should be 32+(24+8) = 64 bits for non-alpha rendering or 96bits with floating point depth
Final note on emissive colour:
If you're not doing deferred shading, but mere deferred lighting (where you output only depth,normals,roughness/shininess).. you can bind your empty specular or diffuse channel of the LBuffer to your GBuffer MRT and prime it with the emissive colour. The only downside is that when writing to it your emissive materials need to divide their emissive colour by specular or diffuse (and none of the RGB components can be 0).
If you're doing deferred shading then you can prime your output framebuffer (to which your deferred full screen shader will write additively) with the emissive colour.
In either case having only some objects write to a colour channel is a waste of memory bandwidth and hence a big FPS hit, which is why I'd group objects like this:
1) Diffuse Only
2) Has Specular
3) Has Emissive
Then progressively:
Draw Object Group
Bind One more channel (specular, emissive)
You want to render to (compose your deferred results in) 16bit Float ARGB, this is the max you want and need.
For bonus points, when you don't want alpha, you can render to RGB9_E5 (shared exponent) even though its a non-renderable format by having your own GLSL function to pack RGBA32F to RGB9_E5 (as a uint - a GLSL equivalent of uint32_t).
If you're using PBR, you do not need Albedo outside the range of [0,1].
To support HDR and 10bit Displays use a RGB10_A2 format (i think its renderable).
People usually put greyscale specular in the alpha.
Depth is already implicitly present in the depth attachment of every FBO, its accessible as a texture from a shader! No need to output it again.
For good precision and no z-fighting use DEPTH32F and for bonus points reverse-Z with glDepthRange of [0,1] instead of [-1,1]
You want to use the full 24bits for Normals, now it doesnt matter how you store them.. but full 24bits please, or you will see quantization error in reflections and highlights.
Best method is to use standard RGB8 with a special lookup texture (Crytek method which uses 98% of the available precision) which finds you an unnormalized integer vector with the least angle deviation from your original.
We already have an implementation of this in IrrBAW when we compress mesh normals from XYZ 32bit Float down to RGB30_A2.
PAY ATTENTION HERE, YOU DO NOT STORE THE NORMALIZED (UNIT LENGTH) NORMAL AS A FIXED PRECISION UINT! - THIS WAY ONLY 2% OF THE VALUES GET USED
Whats beautiful about this method is that interpolation still works (as opposed to other mappings which have singularities).
Now if you store normals in 24bits, you have 8 bits left for some specular stuff.
As for specularity/shininess/roughness, Unreal did a good mapping for CGX which maps the steps of shininess to the [0,1] range nicely.
Your G-Buffer should be 32+(24+8) = 64 bits for non-alpha rendering or 96bits with floating point depth
Final note on emissive colour:
If you're not doing deferred shading, but mere deferred lighting (where you output only depth,normals,roughness/shininess).. you can bind your empty specular or diffuse channel of the LBuffer to your GBuffer MRT and prime it with the emissive colour. The only downside is that when writing to it your emissive materials need to divide their emissive colour by specular or diffuse (and none of the RGB components can be 0).
If you're doing deferred shading then you can prime your output framebuffer (to which your deferred full screen shader will write additively) with the emissive colour.
In either case having only some objects write to a colour channel is a waste of memory bandwidth and hence a big FPS hit, which is why I'd group objects like this:
1) Diffuse Only
2) Has Specular
3) Has Emissive
Then progressively:
Draw Object Group
Bind One more channel (specular, emissive)
Re: Advanced Effects
Once again devsh comes to the rescue with his wisdom!
Duly noted! Thanks! (specially the advice on 24 bits for normals)
I'll investigate for sure!
Duly noted! Thanks! (specially the advice on 24 bits for normals)
I'll investigate for sure!
Re: Advanced Effects
Added a new part to IrrlichtBAW's MSAA example:
https://github.com/buildaworldnet/Irrli ... 49a377d46a
Programmable GLSL MSAA resolve.
I'm interested what you'd manage to do with your magic!
Suggestions:
MSAA + SSAO ?
TAA
FXAA
SMAA
SRAA
Any other Anti-Aliasing Technique from DOOM 2016 or Battlefield or Crytek XD
https://github.com/buildaworldnet/Irrli ... 49a377d46a
Programmable GLSL MSAA resolve.
I'm interested what you'd manage to do with your magic!
Suggestions:
MSAA + SSAO ?
TAA
FXAA
SMAA
SRAA
Any other Anti-Aliasing Technique from DOOM 2016 or Battlefield or Crytek XD
Re: Advanced Effects
Yes..
But before that I've come to the conclusion that my project needs a major architectural redesign..
Posting it the way it is now.
But before that I've come to the conclusion that my project needs a major architectural redesign..
Posting it the way it is now.
Re: Advanced Effects
Last of the old architecture.
Special thanks to devsh for his technical input.
Lots of stuff like a cool new SSAO shader, Screen space reflection, 32bit Fragment position in a render target etc.
You'll have to figure out how to use the keys..
(key "V" brings up the shader uniform feed values and "M" changes input mode)
I'm tired..
Full Project (VC 7.1)
http://s000.tinyupload.com/?file_id=181 ... 6751490240
Special thanks to devsh for his technical input.
Lots of stuff like a cool new SSAO shader, Screen space reflection, 32bit Fragment position in a render target etc.
You'll have to figure out how to use the keys..
(key "V" brings up the shader uniform feed values and "M" changes input mode)
I'm tired..
Full Project (VC 7.1)
http://s000.tinyupload.com/?file_id=181 ... 6751490240
Re: Advanced Effects
Hello there!
I'm done studying for a while and would like to experiment with Irrlicht again.
All my old stuff was usually on "tiny upload" which only kept things for 90 days.
I now have a Google Drive account with which I can share some stuff again.
I'm still a bit of a newbie with Irrlicht so the code isn't Fantastic but the ideas are sort of cool.
I saw someone ask about Normal Maps etc, so I decided to re-post some old stuff..
Keep in mind that these are quite old but runs super-fast on my new machine which says a lot for Irrlicht.
My main interest back then was Character Animation and how to use different apps to get the characters
into Irrlicht. "*.b3d" can be rendered by Irrlicht and you can port your Blender Characters to Irrlicht
via the free "Frag Motion". (Blender with it's EEVEE is taking over the world)
I mostly still use Blender 2.79 because of the game engine with which I can test shaders.
(find them on my YouTube, like and comment please)
Blender 2.79 is most very definitely not redundant as one may naturally assume.
Blender 8.x and EEVEE is almost a completely new system with a new GUI etc.
Blender 8.x has good backward compatibility if your scenes uses cycles but my scenes use the
old blender render.
This is easily fixed by treating materials in cycles node mode.
Blender 2.79 should, for now form part of yout toolkit if you are a blender freak like me.
Mapped Normals and a good understanding of Specular versus Gloss really made my characters look good in Irrlicht.
I use Audierre Sound Library as most sound libraries haven't really improved since then.
(it's very fast)
I'm done studying for a while and would like to experiment with Irrlicht again.
All my old stuff was usually on "tiny upload" which only kept things for 90 days.
I now have a Google Drive account with which I can share some stuff again.
I'm still a bit of a newbie with Irrlicht so the code isn't Fantastic but the ideas are sort of cool.
I saw someone ask about Normal Maps etc, so I decided to re-post some old stuff..
Keep in mind that these are quite old but runs super-fast on my new machine which says a lot for Irrlicht.
My main interest back then was Character Animation and how to use different apps to get the characters
into Irrlicht. "*.b3d" can be rendered by Irrlicht and you can port your Blender Characters to Irrlicht
via the free "Frag Motion". (Blender with it's EEVEE is taking over the world)
I mostly still use Blender 2.79 because of the game engine with which I can test shaders.
(find them on my YouTube, like and comment please)
Blender 2.79 is most very definitely not redundant as one may naturally assume.
Blender 8.x and EEVEE is almost a completely new system with a new GUI etc.
Blender 8.x has good backward compatibility if your scenes uses cycles but my scenes use the
old blender render.
This is easily fixed by treating materials in cycles node mode.
Blender 2.79 should, for now form part of yout toolkit if you are a blender freak like me.
Mapped Normals and a good understanding of Specular versus Gloss really made my characters look good in Irrlicht.
I use Audierre Sound Library as most sound libraries haven't really improved since then.
(it's very fast)
Re: Advanced Effects
For those interested here are some projects I posted..
All of this is 32 bit as I know diddly squat about 64 bit Irrlicht yet.
The zipped files are prefixed with numbers which is an indication of which were done before which.
To see how I progressed note the order of these prefixes.
Also, if you see errors or have ideas let me know.
Any "*.odt" files is just "Open Office" formats in which I use an experimental syntax highlighting scheme.
Some files were stored on DVD and thus have READ ONLY attributes. (you may need to change this)
Most image files are in *.TGA which is bulky so you can experiment with lossless *.PNG which is far better in terms of size..
Some data files may take a while to load. Not a crash, just wait for them.
When I get time I'll post some "Content Creation" notes you might find useful.
If you see a purple screen then it is not a bug, but my compiler messing with opengl due to versions etc.
(I must still look into these, and will rely to comments when I have time)
Understand that there is a definite order in which these were created.
Later projects have better solutions so see the prefixes, eg, "0106_xx.zip" versus "0541_xx.zip".
Don't consider earlier projects redundant though as there are useful with unique things in them.
If you see what looks like your code in here then it probably is and we all thank you for posting them!
Finally, these files are yours and you can do what you like with them.
(some credit to me and the original authors will be appreciated though)
All of this is 32 bit as I know diddly squat about 64 bit Irrlicht yet.
The zipped files are prefixed with numbers which is an indication of which were done before which.
To see how I progressed note the order of these prefixes.
Also, if you see errors or have ideas let me know.
Any "*.odt" files is just "Open Office" formats in which I use an experimental syntax highlighting scheme.
Some files were stored on DVD and thus have READ ONLY attributes. (you may need to change this)
Most image files are in *.TGA which is bulky so you can experiment with lossless *.PNG which is far better in terms of size..
Some data files may take a while to load. Not a crash, just wait for them.
When I get time I'll post some "Content Creation" notes you might find useful.
If you see a purple screen then it is not a bug, but my compiler messing with opengl due to versions etc.
(I must still look into these, and will rely to comments when I have time)
Understand that there is a definite order in which these were created.
Later projects have better solutions so see the prefixes, eg, "0106_xx.zip" versus "0541_xx.zip".
Don't consider earlier projects redundant though as there are useful with unique things in them.
If you see what looks like your code in here then it probably is and we all thank you for posting them!
Finally, these files are yours and you can do what you like with them.
(some credit to me and the original authors will be appreciated though)