jMonkeyEngine.org

I’m working on a shader for rendering moving textures. The original one I set up where you simply pass in the offset, works just fine, however… when I updated it to pass in a the speed and direct… it still worked! hah… until… I alter the speed and direction. Then the texture jumps to new coords and begins acting normal again. I’m doing this on complete trial and error… so bare with any bad implementation issues. I have done no clean up, since I have had 0 luck tracking down why this happens.

Is this due to the shader being recompiled when updating these variables in the .vert? The alpha is being updated and effects nothing… but it is also only being used by the .frag.

Anyways… any help here would be greatly appreciated! Here is the .vert .frag files:

MovingTextured.vert:

uniform mat4 g_WorldViewProjectionMatrix;
uniform float g_Time;
attribute vec3 inPosition;
uniform float m_Alpha;
uniform float m_Speed;
uniform float m_Direction;

#if defined(HAS_COLORMAP) || (defined(HAS_LIGHTMAP) && !defined(SEPARATE_TEXCOORD))
    #define NEED_TEXCOORD1
#endif
#if defined(IS_MOVING) && defined(HAS_DIRECTION)
	#define MOVE
#endif

#ifdef NEED_TEXCOORD1
    attribute vec2 inTexCoord;
    varying vec2 texCoord1;
#endif

#ifdef SEPARATE_TEXCOORD
    attribute vec2 inTexCoord2;
    varying vec2 texCoord2;
#endif

#ifdef HAS_VERTEXCOLOR
    attribute vec4 inColor;
    varying vec4 vertColor;
#endif

void main(){
    #ifdef NEED_TEXCOORD1
		texCoord1 = inTexCoord;
		#ifdef MOVE
			float xInc = ((m_Speed*g_Time)*sin(m_Direction));
			float yInc = ((m_Speed*g_Time)*cos(m_Direction));
			if (xInc > 1.0) xInc -= 1.0;
			else if (xInc < 0.0) xInc += 1.0;
			if (yInc > 1.0) yInc -= 1.0;
			else if (yInc < 0.0) yInc += 1.0;
			texCoord1 += vec2(xInc,yInc);
		#endif
	#endif

    #ifdef SEPARATE_TEXCOORD
        texCoord2 = inTexCoord2;
    #endif

    #ifdef HAS_VERTEXCOLOR
        vertColor = inColor;
    #endif

    gl_Position = g_WorldViewProjectionMatrix * vec4(inPosition, 1.0);
}

MovingTextured.frag:

uniform vec4 m_Color;
uniform float m_Alpha;

#if defined(HAS_GLOWMAP) || defined(HAS_COLORMAP) || (defined(HAS_LIGHTMAP) && !defined(SEPARATE_TEXCOORD))
    #define NEED_TEXCOORD1
#endif
#if defined(IS_MOVING) && defined(HAS_DIRECTION)
	#define MOVE
#endif

#ifdef HAS_COLORMAP
    uniform sampler2D m_ColorMap;
#endif

#ifdef NEED_TEXCOORD1
	#ifdef MOVE
	    varying vec2 texCoord1;
	#endif
#endif

#ifdef HAS_LIGHTMAP
    uniform sampler2D m_LightMap;
    #ifdef SEPARATE_TEXCOORD
        varying vec2 texCoord2;
    #endif
#endif

#ifdef HAS_VERTEXCOLOR
    varying vec4 vertColor;
#endif

void main(){
    vec4 color = vec4(1.0);

    #ifdef HAS_COLORMAP
		#ifdef MOVE
	        color *= texture2D(m_ColorMap, texCoord1);
		#endif
    #endif

    #ifdef HAS_VERTEXCOLOR
        color *= vertColor;
    #endif

    #ifdef HAS_COLOR
		vec4 n_Color = vec4((m_Color[0]*color.a),(m_Color[1]*color.a),(m_Color[2]*color.a),color.a);
		color = mix(color, n_Color, 0.25f);
    #endif

    #ifdef HAS_LIGHTMAP
        #ifdef SEPARATE_TEXCOORD
            color.rgb *= texture2D(m_LightMap, texCoord2).rgb;
        #else
            color.rgb *= texture2D(m_LightMap, texCoord1).rgb;
        #endif
    #endif

	#ifdef HAS_ALPHA
		color.a *= m_Alpha;
	#endif

    gl_FragColor = color;
}

@pspeed Hmmm… it doesn’t jump ever, unless I change the direction or speed. It runs nice & smooth. (constant speed)

m_Speed is a float set between .025 and .05 for my purposes (basically anything between 0 and 1 works).
m_Direction is between -HALF_PI and HALF_PI
the checks right below the first two lines cycle the xInc/yInc to stay between 0 and 1. Since the texture is tiled, it is a very smooth transition as it moves.

I just can’t figure out why when I update m_Speed or m_Direction I get a huge jump to new coords before it starts running smooth again.

And by the way… if you have wrap mode on for your texture then you shouldn’t need to clamp/mod at all.

@pspeed I was under the assumption the g_Time was the time the shader took to render a frame (pass, whatever). Either way, I can fix that… but will it effect the issue I am seeing? I would think it would happen every time it renders… not just when I update those variables (which happens very infrequently).

I’ll try removing g_Time… and pass in the tpf from the update loop. Otherwise, it would speed up and slow down depending on CPU usage. But, I was hoping to avoid constantly updating the material.

Who knows… maybe that will fix it /shrug. Any other thoughts?

Just switch direction from the current point.

And… very funny, I was just about to post that g_Time was the whole reason it was working in the first place… but you beat me to it.

Soo… how do I use in / out variables? They are supposed to be the value from the last frame rendered. However, my attempts so far aren’t showing this to be the case. Wouldn’t this solve the issue? i.e. some in variable that is += g_TPF until it is greater than 1… then reset to 0. This would ensure that the m_Direction wouldn’t do what you said above.

@pspeed I am starting to think this headache I have is making me temporarily retarded.

Basically what I would like to do is either:

1. get texCoord1 from the previous rendered frame.
OR
2. get texCoord1 from the previous rendered frame.

Thats pretty much what I need

@pspeed Oh… sorry.

I am updating the shader I am using to move clouds. At the moment, I determine the offset from the original clamp in the update loop and pass it in to move the texture. However, it seems silly to continuously pass in an offset when the shader should be capable of doing it.

For instance…

if the current texCoord1 = 0.457, 0,0312
I need to += it by .055, -0.12 (these are the xInc, yInc variables)
If the direction or speed changes… the xInc, yInc should change by only a small fraction.

Basically it should look like this:

xInc += (speed*sin(rotation));
yInc += (speed*cos(rotation));

But this complete depends on knowing the previous x,y coord. Unless the rotation or speed changes, xInc and yInc will always be constant.

According to GLSL references… variable types can be:

attribute, varying, uniform, in or out…

in reads in the previous value from the last render loop….

but I can’t seem to get it working right /boggle

I don’t think that in/out can be used the way you want since at best they are for multiple stages in the same render pass… not for accumulating state from one render pass to another.

Do all of your clouds move in the same direction?

If so then maybe it is probably better to move the geometry. Attach them all to a node and move them together. Mythruna puts its clouds on quads oriented in a giant sphere-like shape and then I can just rotate the center node. I have several layers that move slightly differently. In the vert shader I collapse the Z value and multiple x,y so the horizon looks really far away.

Otherwise, there is no way around passing an offset into your shaders, I think.