Irrlicht Engine

I had exactly the same thought about using 3 quads, but as you say that also suffers the same issue. I need to keep things fast as it's already dropping frames, so using many triangles, which would be a good solution, isn't an option, I guess I can add the perspective pixel address code to the shade...

https://www.sendspace.com/file/dklr00 - Same distortion in the Beam node https://www.sendspace.com/file/dklr00. So it looks like this is easy enough to solve in a shader as the article explains, but can it be done without having to use a shader to map each pixel to the correct perspective? Can't re...

That's great, I'll try to recalculate the UVs based on that, of course my case is just 2 triangles, but how hard can the math be!

Yes but triangle A is much bigger than B, so the GPU is spreading the texture evenly, and in triangle B it's more compressed. It's seems the GPU/DX driver assumes any triangle with UV's 0,0-1,0-1,1 will have texture 0.5, 0.5 in the middle of the diagonal, whereas my beam would need it to be 0.5, 0.9...

So this should have been simple enough, but :roll: I created a beam using two triangles (based on the beam post here), works fine until I adjust the end vertices to spread the beam... What happens is that the leftside triangle (A) which has its base at the end of the beam, if made wider naturally ma...

Trial and error, quite painful at times!

XEffects shader doesn't handle normals calculation in terrain vertex height processing, which was where my issue was. Its surprising how this can get exponentially complicated as you add to the code. My pixel shader is 70K when compiled now, takes several minutes to compile to, so I keep the compile...

I could but it wouldn't be much use without the other 35 k lines of code that make up the vertex-based height map, shadow, lighting and bump mapping system. It's sorta got really complicated, as the shader has to read a height map to elevate the vertices for the terrain, then calculate the X, Z slop...

I improved the shader math and it's fixed.

Was the floats getting to close to zero.

It's great chatting with you about these issues, you really know your stuff! Yeah, shadow camera needs to be well focused on the required zone only, suitable resolution, etc., but I'm using a dynamic shadow-light camera positioning trick that tracks it in behind the view cam keeping the same directi...

The irrEffects pixel shader renderer works well, but at low angles to lights the edges of the shadow flicker even when smoothed. I guess the steep depth map changes on oblique angles might be the reason, with the tiniest camera movement causing a large change in the shadow depth map. Has anyone any ...

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. :roll: :l...

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.

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

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