2D lighting issue.

[Richard BetsonParticipant]

Please view at 1080p if you can fullscreen.

Hi,

I have posted a video illustrating issues I have been having with lighting and texture filters. I’m getting what looks to me as issues with texture filtering and positioning of images as well as heavy artifact’ing. In the video above I test the same code/resources with TextureFlags.Filter and TextureFlags.None. Checkout the positioning of the space stations using the two different texture flags . To me it’s obvious something is up either with what I am doing or mojo. I’ve tried changing every setting I can think of for the Nvida GPU driver including cranking up antialasing and disabling triple buffering and using FXAA. Nothing seems to help. I have also tried ditching virtual resolution and changing the window layout (mojox) from fill to stretch (even worse with this) all with no solution.

One thing that did seem to help (a bit) was flooring object position floats (x,y) before drawing an image to the canvas. Other then that I can find no issues in my code.

Checkout the video and let me know what you think.

.

Edit: I’m using Monkey2 109c. I’ve tried using the Ubuntu Nvidia repository driver as well as the proprietary driver from Nvidia all exhibiting the same behavior. I’ve also tried it on Mint 17.2 and 18.3 both exhibiting the same behavior. All of the asteroids are loaded as bumpmaps (except the tiny tiny ones). The space stations are loaded as regular images. Both the bumpmap images and regular images use the same texture flags. Perhaps there is an issue (in mojo) relating to positioning between non-bumpmaped and bumpmaped images. Also before asking me to post a code example help me figure out where start.

[EthernautParticipant]

Is the problem the flickering that’s visible around the 40 second mark? It’s really hard to figure out what’s wrong without more info, like:

– What’s the texture resolution? And the canvas (virtual) resolution Vs. the window resolution?
– Can we look at one of the problematic textures?
– Is the texture transparency premultiplied by alpha? Seems like it’s turning white around transparent areas, which is usually related to non-premultiplied textures. What software are you exporting from?
– Are you rendering to a texture? What are the flags in that texture? Or are you just using “straight” Mojo window layouts?

But one thing I’d try out of the gate is using “TextureFlags.FilterMipmap” on everything, instead of just filtering. It will give you better downscaling if the texture size on screen is smaller than the original texture. It won’t fix non-premultiplied textures, though.

[Richard BetsonParticipant]

@ethernaut

Hi, as I indicated above I am using images with the same texture flags and using mojo layout and simply drawing images to canvas. I’m most concerned about the positioning issue when using TextureFlags.Filter as it seems that using that filter with non-bumpmapped ‘images’ (like the space stations seen in video) and bumpmapped ‘images’ does not work correctly. Why are the positions of the space stations adversely effected using TextureFlags.Filter when all other texture filters seem to work (image position wise)?

As far as the artifacting of ‘images’ (simple load image and then draw to canvas) this may be an issue with a normal map or specular map, but I have tried several combinations and all will artifact when using TextureFlags.Filter and TextureFlags.FilterMipmap. I have included a current copy of a bump map image below.

Essentially I am just loading bump mapped and non-bump mapped images with the same texture flags and drawing them to canvas. The only really sophisticated thing am am doing is multiple passes with lighting and shadows, for example :

Monkey

BeginLighting() Calculate image position. DrawImage AddLight EndLighting() BeginLighting() Calculate image position. DrawImage AddLight EndLighting() BeginLighting() Calculate image position. DrawImage AddLight EndLighting()

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

BeginLighting()      Calculate image position.      DrawImage      AddLight EndLighting()   BeginLighting()      Calculate image position.      DrawImage      AddLight EndLighting()   BeginLighting()      Calculate image position.      DrawImage      AddLight EndLighting()

So no real tricks here and pretty much straight forward. Have a look at the bump map images below and let me know what you think.

.

Edit TextureFlags.FilterMipmap also has an issue with lights wiggling there position (similar to the space stations). I may do a video for that as well. If I have to I will work up a code example but I’m hoping not to have to as that would take some time. Hopefully Mark might have insight.

Attachments:

1. 

   elbow_nw.png
   

2. 

   elbow_nw_N.png
   

3. 

   elbow_nw_S.png
   

[Mark SiblyKeymaster]

The spaceships are ‘bouncing around’ because, with no texture filtering, they are ‘jumping’ between integer pixel coordinates. When things move slowly, this jumping will be very noticeable. Didn’t we go through this earlier? What are you expecting to happen here that isn’t? Why does the ‘ bouncing around’ bit appear twice at the start? Is there a difference between the 2 I’m not noticing?

There is definitely a noticeable fringing on the right hand side of some detail sprites at 40s in the video, but a video is kind of next to useless for the purposes of diagnosing what could be going on – please post something short and simple I can run. Ditto there is more apparent fringing going on later in the video too but again there’s no way I can even really guess what’s going on purely from a video.

