I'd like to believe you but currently it seems it doesn't work the way I'd expect. I did a few Google searches and so far everybody (including this) says that one can not calculate the normal of a surface without access to the neighbouring vertices (neither in the vertex nor in the pixel shader).
I'm currently using a shader for per-pixel lighting from the Ogre wiki which seems to work. I changed
which takes a normal from the vertex shader to
to calculate the normal. I tested this on a normal mesh (tudorhouse.mesh) coming with Ogre. I guess the shader should work on any mesh, right? I tried different combinations of the vertex position with world_matrix, worldView_matrix and worldViewProj_matrix, nothing gives results that look similar to the fixed-function pipeline. Am I doing something wrong?

edit: If nothing helps I think I could still fall back to the surface extractor with normals, although I think other than the normals this only has negative effects.

edit2: Would it be possible to let the surface extractor calculate the vertices and their normals, but still have vertex sharing so each cube consists of only 8 vertices? Then I could still re-calculate the normals in the shader for the texture atlas, but would have the real vertex normal for lighting. Is this possible?

Well, that guy seems pretty sure But there are some counter examples which you can have a look at:

http://c0de517e.blogspot.com/2008/10/no ... rmals.html
http://forum.beyond3d.com/showthread.php?t=37614



In principle the technique can be applied to any mesh, though usually it doesn't save much space. I don't know if you can just drop in the code snippet though, there might be more changes required than that.



It does depend where your bottleneck is, though I believe that for PolyVox it will be better to calculate the normal in the pixel shader. I haven't done any significant testing though. You should try switching to the version with normals to see if it fixes your problem, and you should also try outputting the normals as RGB values to see where any differences are occuring. Post screenshots if you like and I'll take a look.

Please see my second edit above, too

Here are some screenshots of "RGB'ed" normalized normals:

RIGHT



WRONG



As you can see the "normal trick" outputs vastly different normals than the "baked in" ones. I hope you can put this to some use

You probably don't actually want this. The reason that most meshes (particularly charachters) interpolate the vertex normal for lighting is because they want the resulting image to look smooth. But in your case you want the individual faces to stand out (the correct term is 'faceted'). For a minecraft style level you specifically want to avoid interpolating the normals because you don't want the smooth look. Of course, if you were using the Marching Cubes surface extractor for smooth terrain it would be the other way around. Here's a random image which illustrates the difference:

http://i280.photobucket.com/albums/kk16 ... tSolid.jpg

On the left the normals are defined per-vertex and interpolated across the face, and on the right they are defined per-face.



This one is correct. Well, almost. The building is wrong but that is because applying this technique to the building is probably more complex than just dropping in that snippet of code (it is dependant on the way the vertex shader is set up as well).

But notice the colours of the cubes - each cube has one pure red face and one pure blue face. There should be a pure green face too but that is probably on the botton. Given this, you might find that all your normals are pointing in exactly the wrong direction. Try multiplying your normal by -1. You can also try taking the absolute value of the normal by using 'normal = abs(normal)'.

Are you using Direct3D or OpenGL? I noticed in themite that the normals actually point the opposite way in OpenGL, whereas my code snippet worked correctly for Direct3D.

Thou hast done well in teaching thine scholar.
Did I already tell you that you will probably hold the second place in my credits?


I'm using a CG shader but am nearly always running the game in OpenGL (to make sure the main component for platform independence is still intact).
Now I just have to mix the lighting with the previous texturing and I should be ready to go!

Glad you got it working... the main reason why it was obvious to me was that I had the same problem in Thermite (using Cg with both Direct3D and OpenGL). On the Ogre forums I found a way to get different behaviour between render systems - it's a bit messy but does work (I used SpaceDude's solution inthe third post down): http://www.ogre3d.org/forums/viewtopic.php?f=1&t=40084

That will come in handy!
I hope I'm not derailing the thread too much, here's my last entry for a while
See my directional light:
Diffuse:

Specular:

Now I only have to get multiple lights working, but I guess that can't be too hard

Looks good!

You're tempting fate by saying that

Yeah, I guess now I "eat my words". Of course it is NOT as easy as I thought. And I'm hijacking this thread again. If you think it's necessary you might as well create a new thread from this
For one, I just had to set in the material's pass declaration. But then there's only green light if I create a green point light after the directional light, as the colour of pass 2 overwrites the previous I guess. So I'm setting in the pass, too, like it's said in the PerPixel tutorial in the Ogre wiki. Then I have a transparent ghost world which is cool, but not what I want But maybe I'll figure that out, as the tutorial describes something like this.

Anyhow, if a mesh gets in point light range it's completely lit green. Do I have to do the distance calculation myself, too? (attenuation etc)

edit:
The transparency problem seems to vanish if I put another pass before the actual fragment shader pass. I don't know why, but it seems this first pass is used for ambient calculation.

edit2:
This is what I get now:
Sometimes it looks right, then sometimes the colours add so that it looks like there's fog all over the place, then again I seem to get some shadow acne-like distortions (although I didn't implement shadows).

Foggy

Seems right

This can change at any second while I'm moving through the world.

edit3:
I'm not sure how safe this statement is, but it seems to change whenever all non-Polyvox-ManualObject-meshes get out of view. As you can see in one of the previous pictures there's the house with my shader applied and some other, normal meshes.

I think your now getting into the realm of Ogre rather than PolyVox and I don't have so much experience here, but I can answer some of your questions. I'm sure more will be revealed as you read on in the turorial though

Yes, you will have to implement the attenuation in shaders. However, I think that Ogre might hide the point light once it goes out of range, so if you don't handle attenuation it might appear to suddenly vanish rather than fading off.

Additive blending basically means it's partially transparent, because you are adding on to the background. Typically you will want to draw your first pass solid (replace rather than blend) and then additively blend the other passes to accumulate the other lights.

Not sure about this... but you may need to set up the bounding box of the manual object?