It is currently Mon Feb 24, 2020 5:50 pm


All times are UTC




Post new topic Reply to topic  [ 20 posts ]  Go to page Previous  1, 2
Author Message
 Post subject: Re: Improved CubicSurfaceExtractor
PostPosted: Mon Jan 24, 2011 9:35 pm 

Joined: Sun Oct 03, 2010 10:13 pm
Posts: 73
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
Code:
float3 N = normalize(normal);
which takes a normal from the vertex shader to
Code:
   float4 worldPos = mul(world, position);
   float3 worldNormal = cross(ddy(worldPos.xyz), ddx(worldPos.xyz));
   float3 N = normalize(worldNormal);
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?


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Improved CubicSurfaceExtractor
PostPosted: Mon Jan 24, 2011 10:08 pm 
Developer
User avatar

Joined: Sun May 04, 2008 6:35 pm
Posts: 1827
AndiNo wrote:
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).


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

AndiNo wrote:
I'm currently using a shader for per-pixel lighting from the Ogre wiki which seems to work. I changed
Code:
float3 N = normalize(normal);
which takes a normal from the vertex shader to
Code:
   float4 worldPos = mul(world, position);
   float3 worldNormal = cross(ddy(worldPos.xyz), ddx(worldPos.xyz));
   float3 N = normalize(worldNormal);
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?


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.

AndiNo wrote:
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.


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.


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Improved CubicSurfaceExtractor
PostPosted: Mon Jan 24, 2011 10:53 pm 

Joined: Sun Oct 03, 2010 10:13 pm
Posts: 73
Please see my second edit above, too :)

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

RIGHT
Image
Image

WRONG
Image
Image

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 :)


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Improved CubicSurfaceExtractor
PostPosted: Mon Jan 24, 2011 11:16 pm 
Developer
User avatar

Joined: Sun May 04, 2008 6:35 pm
Posts: 1827
AndiNo wrote:
edit2: ...but would have the real vertex normal for lighting. Is this possible?


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.

AndiNo wrote:
Here are some screenshots of "RGB'ed" normalized normals:
...
Image


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.


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Improved CubicSurfaceExtractor
PostPosted: Tue Jan 25, 2011 7:01 pm 

Joined: Sun Oct 03, 2010 10:13 pm
Posts: 73
David Williams wrote:
Try multiplying your normal by -1.

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

David Williams wrote:
Are you using Direct3D or OpenGL?

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!


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Improved CubicSurfaceExtractor
PostPosted: Tue Jan 25, 2011 7:40 pm 
Developer
User avatar

Joined: Sun May 04, 2008 6:35 pm
Posts: 1827
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


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Improved CubicSurfaceExtractor
PostPosted: Tue Jan 25, 2011 9:18 pm 

Joined: Sun Oct 03, 2010 10:13 pm
Posts: 73
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:
Image
Specular:
Image
Now I only have to get multiple lights working, but I guess that can't be too hard :)


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Improved CubicSurfaceExtractor
PostPosted: Tue Jan 25, 2011 9:47 pm 
Developer
User avatar

Joined: Sun May 04, 2008 6:35 pm
Posts: 1827
Looks good!
AndiNo wrote:
Now I only have to get multiple lights working, but I guess that can't be too hard :)

You're tempting fate by saying that ;-)


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Improved CubicSurfaceExtractor
PostPosted: Tue Jan 25, 2011 10:59 pm 

Joined: Sun Oct 03, 2010 10:13 pm
Posts: 73
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
Code:
iteration once_per_light
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
Code:
scene_blend add
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
Image
Seems right
Image
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.


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Improved CubicSurfaceExtractor
PostPosted: Wed Jan 26, 2011 6:32 pm 
Developer
User avatar

Joined: Sun May 04, 2008 6:35 pm
Posts: 1827
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 ;-)
AndiNo wrote:
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)

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.
AndiNo wrote:
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.

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.
AndiNo wrote:
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.

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


Top
Offline Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 20 posts ]  Go to page Previous  1, 2

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Theme created StylerBB.net