This is getting annoying

[The_Glitch]

Fixed My shader It was what I suspected the matrices.

[Christi258]

Code: Select all

 
        services->setVertexShaderConstant("matworld", world_pointer.pointer(), 16);
        services->setVertexShaderConstant("matworldviewprojection", WorldViewProj.pointer(), 16);
 

Yeah, a small formal error, you forgot the ' " '
But the rest is OK.

[The_Glitch]

Actually that's wrong I use the shader pipeline branch, nice try though.

[Destructavator]

Typically I'm an OpenGL / GLSL guy, so I could be off here, but I noticed you are sending the matrix "WorldViewProj" to a name in quotes (which I'm guessing is the name in the shader) called "matworldviewprojection" but in your shader code you have the name as "matWorldViewProj"

One name has the word "projection" spelled out (including the "-ection" part at the end) but the other does not.

I'm guessing (as I normally do GL stuff) that in this case uppercase vs. lowercase doesn't matter, but what might matter is that "matworldviewproj" != "matworldviewprojection".

Does this help?

[The_Glitch]

No that's not it either. My matrix is pre assigned a variable name which is what you guys see. In shader pipeline the string name is pre assigned to a variable name which is what you see without the quotes. I just didn't post that part of the code. I think the problem is there's something in my shader that rendermonkey understands fine and Irrlicht doesn't. I'm just having a hard time figuring it out. I'll stick with asking Nadro. Thanks for your help guys. I really want to get this working and add it to Irrlicht myself so people can have good looking options for water with evlfmans water and mine.

[Granyte]

at this point i would say release the code so we can help

i have seen cases where the shader compilation fail silently in HLSL so you are left with a blank screen and no warning it might be one of those cases

[hendu]

That's a horrible title ("This is getting annoying"). You can't expect people to read what it's about.

Hint: "How to pass HLSL matrices?"

[Destructavator]

at this point i would say release the code so we can help

Agreed. It was mentioned in the first post that this is intended to be given to the community, possibly added on to Irrlicht, perhaps you could post the whole thing as a draft proposal of some kind, making it clear it isn't the final version and just needs a few bugs ironed out. That, and the fact that any time something is released for a lot of other people to use in their code, there's likely going to be bug-killing, updates, and later revisions at some point anyways, I can't think of any real example of a case where someone releases software or code just once then says "OK, I'm done, I'm never going back to it" and no revision ever comes out. At least no *decent* programmer does that, not the good ones. And, of course, there's always the case where someone thinks they have a working version 1.0, puts it up for the first time, and someone with a different toolchain / compiler / build environment / computer / time of day when the phase of the moon is different / whatever tries to use it and finds a problem that needs to be fixed. Yup, been there, done that, seen that, I'm sure you know how it goes...

[The_Glitch]

Fixed my shader

[Destructavator]

I notice you are initializing a float variable in your CPP code, "T", to 0.0f, which you are then sending to "Tile" - Is this desired, or a mistake?

I normally do GLSL, but the line in your shader:

OUT.alphaMapTC = IN.texCoord * Tile;

...So you are multiplying a texture coordinate by zero, meaning the result will probably always be zero across the board for every pixel fragment, unless of course DirectX shaders do some kind of non-standard funky math trick with floating-point zeros that I'm totally unaware of.

Is this intentional, or because you were trying to "turn off" something for debugging purposes, trying to simplify things by taking certain variables out of the math temporarily?

I'm sure you know by now that even if Matrices are OK, having bad texture coordinate computations can lead to issues that can mess stuff up as well...

Also, do you have a screen shot of what you *want* the result to look like? That would help a little.


EDIT: I also see *another* issue, this one indeed with the matrix math, possibly:

In my own code for my own project, I multiply matrices together like this:

Code: Select all

        mt_worldView = mt_view * mt_world;
        mt_worldViewProj = mt_projection * mt_view * mt_world;
 

...And then if I want to get an inverse of the end-result, I take the final "mt_worldViewProj" and call a getInverse() or makeInverse() or similar function on it (I forget exactly what the function name is). I find that the end result then plugs right into a GLSL shader, no problems.

For DirectX-based stuff, I don't know, though, so this might not be the problem.

