wraitii

I'll try that. I have no idea what the instancing matrix is... On the ARB shader, the calculations works and the normals don't look completely wrong, but they might be. I also have the modelview matrix accessible, I'll try and compare the two.

Yeah, I realized that later, but I posted too early in excitement. So yes, I believe my problem is with the instancing matrix. Only it seems to work for the position.

Thanks for answering. As you can see from my edit above, I've got why it didn't work... Edit: need to change v_tangent = tangent to v_tangent = a_tangent too. EditN°2: thought that may break other things... EditN°3: so there actually is something with the matrix calculation…

Complete edit: got it! Live 92 of model_common.vs, change v_normal = normal; to v_normal = a_normal;.

That's the basic idea. Going back to the original issue: I have a problem with GLSL on my Geforce GT 120. It also happens with regular SVN. model_common bugs. I've tracked it down to: v_normal (and incidentally v_tangent/v_bitangent). Now this is sent to the fragment shader by the vertex shader. Here, the problem can't be with InstancingTransform as the position is OK, and it uses that. Since v_normal only calls a_normal, the problem resides in a_normal. Now what is a_normal? It's defined as an attribute, asking for gl_Normal. Let's investigate Shader_manager.cpp. gl_Normal is there defined to have location "2", as documented by nvidia. Afaik, this is right. Now, when creating the shader, Shader_manager.cpp will set this "a_normal" as an attribute in vertexAttribs["a_normal"] = 2 (I believe). Vertex attribs are then passed to the GLSL shader. This is where it starts to differ from the ARB shader (which, remember, works, so we know that the problem is not in reading the files/passing the normals). Going into Shader_program.cpp, it calls CShaderProgramGLSL. This set "m_VertexAttribs" as the vertex Attributes. Lines of interest are now 347/348, where "pglBindAttribLocationARB" is called; lines 489-505, where "Bind" and "Unbind" are defined; lines 633-653 where VertexAttribPointer and VertexAttribIPointer are defined. Base on previous research, I also know that InstancingModelRenderer.cpp has something to do with that. When "stream_normal" is set (and it is), it will use NormalPointer (a overriden function that calls pglVertexAttribPointerARB, in position 2 (the same as defined by Nvidia). According to "glexts_funcs.h", this is equivalent to "glVertexAttribPointer", ie that. No reason to believe this bugs, in particular because the TexCoordPointer and the VertexPointer seem to work just fine. There are other function calls that do other things. I'm not completely sure, as everything calls everything else. But I have no idea why this doesn't work for GLSL when it works for ARB.

Basic solution would be to have bigger textures, and use bigger blending masks.

I may be wrong, but this looks like an actual vertex displacement effect and not a texture simulation. (which would explain the "backyard water" effect too, as this would require huge computing power to simulate an ocean perfectly.)

It's probably easier to add a transparent "wave" texture like most games probably do.

I dunno, boat waves are fairly small things that would require precision. Perhaps we could trick it by using a 1024x1024 texture to say "where" we want the waves to be, and then have some smaller textures to actually represent the waves.

Wouldn't that require a huge texture, though? The normals are basically a repetition of a small one, but using this efficiently would change that, or am I mistaken here?

I don't think the game has enough vertices to support that on a per-vertex basis. I could be done with fairly big waves, but then we would not require that kind or precision (I actually gave that a small shot 3 days ago, you can achieve a nice effect for a bargain cost right now). No idea how it would work on a fragment program, but I think it would require a (way too big) texture, unless I'm mistaken (how do shadows work?). For boats and waves, the easiest system right now (with water as a flat plane) is probably to use a stencil over the water and to use bump mapping/parallax on that to achieve the effect of waves. Then again, I say "easiest", but it's also quite some work. @zoot: pulled your fix, thanks! And I'm glad to know it's working.

I'm not too sure about the CG compiler... And I'm not sure it would work given the architecture of the shaders themselves. It would be efficient, but for robustness, redoing them is probably the best way. I've committed the fix for the waterShader branch, it should work but there might be a place I forgot. The modelMapping branch will have to wait as I've started coding the Parallax stuff.

Could be. Try adding TEMP temporary; MOV temporary, 0.8; just before the POW line( using POW fresnel, fresnel.x, 0.8; ).

Actually, since it's two inputs, but one output, it should work. The thing is that it seems to consider that "1.0" is not a scalar, for some reason... On my computer, there's no issue, which further baffles me.

@Zoot: and by changing to POW fresnel, 1, 1; ? @Myconid: that would be an option. I'll look into that.

That's strange... There is no reason for it to crash at this particular point. You're sure you haven't changed anything? Does it work it you replace the line 76 with something like: POW fresnel, 0.5, 0.8; (I mean: no error. The result should be slightly messed up). @myconid: given that you're using a "while" loop, I have no idea how much I'd need to roll... And anyway the basic ARB shader also hasn't have an "IF" statement. I'll try with the extension and we'll see.

Okay, I've pushed the changes to the Modelmapping Branch. I've tried cleaning things up as most as I could, it should work still, but again, I'm not 100% sure. You will need to set "calculateTangents" to true in the game's config file (I haven't changed the warning set by Myconid, but it should now work). Specular and diffuse normal mapping should be visible on the model Rome_Temple_Mars 2, not yet on terrain. @Myconid: seeing how much trouble I've had with the two (in the end, fairly basic) patches, I'll try to give a look but I wouldn't swear I can do that. Edit: water patch doesn't seem to fix #966, sadly. Edit2: there may be hope for parallax mapping if the computer supports the GL extension "GL_NV_fragment_program2", which came out in 2004 (and which my computer supports, so that's nice).

Haven't checked, but I would guess no. That would require to handle the shadow matrix differently, I think, which I have not done/changed.

Yeah, I've used windows endlines and not unix endlines. Fixed it now, but I didn't bother to when committing that. FYI, in that file, the only stuff that's changing is at lines 675/676/677/678 .

It's quite allright . The water shader should be available here. I changed the GLSL script to give the same result as the ARB shader, but I'm not sure I haven't forgotten something so if the GLSL shader acts weirdly, report. I'll look into the modelmapping issue now.

Thanks for the help. I'm off to eat, I'll try to push the water shader code in the afternoon. In the meantime, here's an album showing the differences.

Okay, so I've ported the water shader to ARB. It's been surprisingly straightforward, this time. The code and everything else works nicely, however, I'm not too sure how to push that to github/wherever... I'm not used to those things. Any tutorials/guidelines? While the water patch is extremely neat (the 3 shader files, and 4 lines modified in terrainRenderer.cpp), the other patch might be more messy (as I tried stuff, I may have modified tons of little things here and there in a few files). I'll check if it fixes the water bug on my MacBook Air when it's finished copying. BTW, I might give a shot at slightly improving the shader... The waviness factor is used in very weird ways.

Yeah, from the looks of it I might be able to do a simple parallax, but I'd really doubt that given the very basic capabilities of ARB. I might be able to port the water shader, again, perhaps fixing that one bug I mentioned. I'll look into the GLSL problem, however. There's hardly a reason for it to crash that way. Edit: also, I must do the terrain specular/diffuse mapping, and perhaps give a look at trilinear texturing.

Many maps get Out Of Memory errors on very large maps... It doesnt always crash, however. I also think that we should restrict some things based on maps and map settings. 8 players on a tiny map should not be possible/expected to be messy.

I'll try to do the water shader for ARB first, and I'll then try to push that.