Are you using a texture atlas at all? It looks a bit like texels are being fetched from the neighboring edges of an atlas. This *will* happen with filtering and you will need to pad atlas frames with a ‘null’ border.

[Richard BetsonParticipant]

@Mark Sibly

Hi, ya we did kind of go over this but what I am experiencing seems to be beyond that discussion. The asteroids and the space stations ‘images’ all use the same texture flag (in video above) so I am confused why if the asteroid (bumpmap images)  and the space station images  (with a common position system) all use the same filtering why do the non-bumpmapped images (space station) move in an irregular fashion (way more then a pixel)  but the bump mapped images do not. I’ll just have to break this out in code all though I was hoping for one of our lot to say “hey dude it’s this” and why I posted a video. I’m behind in my schedule so pressed for time.

I do not use a texture atlas or sprite sheet. Each image (sprite, image) is loaded individually.

I’ll put together am example that clearly outlines the issue. BTW, when I post a video or some such it is often in an effort to get some feedback and direction which often leads to a better code example and a better understanding of the issue involved.

[EthernautParticipant]

Just out of curiosity, can you try these? I removed the alpha from the specular map and re-generated a new normal map using a method that’s probably different than the one you used. Will probably make no difference, but worth trying.

You can probably ignore the color texture and just use yours, I accidentally removed all saturation and saved over it…

(You may need to invert the normals in the Image.LoadBump function)

Attachments:

1. 

   elbow_nw-1.png
   

2. 

   elbow_nw_N-1.png
   

3. 

   elbow_nw_S-1.png
   

[EthernautParticipant]

I also noticed the specular map was not aligned with the other two, that alone is a good candidate to be the cause of the problem! Give a look and let us know.

[Richard BetsonParticipant]

Just out of curiosity, can you try these?

I sure can. Will try them later today.

also noticed the specular map was not aligned with the other two

Hummmm.. That should not be the case, I will take a look at that as well.

I’ll be working on a code example as well later today to illustrate the positioning issue I have described above. I really do understand Marks point about jumping between integer pixel coordinates, but what I am experiencing is well beyond a one pixel jump. In fact if you look closely at the at the first part of the video the base floor (with the light on it left of ship) is moving as I would expect with Textureflags.None (base floor is a bumpmap image). You can also use that base floor as a reference on pixel size with the grate (black crosshatch line looking parts of the image) crosshatch lines which are about 2 pixels wide. Using that as a reference to pixel size it should be come clear how far the non-bumpmapped space station images images are actually moving around. More then a pixel jump (to my eyes) and only the non-bumpmapped images act this way with TextureFlags.None. Even so all of the images use the same texture flag and should move in the same manor.

I should have something late tonight. and thanks for the advice on image/texture maps, I’ll let you know how it turns out.

[Richard BetsonParticipant]

Hi,

I have been tackling the bumpmap artifacting issue I was encountering and ended up changing mojo’s ‘ light.glsl ‘ shader a little bit. I adjusted the normal from this:

normal.xy=normal.xy * 2.0 – 1.0;

To:

normal.xy=((normal.xy * 2.0 – 1.0)*0.5);

This really sweetened things up quite a bit and removed all of the heavy artifacting. Here is a copy of the modified mojo light.glsl shader. Off to work on example code.

Monkey

//@renderpasses 4,5 varying vec2 v_TexCoord0; varying vec2 v_LightPos; varying vec4 v_Color; varying vec2 v_GBufferCoords; varying vec2 v_FragPos; //@vertex attribute vec4 a_Position; attribute vec2 a_TexCoord0; attribute vec2 a_TexCoord1; attribute vec4 a_Color; uniform mat4 r_ModelViewMatrix; uniform mat4 r_ModelViewProjectionMatrix; uniform vec2 r_ViewportOrigin; uniform vec2 r_ViewportSize; uniform vec2 r_ViewportClip; uniform vec2 r_GBufferScale; uniform vec4 m_ImageColor; void main(){ v_TexCoord0=a_TexCoord0; v_LightPos=a_TexCoord1; v_FragPos=a_Position.xy; v_Color=m_ImageColor * a_Color; gl_Position=r_ModelViewProjectionMatrix * a_Position; vec2 vpcoords=(gl_Position.xy * 0.5 + 0.5) * r_ViewportSize; v_GBufferCoords=(vpcoords + r_ViewportOrigin) * r_GBufferScale; } //@fragment uniform sampler2D m_ImageTexture0; //image texture uniform float m_LightDepth; uniform sampler2D r_GBuffer0; //gbuffer diffuse uniform sampler2D r_GBuffer1; //gbuffer normal void main(){ vec3 normal=texture2D( r_GBuffer1,v_GBufferCoords ).xyz; float gloss=normal.z; normal.xy=((normal.xy * 2.0 - 1.0)*0.5); normal.z=sqrt( 1.0-dot( normal.xy,normal.xy ) ); //diffuse... // vec3 lvec=normalize( vec3( v_LightPos-v_FragPos,m_LightDepth ) ); float ndotl=max( dot( normal,lvec ),0.0 ); vec4 tcolor=texture2D( m_ImageTexture0,v_TexCoord0 ) * v_Color; vec4 diffuse=texture2D( r_GBuffer0,v_GBufferCoords ) * tcolor * ndotl; //specular... // vec3 hvec=normalize( lvec+vec3( 0.0,0.0,1.0 ) ); float ndoth=max( dot( normal,hvec ),0.0 ); vec4 specular=tcolor * pow( ndoth,128.0 ) * gloss; #if MX2_RENDERPASS==5 float shadow=texture2D( r_GBuffer0,v_GBufferCoords ).a; diffuse*=shadow; specular*=shadow; #endif //tada! // gl_FragColor=vec4( diffuse.rgb+vec3( specular.a ),0.0 ); }

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91

