Are you using modulative shadows? Those use a shadow quad overlay combined with a stencil buffer to generate shadows. That's why the fog state does not affect it currently. I'll put it on the list of things to look at though. The shadows around the water, I'm not too sure about. Perhaps it is something with how you do the water? Have you tried removing the water to see if the shadows are still there on the terrain from that viewpoint?
Thanks for the help renase! 
Actually I'm using Additive shadows. Here's pretty much all of the shadow code (the game extends SimplePassGame):
private static ShadowedRenderPass sPass = new ShadowedRenderPass();
Sphere s = new Sphere("My sphere", 30, 30, 100);
rootNode.attachChild(s);
ShadeState ss = display.getRenderer().createShadeState();
ss.setShade(ShadeState.SM_SMOOTH);
ss.setEnabled(true);
rootNode.setRenderState(ss);
sPass.add(rootNode);
sPass.addOccluder(s);
sPass.setRenderShadows(true);
sPass.setLightingMethod(ShadowedRenderPass.ADDITIVE);
pManager.add(sPass);
As for the shadows around the water it really only happens around water-land intersections so if i remove either the shadow disappears. My terrain is simply made with a class named TerrainGenerator which extends TerrainPage (the world is made up of tiles that load around the player depending on the direction of movement to simulate a planet). This contains the following code to build the terrain pages:
FaultFractalHeightMap heightMap = new FaultFractalHeightMap(65, 30, 0, 255, 0.75f);
heightMap.setHeightScale(0.003f);
Vector3f terrainScale = new Vector3f(100, 10, 100);
ter = new TerrainPage("Terrain", 33, heightMap.getSize(),
terrainScale, heightMap.getHeightMap(), false);
ter.setIsCollidable(true);
ter.setDetailTexture(1, 160);
ter.setLocalTranslation(position.add(new Vector3f(0, -500, 0)));
ter.updateFromHeightMap();
terrain.attachChild(page);
The water is terrain as well (using the following code) and is built along with each terrain tile. Should I use something other than terrain for water? I'm not sure what's easiest but considering height of verts in a terrain is easily manipulated I thought terrain was the way to go. I'll add random (small) waves that way but it might be horribly inefficient to calculate waves for 9 terrainpages of which most might not even be seen. Eventually I'd think about using sinus functions to radiate waves toward terrain 'collisions' that form the coast to simulate slightly more realistic coastal water.... So, should I be using something other than terrain for water to fix the shadow problem (and to realize those kinds of plans)?
FluidSimHeightMap wHeightMap = new FluidSimHeightMap(65, 300,0,1,20f,1f,1f,2f,1);
wHeightMap.setHeightScale(0.0001f);
Vector3f wTerrainScale = new Vector3f(100, 1, 100);
terWater = new TerrainPage("Terrain", 33, wHeightMap.getSize(),
wTerrainScale, wHeightMap.getHeightMap(), false);
terWater.setDetailTexture(1, 4);
terWater.setLocalTranslation(position.add(new Vector3f(0, -500, 0)));
water.attachChild(terWater);
Update:
In trying to figure out the problem I turned on shadow volume rendering and made a few screenshots zooming out:
(don't mind the erratic terrain as each tiles height map is still generated randomly)
As you can see the shadow of the sphere doesn't line up with the base of the volume. Although at a very close distance this isn't visible, the farther the camera is the more shadows are displaced (most visible at waters' edges but also under the sphere). :? The terrain isn't a clod (set to false in the code above) which I thought might account for terrain vectors not actually being where they should be. I'm kind of stumped on this.... (then again I'm a noob trying to learn as fast as I can! ://)
(Also, shadows disappear when the camera is inside the volume. Isn't that a relatively easy fix?)
camera in shadows is zfail. I just haven't got around to that yet. The naive version is to init your near plan with 1 when you detect you are in shadows, but then you still have problems with intersections and the like. I want to make a clean implementation and will get to it eventually I promise.
As for the offset, to me it still looks like a stencil buffer fidelity issue - the stencil buffer depth is too low. Have you tried bumping that up?
How would I go about doing that? The only buffer depth related setting I could find was DisplaySystem.setMinDepthBits(int) which is apparantly 8 by default. I'm not quite sure how to access and set it though. I tried the following with no improvement:
display.setMinDepthBits(128);
or should I be doing something with a ZRenderState? I don't see any possibility to change the depth buffer with that though, only the function.
ZBufferState zbs = display.getRenderer().createZBufferState();
zbs.setEnabled(true);
rootNode.setRenderState(zbs);
I've also played with the shadow settings a bit with the ShadowTweaker and found a setting that seems to work with my shadows (although the scene becomes overly bright... I'd have to play with lighting levels to see if this is an advantage or disadvantage). I poked around in the ShadowTweaker code to quickly find how to set them and noticed that it just sets an alphastate in ShadowRenderPass in general. If I use the same code in my main class (where I set up the shadow pass) nothing changes because blended and blendTex are null.
sPass.add(rootNode);
sPass.addOccluder(s);
sPass.setRenderShadows(true);
sPass.setLightingMethod(ShadowedRenderPass.ADDITIVE);
//Light Pass (S/D) 2/1
//Texture Pass (S/D) 4/2
ShadowedRenderPass.rTexture = true;
if (ShadowedRenderPass.blended != null){
ShadowedRenderPass.blended.setSrcFunction(2);
ShadowedRenderPass.blended.setDstFunction(1);
}
if (ShadowedRenderPass.blendTex != null){
ShadowedRenderPass.blendTex.setSrcFunction(4);
ShadowedRenderPass.blendTex.setDstFunction(2);
}
pManager.add(sPass);
Anyway, thanks for taking the time to help me out! :)
The alpha states are inited later in the process which is why they are null there. As for the bits, you are close… you want the stencil bits. The needs to be done before the renderer is created though. If you are using SimpleGame you can set the stencilBits (something like that… not in front of me) in your application class constructor and it will be used at the appropriate time. Try a value of 8 or 16. Max values differ by card, but 32 is probably absolute max setting for most of the buffer types.
Ok, so for the alpha states I shouldn't change them within simpleInitGame()? I'll have to fiddle with that and see what happens. Anywhere I place changes to them within that method doesn't affect the scene.
I can't quite figure out where to change the stencilBits either… ://
If i set stencilBits, even as the very first line here, display.getMinStencilBits() returns 0. On the other hand, setting display.setMinStencilBits( 8 ) does cause it to return 8 but with no change in the scene.
protected void simpleInitGame() {
//display.setMinStencilBits(8);
stencilBits = 8;
As a test I changed the value of stencilBits in BaseSimpleGame to 8, which returns 8 with no change in the scene as well. Changing it to 16 resulted in an error:
Jul 13, 2006 4:07:59 PM com.jme.system.lwjgl.LWJGLDisplaySystem initDisplay
SEVERE: Cannot create window
java.lang.Error: Cannot create window: Could not find a valid pixel format
(on a laptop with an ATi radeon 9700 Pro)
(On a more positive note working with terrain is getting somewhere... by tomorrow the terrain should form a large cylinder that simulates a planet loaded from image height maps. This is disguised in-game by causing heavy damage to players in polar waters :P So at least some things are working out. jME is truely a great project and can definately count on donations from my own!)
hmm, well you are setting it right, so my hunch is probably wrong. :/ sorry. I'll have a think about it.