wraitii

@HistoricBruno: technically, AO could require a lot of "rays" to be precise. It can probably be approximated fairly well, for example with SSAO. I'm fairly sure we can't get a result as good as Blender's, but for most model, and approximation should be enough. However, I agree that it would be the most straightforward way.

The problem with that system is that it requires the water plane to have more vertices than it currently has (I'd say at least 4 times more), and it would then require to calculate each frame the water physics. While it's certainly possible, it's way slower than what we have know if we want a proper result. It's far from impossible, but it would really only benefit for simulating stormy seas.

Well, right now, the ARB and GLSL shaders give the same results and take the same inputs. When myconid implements his post-processing effect, I'll be able to improve the quality of the water with proper knowledge of depth, but in the meanwhile, this will do. I'll try to implement a basic foam, it should not prove too hard. Proper wave breaching is out of the question in the current version of the shader.

Was parallax activated on the unit? @Don't overstress yourself: the less I can work on shaders, the more I'll work on my bot

Very good then... I'll just wait (and no, I indeed didn't need real raycasting, just some info about the heightmap, or the depthbuffer, though I hadn't thought of that). Would this (particularly points 4/5) require rendering the water twice?

I could use it for improving murkiness (calculating actual distance of light underwater), some sort of advanced refraction, and probably would be nice to have overall. It could also fix a rare, but possible bug with water being incorrectly transparent (if you look at the far side of a steep enough island).

Myconid, do you believe it would be possible to (at runtime) export an heightmap of the map? I think I could use it in the water shader to start doing some fancy stuff (simulating ray-casting for depth) Edit: scrap it, it may already be in the game…

It looks like a precision issue in the dot product... I'm not completely sold on how it can be averted.

Could be normals not working, but the parallax works... I'll look int it, but it works for me.

Doesn't happen with me... If you do change the lighting, does anything happen? If you rotate/elevate the sun, does something happen?

It does this only with the temple? Tried deactivating stuffs in the material? (I'm thinking AO/self-light).

No, if anything, in the current state, it's probably more obvious. I'll look into what causes this tiling anyway, because it should not happen.

I figure that would be the easiest way to use the SSAO... It could also be used on buildings (modifying their xml to add the baked texture). This would help with modding support, too, as they would not be required to bake the AO themselves.

Yeah, I've given a look at that... I'm thinking it would be possible to push it slightly further... Of course, we don't need a completely modular system.

To do that (and a few other things), we'd need to have some sort of basic raytracing. We have to know the distance between the light entering the water and hitting the ground. It can perhaps be approximated, but it's already much harder to compute.

Well using techniques and the "ShaderManager", I don't think it would be too hard to switch between two techniques. The hard part is defining the switch criterion. We could probably do it by adding a line along the lines of "<ifCriterion criterion = "distance" value="50" type="GreaterThan">" or something to the XML. Ideally, we'd have a "base" shader, and if some criteria are met, we switch to another (more detailed) shader. This way, we could link 1/2/3/4… different shaders for different LOD, and also prevent this switching by options, so that lower configs would only use the base shader or the level 1.

The idea would be to load two shaders and switch depending on the situation?

Okay, so now it ought to be allright.

The thing is... I can, but the instruction would still be processed (only not doing anything). So from a speed point of view, I might just as well do it.

Let's use this new forum. Following my conversion of myconid's efforts to ARB, I have ported the water shader (and now, the water with shadows effect). In turn, I figured: why not give a shot at improving this? And hence I tried. First, a link to this album, which shows (in the first version) the many differences between the old and the new shader. I think we'll all agree that the new shader allows the "waviness" factor to mean much more. I've just added three pictures, and in particular, those two, which show the wave size scaling with waviness: I'd like to know if the direction I'm taking is allright with the rest of the team/most people, and if anybody has idea for improvements. Additionally, thanks to myconid's efforts, we have shadows on the water, and I have taken the liberty of having murkiness effect the transparency of shadows (I'm not sure how water works, but it made sense at the time).

Zoot, does it work now? (reposting the link) I'd recommend a clean-workspaces / update-workspaces.

I'm not dropping the non-nvidia users. It's just that nVidia users could benefit from a faster, more efficient shader at no cost. The GLSL parallax module uses "if" to determine if the distance is small enough to draw the parallax(for optimization). I can't do that with the ARB shader as is... Alternatively, I might be able to have the engine calculate this, and then send it as a define. But that'd be more of a hack, and I'm not sure how usable it is. I dunno. Any opinions?

@HIstoricBruno: not yet, but I'll upgrade my iMac on 10.6.8 to 10.8 quite fast is no major problem is revealed.

I'm not completely sure what causes this, but when setting "preferglsl = false", the choice of shaders for the GUI is the fixed function, not the GLSL shaders. I'm not completely sure, but myconid may have modified the fixed function, so the problem could come from that. I'll have to check. The decals problem looks like it stems from the unfinished terrain shader. I'll try porting this over when Myconid has decided on the ≈ final version. BTW, I'm still facing a problem with the ARB shaders... Since I can't have "IF", then the parallax is always active: this could slow computers down considerably. I'd want to try to implement something in the source code that would tell me if the nVIDIA extension is supported, and then if so, use the modified shader and not the basic one. I've actually already tried and succeeded at that, but it's a semi-important design change so I though I'd share. Particularly since in the perspective of ahving advanced graphic options to deactivate parallax specifically, you could have a tooltip for the case where the extension is not activated. Also, changing HWDetect to switch it off if the extension is not there and we want ARB shaders. BTW, I assume the game prefers ARB shaders because of their wider compatibility?

Allright, well I'll see that tomorrow, in the meantime you should be able to compile if you copy SVN's premake over it.