Irrlicht Engine

http://jbit.net/~sparky/sfgrad_bump/mm_sfgrad_bump.pdf

Tangentless normal mapping. No I don't want to preprocess my meshes nor upload unneeded tangents.

Before - after:

are you generating the tengents on the fly?

I was using techic for normal maping w/o tengents befor i switched to the FVF svn

the article doesn't even mention speed and framerates, so my guess is that it must be MUCH slower than uploading tangents to do normal-mapping the traditional way
Useful for offline editors though

hendu you should add some specular lighting to your shots because they amplify the effect of normal mapping

Granyte wrote:are you generating the tengents on the fly?

No, and that's the point. There are no tangents. Do read the paper

It works in screen space, per-triangle.

fmx wrote:the article doesn't even mention speed and framerates, so my guess is that it must be MUCH slower than uploading tangents to do normal-mapping the traditional way
Useful for offline editors though

hendu you should add some specular lighting to your shots because they amplify the effect of normal mapping

It's likely slower than object-space normal-mapping, but as tangent-space needs a few calculations too, the speed difference to tangent space normals may not be big. CBA to set up traditional tangent-space mapping to compare

Also, as the paper mentions, it was used in Uncharted 2.

Even if it's a little slower than tangent space, it has less limitations (texture _can_ be mirrored/replicated over a mesh), doesn't require uploading unnecessary tangents (less VRAM use, faster uploads), doesn't require mesh pre-processing (all is handled at runtime, via the texture).

In general this class of algorithms is much superior. Anything works, all without preprocessing. Just like screen-space SSAO > pre-calculated SSAO.

What's the limitaton? I know I was trying to do something similar, but shaders only give you information for the current vertex/pixel. ddx_fine/ddy_fine look like functions that allow the GPU to provide the missing information, but where are they available?

Also, does the technique in the paper require you *not* to use vertex shaders? That is, will it only work if there isn't a vertex shader?

What's the limitaton? I know I was trying to do something similar, but shaders only give you information for the current vertex/pixel. ddx_fine/ddy_fine look like functions that allow the GPU to provide the missing information, but where are they available?

I use GL dFdx, dFdy, which correspond to ddx and ddy. The HLSL _fine versions require DX11 cards, but the normal versions and so the GL equivalents should work on anything GL2 (~DX 9.0c).

Also, does the technique in the paper require you *not* to use vertex shaders? That is, will it only work if there isn't a vertex shader?

No such limit, use all shaders you want.

Testing it with text (normalmapped text, yay!)

I improved the quality a bit. On the speed, with 640x480 all covered I get 300fps - keep in mind this is with tearing prevention, so the full speed would be even higher. Can't complain.

I cant argue with you on that one, good stuff
thanks for sharing as usual

Atmospheric scattering (sky color, sun) from ShaderX2.

I'll need to compare this with the ATMOsphere from here once I add luna and stars.

preatty nice colors you have there is this algorythm capable of extra atmospheric effect?

What do you mean by extra effects?

i mean like the atmosphere seen from the outside but i guess it can't you didn't think about it

Ah, no, it doesn't do that. It's very optimized for the sky as seen from the planet surface, basically making it do scattering from the outside too would mean picking a different algo.

alright that's what i was wondering the one i implemented can do both but i can't get it to output a nice sunset color sky