//@renderpasses 4,5   varying vec2 v_TexCoord0; varying vec2 v_LightPos; varying vec4 v_Color;   varying vec2 v_GBufferCoords; varying vec2 v_FragPos;   //@vertex   attribute vec4 a_Position; attribute vec2 a_TexCoord0; attribute vec2 a_TexCoord1; attribute vec4 a_Color;   uniform mat4 r_ModelViewMatrix; uniform mat4 r_ModelViewProjectionMatrix;   uniform vec2 r_ViewportOrigin; uniform vec2 r_ViewportSize; uniform vec2 r_ViewportClip;   uniform vec2 r_GBufferScale;   uniform vec4 m_ImageColor;   void main(){   v_TexCoord0=a_TexCoord0; v_LightPos=a_TexCoord1; v_FragPos=a_Position.xy; v_Color=m_ImageColor * a_Color;   gl_Position=r_ModelViewProjectionMatrix * a_Position; vec2 vpcoords=(gl_Position.xy * 0.5 + 0.5) * r_ViewportSize; v_GBufferCoords=(vpcoords + r_ViewportOrigin) * r_GBufferScale; }   //@fragment   uniform sampler2D m_ImageTexture0; //image texture uniform float m_LightDepth;   uniform sampler2D r_GBuffer0; //gbuffer diffuse uniform sampler2D r_GBuffer1; //gbuffer normal   void main(){   vec3 normal=texture2D( r_GBuffer1,v_GBufferCoords ).xyz; float gloss=normal.z; normal.xy=((normal.xy * 2.0 - 1.0)*0.5); normal.z=sqrt( 1.0-dot( normal.xy,normal.xy ) ); //diffuse... // vec3 lvec=normalize( vec3( v_LightPos-v_FragPos,m_LightDepth ) ); float ndotl=max( dot( normal,lvec ),0.0 ); vec4 tcolor=texture2D( m_ImageTexture0,v_TexCoord0 ) * v_Color;   vec4 diffuse=texture2D( r_GBuffer0,v_GBufferCoords ) * tcolor * ndotl; //specular... // vec3 hvec=normalize( lvec+vec3( 0.0,0.0,1.0 ) ); float ndoth=max( dot( normal,hvec ),0.0 ); vec4 specular=tcolor * pow( ndoth,128.0 ) * gloss; #if MX2_RENDERPASS==5   float shadow=texture2D( r_GBuffer0,v_GBufferCoords ).a; diffuse*=shadow; specular*=shadow;   #endif //tada! // gl_FragColor=vec4( diffuse.rgb+vec3( specular.a ),0.0 ); }

[Richard BetsonParticipant]

So.. ya..

I tried above and it worked well but not what I wanted and not really the right way. I ended up looking at the textures that Mark used for simple light and noticed that none of the bump-map textures used an alpha channel (RGB). So I removed the alpha channel from both the normal and specular maps and made the former alpha’ed areas black (RGB(0,0,0)). This works pretty well and appears to remove nearly all of the artifacting. I left the diffuse texture with an alpha channel. Edging the alpha’ed areas of the diffuse image in black also seems to help. This might have been what Ethernaut was trying to get across to me, either way it seems to solve the specular issue without resorting to changing a shader.

My only real issue left is my issue with positioning and textureflags, which I will code out in example form. After messing with mojo’s shaders I am interested in doing more with shaders.

[Mark SiblyKeymaster]

An image property that may be use here is light depth, eg: image.LightDepth=blah (defaults to 100.0).

This is the z coordinate of the light, ie: its distance from the plane being lit, and increasing it should mellow out lighting a bit.

[Author]

Posts