...But according to my own research, the code I just put in this post is how a matrix should be multiplied properly for OpenGL. In looking at other code examples for GL on the web, other hand-coded examples also do it in this order, which can seem counter-intuitive. (Yes, I know it looks backwards, reading it. It got me too, with my own project, and I didn't get it right until after much cursing and swearing...)

EDIT(2):

From the official tutorial on shaders, from the "trunk" SVN repo (if this helps at all), which does things a little differently still:

Code: Select all

class MyShaderCallBack : public video::IShaderConstantSetCallBack
{
public:
 
  virtual void OnSetConstants(video::IMaterialRendererServices* services, s32 userData)
  {
    video::IVideoDriver* driver = services->getVideoDriver();
 
    // set inverted world matrix
    // if we are using highlevel shaders (the user can select this when
    // starting the program), we must set the constants by name.
    core::matrix4 invWorld = driver->getTransform(video::ETS_WORLD);
    invWorld.makeInverse();
 
    if (UseHighLevelShaders)
       services->setVertexShaderConstant("mInvWorld", &invWorld.M[0], 16);
    else
       services->setVertexShaderConstant(&invWorld.M[0], 0, 4);
 
    // set clip matrix
    core::matrix4 worldViewProj;
    worldViewProj = driver->getTransform(video::ETS_PROJECTION);            
    worldViewProj *= driver->getTransform(video::ETS_VIEW);
    worldViewProj *= driver->getTransform(video::ETS_WORLD);
 
    if (UseHighLevelShaders)
       services->setVertexShaderConstant("mWorldViewProj", &worldViewProj.M[0], 16);
    else
       services->setVertexShaderConstant(&worldViewProj.M[0], 4, 4);
        
    // set camera position
    core::vector3df pos = device->getSceneManager()->
    getActiveCamera()->getAbsolutePosition();
 
    if (UseHighLevelShaders)
      services->setVertexShaderConstant("mLightPos", reinterpret_cast<f32*>(&pos), 3);
    else
      services->setVertexShaderConstant(reinterpret_cast<f32*>(&pos), 8, 1);
 
    // set light color 
    video::SColorf col(0.0f,1.0f,1.0f,0.0f);
 
    if (UseHighLevelShaders)
      services->setVertexShaderConstant("mLightColor", reinterpret_cast<f32*>(&col), 4);
    else
      services->setVertexShaderConstant(reinterpret_cast<f32*>(&col), 9, 1);
 
    // set transposed world matrix
    core::matrix4 world = driver->getTransform(video::ETS_WORLD);
    world = world.getTransposed();
 
    if (UseHighLevelShaders)
      services->setVertexShaderConstant("mTransWorld", &world.M[0], 16);
    else
      services->setVertexShaderConstant(&world.M[0], 10, 4);
    }
};

It uses a makeInverse() function I still don't see in your C++ code, before you pass the data to the shader.

[The_Glitch]

All the things you suggested I have done. I set tile to zero like you said " testing purpose's". Giving it it's default value in rendermonkey yields the same result. Also your explanation on matrices I've already done also. I've assigned matworld to View * World and in reverse and still nothing. I'll see If I can post what the plane looks like with the shader applied. It basically looks grey nothing working no textures anything. So as a test I assigned one of my other shaders to the plane model "water" and it works fine. Also what do you mean what do I want it to look like??? I want it to look like the actual shader in my pics above.

[Destructavator]

Hmmm.... I see another issue:

Code: Select all

float time = (float)device->getTimer()->getTime() / 100.0f;
 
 
        f32 Animation = time;
        services->setVertexShaderConstant(TIME, reinterpret_cast<f32*>(&Animation), 1);
 
 
        f32 WS = time;
        services->setVertexShaderConstant(wave_speed, reinterpret_cast<f32*>(&WS), 1);

This is using the Irrlicht timer in a funny way that I wouldn't recommend.
From my own experience, unless you actually reset the Irrlicht ITimer by using the setTime() function, calling the getTime() function gets the *total* time since back whenever the timer was started, typically at the start of your program, in ms (thousandths of a second), which means you are sending an increasing value to not only the animation, but also jacking up the "wave_speed" by 10 every second. So if your application has been running for just three seconds, you have a speed setting sent to the shader of 30.0f.

If you want to actually get the elapsed time since the last time you checked for it, you need to have a variable you keep around where you store the time since the start of the entire application, and compare it to the value when it was last copied from getTime(); which by default returns a u32.

So, an example:

u32 total_time; // declared in the class, or somewhere in your program, perhaps even a global variable;

Every frame, or every loop of your main program loop:

const u32 new_time = ITimer->getTime();
const u32 time_since_last_frame = new_time - total_time; // NOW we have a value of time since we last checked!
total_time = new_time; // For the next time we check...

f32 value_to_send_to_shader = (f32) time_since_last_frame; // Cast the elapsed value to a float
value_to_send_to_shader *= ... / Multiply by whatever desired factor

...Then send "value_to_send_to_shader" to your shader as an input variable.

If you fail to do it this way, you can easily end up with water scrolling so d*** fast it blurs into a solid-looking mess or block of some kind.

Also, again, you're sending the time value to two inputs, both the animation value as well as the speed, something that RenderMonkey might not be doing.

Try either temporarily using fixed, test values for the inputs for wave animation and speed (the quick way), or write some more code to properly get the elapsed time (a little more work, but you might fix the problem this way).

If you're still having issues after this, try fiddling with any other values that Irrlicht is supposed to provide, values which you are expecting to be the same in RenderMonkey but for whatever reason might not be properly supplied by Irrlicht for whatever unknown reason.

That's about all I can offer at this point, without actually running your code in a complete application demo.

EDIT: Actually, just thought of one other thing: Irrlicht can be difficult with multiple textures in a SMaterial, in some cases only using the first texture layer sometimes. I know with OpenGL you often have to send additional constants to the vertex shader (integer values) for the actual texture samplers sometimes, with a value of 0 for the first sampler, 1 for the second texture, 2 for the third, 3 for the fourth, etc. Failing to do this can sometimes cause use of only the first texture, at least with the OpenGL driver. I'm not sure, but the same *might* be true with DirectX shaders. If the resulting render looks like the very first texture layer, as if no other layer is being used, this is a hint of what is going on.

Hope something from all that helps, sorry I'm also having difficulty in quickly helping you find the issue, and good luck!

[The_Glitch]

I'll try setting the values in the shader itself to test further. Also I've never had a texture issue. normally what order in the shader you declare texture samplers was the order Irrlicht expected them. Hopefully others will post. I will test further and post back.

[The_Glitch]

I've found the problem It was not anything you suggested, It was what I thought it was the matrices. Thanks for your help I'll fix the Timer also.

[The_Glitch]

Not bad for large volumes of water, you can change the blend and everything. And still get thousands of frames

I'm going to go ahead and get started making it where the user just adds a head and source to use it and that's it simple as can be. And I'm going to go ahead and comment everything heavily


Not sure If users would really want it.