Looking thro the code I can't see that default normal direction is being taken into account in the bump parallax shader, or in the makeNormalMap function, or did I miss something?
The normal map, unless specifically adjusted for each mesh shape, will apply all bump normals as if the mesh is a plane, so the back of a sphere would have inverted normals.
I'm thinking I must have missed something?
Irrlicht bump map handling of non-planar meshes
Re: Irrlicht bump map handling of non-planar meshes
Example 11 seems to work fine with a sphere (comment out the setVertexColorAlpha part to see it better).
I've never really looked too close at those shaders as I don't know the assembler (and no point learning it at this point as it's outdated to write shaders like that), but a quick look at COpenGLNormalMapRenderer it has an InNormal variable which I suppose is the vertex normal (interpolated over the vertex from the 3 corners if it works like glsl/hlsl).
I've never really looked too close at those shaders as I don't know the assembler (and no point learning it at this point as it's outdated to write shaders like that), but a quick look at COpenGLNormalMapRenderer it has an InNormal variable which I suppose is the vertex normal (interpolated over the vertex from the 3 corners if it works like glsl/hlsl).
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Re: Irrlicht bump map handling of non-planar meshes
Yes, the in.normal is off the mesh, the shaders read the normal map texture and then use that instead for the normal.
The bump data normal if created from a height map will all be 0,1,0 up oriented, and of course a sphere, etc., has normals in all directions, so technically it would be incorrectly bump mapped, though you might not see that on random textures.
You'd need to apply a simple height map, and move the light around, but by the look of it, there is no reorientation of the height normals to match the base mesh normals.
The bump data normal if created from a height map will all be 0,1,0 up oriented, and of course a sphere, etc., has normals in all directions, so technically it would be incorrectly bump mapped, though you might not see that on random textures.
You'd need to apply a simple height map, and move the light around, but by the look of it, there is no reorientation of the height normals to match the base mesh normals.
Re: Irrlicht bump map handling of non-planar meshes
Hm, I think I might get what you mean. The mesh-normal is in a world coordinate system, but the InTangent and InBinormal are in a polygon local (or bitmap) coordinate system with 3d vector expected to be up? And they just are put together to build one matrix despite that they don't really belong to the same coordinate system.
Thought no idea what this one later on does:
"MAD OutLightVector1, TempTransLightV1, {0.5,0.5,0.5,0.5}, {0.5,0.5,0.5,0.5}; \n"\
Well, I really can't tell. In the example the world with heightmap doesn't look wrong. With moving light and all.
But could be it's wrong and I don't see it there. I never actually used those shaders, so I have no test beyond that.
That stuff should be rewritten in GLSL. We may even mostly have that already in the OGL-ES branch. But I'm a bit reluctant putting anything on my todo-list beyond - fix everything in 1.9 which wasn't broken already in 1.8 to get that ******* release out.
edit: Also I think it had more problems. Obviously it only supports 2 lights. But I think it also ignores directional lights.
Thought no idea what this one later on does:
"MAD OutLightVector1, TempTransLightV1, {0.5,0.5,0.5,0.5}, {0.5,0.5,0.5,0.5}; \n"\
Well, I really can't tell. In the example the world with heightmap doesn't look wrong. With moving light and all.
But could be it's wrong and I don't see it there. I never actually used those shaders, so I have no test beyond that.
That stuff should be rewritten in GLSL. We may even mostly have that already in the OGL-ES branch. But I'm a bit reluctant putting anything on my todo-list beyond - fix everything in 1.9 which wasn't broken already in 1.8 to get that ******* release out.
edit: Also I think it had more problems. Obviously it only supports 2 lights. But I think it also ignores directional lights.
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Re: Irrlicht bump map handling of non-planar meshes
Exactly, the bump normals need to be aligned to the non-planar mesh surface. For gaming I guess no one will notice on basic textures.
The MAD .5.5.5 reduces the vector by half.
Bump data format is xzy and /2 with 0.5 added. That has to be removed in the shader to get the normal vector.
To be honest I'd focus on the OpenGL and DX11 driver as that's available though the shader needs a few hours to complete. All a lot of work though.
The MAD .5.5.5 reduces the vector by half.
Bump data format is xzy and /2 with 0.5 added. That has to be removed in the shader to get the normal vector.
To be honest I'd focus on the OpenGL and DX11 driver as that's available though the shader needs a few hours to complete. All a lot of work though.
Re: Irrlicht bump map handling of non-planar meshes
I think it looks more or less correct even on back of the sphere because it only uses 2 values really from the texture and third from from the polygon normal. So it always looks in the normal direction already and is never inside-out. Up/down in sphere case likely correct anyway - and even the height difference is correct. Only that polygons where height increases reflect as if they go down which is maybe hard to notice.
But that would also mean that it never uses the full range of the heightmap as the influence of the normal vector is at least 50%. Thought I guess rotating the reflection further with a heightmap may not looks so great anyway.
OK, I'll keep it in mind for another time.
But that would also mean that it never uses the full range of the heightmap as the influence of the normal vector is at least 50%. Thought I guess rotating the reflection further with a heightmap may not looks so great anyway.
OK, I'll keep it in mind for another time.
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Re: Irrlicht bump map handling of non-planar meshes
So the shader uses the mesh normal's Y component, adding the X and Z from the bump map vector?
That would keep the backside from going dark but as you say, the lighting gets flipped, it's a bit of a bodge but saves rotating every normal.
That would keep the backside from going dark but as you say, the lighting gets flipped, it's a bit of a bodge but saves rotating every normal.
Re: Irrlicht bump map handling of non-planar meshes
The D3D9 parallax shader was my reference, so not sure if it's the same as the OpenGL version. In any case, losing 50% of the effect would explain why other systems have such stand-out bump maps, just taken me a decade to find the answer, not that I was looking hard, but it's good to know. 
