Shader problem

Started by
4 comments, last by Bob_the_dev 16 years, 1 month ago
I have a shader issue that's been bugging me for a week now, I just can't figure out the problem. I've been following along with the examples in a book I'm reading on DirectX 9 and I tried to combine two of the examples but to no avail. I can't get super detailed now as I'm at work and the code in question's at home, but I do have one last guess as to what the problem is and would like an opinion. What I was trying to accomplish was to make the water in one of the demo applications undulate with a sine wave. I added an external time variable, gTime, to the awter shader and update this variable every frame in the main program. I also added the sine wave function from another demo from the book. And I change the y position of the vertex with the sine functions return. Something like this (semi-pseudocode): vertexVS(posL : POSITION0) { posL.y = sinefunction(posL.x, posL.z); } This should, in theory, cause the vertexes to move up and down the y-axis but what it does instead is create static waves there merely shake oddly back and forth on the x and z planes. The sine function is something like this (I may be getting parts wrong since I'm working from memory): d = (x*x + z*z); return a*sin(k*d + w*gTime + p); I've tried to make the two demo's code as equal as possible but one major difference is that the working sine wave demo uses just a normal primitives grid while the water plane is an optimized mesh. My question is: could the fact that the water plane is an optimized mesh cause this code to not work correctly? Thank you
Advertisement
Quote:Original post by Bob_the_dev
I've tried to make the two demo's code as equal as possible but one major difference is that the working sine wave demo uses just a normal primitives grid while the water plane is an optimized mesh. My question is: could the fact that the water plane is an optimized mesh cause this code to not work correctly?


This shouldn't effect anything. Optimized meshes just have their vertices reordered to maximize vertex cache hits, it should be functionally identical to a list of primitives as far as your vertex shader is concerned.

As for your problem I'm not really sure what's wrong...are you sure your time parameter is being set correctly? If, for example, the demo used seconds and you sent milliseconds that might produce the behavior you're experiencing. A good way to look for problems would be to compile your shader with debug information, and then use PIX to debug the shader. You'll be able to step through the isntructions and verify that your parameters and results look okay.
Quote:Original post by MJP
This shouldn't effect anything. Optimized meshes just have their vertices reordered to maximize vertex cache hits, it should be functionally identical to a list of primitives as far as your vertex shader is concerned.


Ahh ok, that makes sense

Quote:
As for your problem I'm not really sure what's wrong...are you sure your time parameter is being set correctly? If, for example, the demo used seconds and you sent milliseconds that might produce the behavior you're experiencing. A good way to look for problems would be to compile your shader with debug information, and then use PIX to debug the shader. You'll be able to step through the isntructions and verify that your parameters and results look okay.


There's only one time variable and it's the same as the one used in other shaders in the demo, so I'm fairly certain that the problem isn't the time variable. I'll try to debug later as you suggest, thank you.

Just a few more notes on the problem:
-I tried altering the alpha value of the water plane by sin(gTime) and this did what it was expected to, suggesting that it's not the time variable.
-When I change the line in the vertex shader to simply posL.y = gTime; it does absolutely nothing. posL.y = sin(gTime); makes it shake up and down though.
Quote:Original post by MJP
As for your problem I'm not really sure what's wrong...are you sure your time parameter is being set correctly? If, for example, the demo used seconds and you sent milliseconds that might produce the behavior you're experiencing. A good way to look for problems would be to compile your shader with debug information, and then use PIX to debug the shader. You'll be able to step through the isntructions and verify that your parameters and results look okay.


I debugged last night using PIX and was able to confirm that the time variable holds the correct value. Aside from that, I really don't know what to look for anymore. Any other suggestions on where to look for the source of this problem?
Quote:Original post by Bob_the_dev

d = (x*x + z*z);


Shouldn't this be


d = sqrt(x*x + z*z);


I believe d is the distance from the center of a circular wave to the particular point. The distance formula is

square root((x1-x2)*(x1-x2) + (z1-z2)*(z1-z2))

Edit : Seems its the preview in firefox thats not working
Off Topic: For some weird reason the post doesn't show up the plus sign. Is there a special way to do it?
Quote:Original post by totalnut2001
Quote:Original post by Bob_the_dev

d = (x*x + z*z);


Shouldn't this be


d = sqrt(x*x + z*z);


I believe d is the distance from the center of a circular wave to the particular point. The distance formula is

square root((x1-x2)*(x1-x2) + (z1-z2)*(z1-z2))

Edit : Seems its the preview in firefox thats not working
Off Topic: For some weird reason the post doesn't show up the plus sign. Is there a special way to do it?


To be honest I don't know. I know that isn't the source of my problem though.

The shader does create sine waves, it's just that they're static and don't undulate over time. For some very odd reason the time variable doesn't seem to be effecting the sine wave function the way it should be.

This topic is closed to new replies.

Advertisement