NormalMapping

Dafb · July 2020

So from the normal map gideros example, I changed the picture with a normalmapped version of my project main sprite. And I was very impressed by the change!

I started to imagine the lights produced by lasers and missile exhausts changing in real time the appearance of all the ships on the battlefield, and I was "Woooow!... that would just give my game such a high professional touch!"

So much wow that I started to worry about 2 things:
- performance : would a phone be able to withstand about 50 moving ships and 50 moving lights?
- time to learn : I know nothing about shaders. How difficult it is to learn? I know how to create a normal map file. But that's it. What I need to learn especially is how to place/move the lights. How hard is that?

Also I didn't try it, but do we still need power of 2 sized textures?

MoKaLux · July 2020

Don"t worry about performance, try to get the desired effect, then you will find ways to make it perfect (sprite sheet, pooling...). The same for shaders, if the gideros example is all you need then you are good to go. As for the power of 2 i think it is still needed but you can experiment

I like the look of your game.

Dafb · July 2020

I like the look of your game.

Thanks. If I manage to use these shaders properly, it will look even better

.

Playing around, I understood how to make new lights, change their color and place them (or so I think).

I'll give the normal map version a try.

I need to check on the power of 2 requirement because it is messing big time with my actual sprites and the ones I wanted to implement next.

oleg · July 2020

Dafb said:
So from the normal map gideros example, I changed the picture with a normalmapped version of my project main sprite. And I was very impressed by the change!

I started to imagine the lights produced by lasers and missile exhausts changing in real time the appearance of all the ships on the battlefield, and I was "Woooow!... that would just give my game such a high professional touch!"

So much wow that I started to worry about 2 things:
- performance : would a phone be able to withstand about 50 moving ships and 50 moving lights?
- time to learn : I know nothing about shaders. How difficult it is to learn? I know how to create a normal map file. But that's it. What I need to learn especially is how to place/move the lights. How hard is that?

Also I didn't try it, but do we still need power of 2 sized textures?

You need to create 1000 ships in the scene and conduct profiling
https://wiki.giderosmobile.com/index.php/Profiling

Dafb · July 2020

Thank you for leading me to this link.

However, continuing to play with the above example, it seems that a given mesh cannot get more than 1 shader, which is a problem in my current scenario. It seems to be a shader issue regardless of the type of engine. Am I correct?

hgy29 · July 2020

Yes, the shader is applied only once per frame, when the mesh is drawn. If you need multiple lights, you must change the shader and give it an array of light sources, but anyhow 50 lights is big.

oleg · July 2020

Dafb said:
Thank you for leading me to this link.

However, continuing to play with the above example, it seems that a given mesh cannot get more than 1 shader, which is a problem in my current scenario. It seems to be a shader issue regardless of the type of engine. Am I correct?

I in the game 'sokoban' used lamps on boxes, there is 1 lamp but many boxes - everything works perfectly.
https://play.google.com/store/apps/details?id=info.simart.sokoban2018
You don't need to make many lamps, you can make many objects with individual lamps

In another game I tested that there were 6 lamps in the scene that affect all objects - on weak devices such a scene will not work ..

Dafb · July 2020

but anyhow 50 lights is big.

In another game I tested that there were 6 lamps in the scene that affect all objects - on weak devices such a scene will not work ..

Yes, you are both right. I have to make some compromises. I'll try some stuff. For example a global light for all ships, and switching to a closer light from a projectile when it comes close to its target, applying the related shader only to this target.

MoKaLux · July 2020

I can't wait playing it

Dafb · July 2020

MoKaLux said:
I can't wait playing it

Well, I need to make it work first!

I am sorry, I have other questions!

1) Why the alpha does not show a blank background and shows instead this gray surface? How to make it work as intended?
I played a little bit with the colors and in fact the "alpha" takes the color of the shader (see below with the red shader)

2) I changed the code to move light position with the mouse. It seems to behave like the sprite stayed at 0,0 despite it being at the middle of the stage. How do I make the shader take in account the position of the sprite?

3) The orientation of the light/shadows seems off. But it may be because of the automatic generation of the normal map file. (after more verifications, it seems the X is correct but the Y seems inverted)

Here are the shader codes (almost identical to the original files from the gideros example)

vs.glsl

attribute vec4 POSITION0;
attribute vec2 TEXCOORD0;
 
uniform mat4 g_MVPMatrix;
 
varying vec2 position;
varying vec2 texCoord;
 
void main()
{
	texCoord = TEXCOORD0;
	position = POSITION0.xy;
	gl_Position = g_MVPMatrix * POSITION0;
}

ps.glsl

uniform lowp sampler2D g_Texture;
uniform lowp vec4 g_Color;
 
uniform mediump vec4 lightPos;
 
varying highp vec2 texCoord;
varying mediump vec2 position;
 
void main()
{
	lowp vec3 color0 = texture2D(g_Texture, texCoord).rgb;
	lowp vec3 color1 = vec3(0.9, 0.1, 0.1);
	mediump vec3 normal = texture2D(g_Texture, texCoord + vec2(0.5, 0.0)).rgb * 2.0 - 1.0;
	mediump vec3 lightDir = normalize(vec3(lightPos.xy, 150) - vec3(position.xy, 0));
	mediump vec3 halfdir = normalize(normalize(lightDir) + vec3(0, 0, 1));
 
	lowp float diff = max(0.0, dot(normal, lightDir));
	mediump float nh = max(0.0, dot(normal, halfdir));
	mediump float spec = pow(nh, 10.0);
 
	gl_FragColor = g_Color * vec4(color0 * diff + color1 * spec, 1);
}

And here is the animation of the Gideros player

hgy29 · July 2020

1) this is because the ‘a’ component of the sampled texel is discarded. The final equation always set the alpha to 1.
2 and 3) because in the fragment shader the position of the sprite is in normalized device coordinates (they have been transformed in the vertex shader), while your light position wasn’t.

rrraptor · July 2020

One more thing about alpha and shaders:
http://forum.giderosmobile.com/discussion/7988/gl-fragcolor-alpha-issue

Dafb · July 2020

Thanks to your helps, I got the alpha working. The code might be not be the best, but it works:

vec4 tex=texture2D(g_Texture,texCoord.xy);
	vec4 bump = g_Color * vec4(color0 * diff + color1 * spec, 1);
	vec4 alpha = vec4(1.0, 1.0, 1.0, tex.a);
	gl_FragColor = bump * alpha;

I am still struggling with the light devices coordinates though.

Howdy, Stranger!

Categories

In this Discussion

Top Posters

NormalMapping

Comments

Howdy, Stranger!

Quick Links

Categories

In this Discussion

Top Posters

NormalMapping

Comments