Split: Planet rendering issues

For test results, bug reports, announcements of new builds etc.

Moderators: another_commander, winston, Getafix

User avatar
kanthoney
Commodore
Commodore
Posts: 281
Joined: Thu Nov 07, 2013 10:21 pm

Re: Split: Planet rendering issues

Post by kanthoney »

Playing around with the planet fragment shader, it's looking very much as if the vLight1Vector parameter that's passed to it is always normal to the surface, which wouldn't be right. I haven't got as far as finding out where this parameter comes from though. I'll keep digging.
User avatar
cim
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 4072
Joined: Fri Nov 11, 2011 6:19 pm

Re: Split: Planet rendering issues

Post by cim »

kanthoney wrote:
Playing around with the planet fragment shader, it's looking very much as if the vLight1Vector parameter that's passed to it is always normal to the surface, which wouldn't be right. I haven't got as far as finding out where this parameter comes from though. I'll keep digging.
It's set in the vertex shader.
User avatar
kanthoney
Commodore
Commodore
Posts: 281
Joined: Thu Nov 07, 2013 10:21 pm

Re: Split: Planet rendering issues

Post by kanthoney »

Looking at the vertex shader:

Code: Select all

varying vec3			vEyeVector;
varying vec2			vTexCoords;
varying vec3			vLight1Vector;
varying vec3			vCoords;

void main(void)
{
	vCoords = gl_Vertex.xyz;
	
	// Build tangent basis.
	vec3 normal = normalize(gl_NormalMatrix * gl_Normal);
	vec3 binormal = cross(normal, gl_NormalMatrix * vec3(0, 1, 0));
	vec3 tangent = -cross(normal, binormal);
	
	mat3 TBN = mat3(tangent, binormal, normal);
	
	vec3 eyeVector = -vec3(gl_ModelViewMatrix * gl_Vertex);
	vEyeVector = eyeVector;

	vec3 light1Vector = gl_LightSource[1].position.xyz + eyeVector;
	vLight1Vector = light1Vector;
	
	vTexCoords = gl_MultiTexCoord0.st;
	gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
}
Let's see if I've got this right. The lighting is in eye space, so the normal needs to be transformed to eye space, which is what the vec3 normal = ... line does. Then a basis for the tangent space is constructed.

The fragment shader expects everything to be in this tangent space, which is what I think the *TBN is for - but wouldn't you have to multiply by the inverse of TBN?
User avatar
kanthoney
Commodore
Commodore
Posts: 281
Joined: Thu Nov 07, 2013 10:21 pm

Re: Split: Planet rendering issues

Post by kanthoney »

Hard terminator with slight reddish-orange tinge? Nailed yer!

Image

I was right, except instead of inverting TBN (which would require a matrix inversion every vertex - not quick) I've pushed TBN to the fragment shader and done everything in eye space there instead. I'll submit a fix tomorrow once I've tidied stuff up a bit.
User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Re: Split: Planet rendering issues

Post by JensAyton »

another_commander wrote:
cim wrote:
another_commander wrote:
This gets to use the same smoothstep code for the terminator in both Normal Shaders and Extra Detail settings.
For planets, Normal Shaders just uses the static pre-shader methods - the shader program is never even executed. There isn't currently any way that the OO_REDUCED_DETAIL code path can be run.
Oops. Hadn't realized that was the case. Please disregard my earlier comment then.
If we’re happy with the new detail settings, we should remove all references to OO_REDUCED_DETAIL.
User avatar
kanthoney
Commodore
Commodore
Posts: 281
Joined: Thu Nov 07, 2013 10:21 pm

Re: Split: Planet rendering issues

Post by kanthoney »

Now I'm baffled again. Changing the specular part of the fragment shader has no effect at all - even turning it off. The shader is loading, because I can make the planet all sorts of pretty colours. Also, commenting out all the bits that change totalColor (or setting gl_FragColor = vec4(0.0, 0.0, 0.0, 1.0)) turns off the clouds but not the planet - I take it that's not right?
User avatar
cim
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 4072
Joined: Fri Nov 11, 2011 6:19 pm

Re: Split: Planet rendering issues

Post by cim »

Also: Lave.
Lave from the same position, having rolled 180.

So maybe a little work still needed in places...
User avatar
kanthoney
Commodore
Commodore
Posts: 281
Joined: Thu Nov 07, 2013 10:21 pm

Re: Split: Planet rendering issues

Post by kanthoney »

Pretty!

Looks like I needed to transpose the matrix vTBN, i.e.

Code: Select all

vTBN = transpose(mat3(tangent, binormal, vNormal));
in the vertex shader. I've pushed that to master.
User avatar
cim
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 4072
Joined: Fri Nov 11, 2011 6:19 pm

Re: Split: Planet rendering issues

Post by cim »

That works, and it looks like the specular highlight is in the right place again, as well.
User avatar
submersible
Commodore
Commodore
Posts: 264
Joined: Thu Nov 10, 2011 7:49 am

Re: Split: Planet rendering issues

Post by submersible »

cim wrote:
That works, and it looks like the specular highlight is in the right place again, as well.
Also for me the pinched lighting at the poles has gone. I wonder if the trouble I've been having with shading the atmosphere is related , since I've copied liberally from the planet shaders.
User avatar
kanthoney
Commodore
Commodore
Posts: 281
Joined: Thu Nov 07, 2013 10:21 pm

Re: Split: Planet rendering issues

Post by kanthoney »

Something was bugging me about this, so I've been investigating further - turns out the problem wasn't what I thought it was. The actual problem is that gl_NormalMatrix is zero for some openGL implementations, which means both the tangent and binormal vectors are zero. In the original shader, this had the effect of projecting out the component of the light vector parallel to the normal, causing the fragment shader to think the light source was always directly above (or below) the fragment, illuminating it fully on the day side and not at all on the night side.

The effect of moving the TBN matrix to the fragment shader was to project out the z-component of the normal map instead of the light position, which sort-of works if you're not bothered about the x and y components of the normal map.
User avatar
kanthoney
Commodore
Commodore
Posts: 281
Joined: Thu Nov 07, 2013 10:21 pm

Re: Split: Planet rendering issues

Post by kanthoney »

Apparently Lave is supposed to look like this, except presumably with more of a shadow. And that really is a snooker ball.

Image
User avatar
kanthoney
Commodore
Commodore
Posts: 281
Joined: Thu Nov 07, 2013 10:21 pm

Re: Split: Planet rendering issues

Post by kanthoney »

Actually, that's what Lave looks like if you put the light source *really* close.
User avatar
Griff
Oolite 2 Art Director
Oolite 2 Art Director
Posts: 2478
Joined: Fri Jul 14, 2006 12:29 pm
Location: Probably hugging his Air Fryer

Re: Split: Planet rendering issues

Post by Griff »

wow guys, that's really starting to look fantastic. it doesn't bother me that the specular highlight is so pronounced, except maybe that square shaped one just to the right of the main specular highlight looks a bit odd,still though fantastic work, just needs the atmosphere effect from submersibles shady planets branch and some city lights on the dark side of the planet and it would be perfect :D
User avatar
kanthoney
Commodore
Commodore
Posts: 281
Joined: Thu Nov 07, 2013 10:21 pm

Re: Split: Planet rendering issues

Post by kanthoney »

Unfortunately, that was a mistake. A damn cool looking mistake, mind!
Post Reply