   Spherical Environment Mapping not "View angle Dependent for fulldomes. How?
  Hello, this is my first post here, but I've been reading the topics here for awhile.I'm implementing a Fulldome view to a realtime-engine (Blender Game Engine) [1]. It renders the scene a few times (4-6) and draw it warping properly. For each render the camera orientation changes.The problem:The openGL and GLSL implementations of Spherical Environment Mapping and Cube Environment Mapping are "view angle dependent". Therefore if I keep a camera position and only rotate it I will see a different mapping. That will produce seams to the dome view.I got it working for Cube Mapping in GLSL already [2]. But I still need to find a way to do that in openGL. And do SEM in openGL and GLSL.Is that even possible?(I'm strongly tempted to think that no reflection effect should be "View angle dependent" in real world).Sincerely,Dalai[1] http://wiki.blender.org/index.php/Dev:Source/GameEngine/2.49/Fisheye_Dome_Camera[2] http://www.pasteall.org/5547[Edited by - dfelinto on May 12, 2009 6:27:12 PM]
  Why are you saying "Cube Environment Mapping are view angle dependent"?  What is the "seams" of cubemap in your implementation look likes (an image would be excellent)?Fix pipeline functions of OpenGL was dropped in the latest version of OpenGL.  Using shaders alone would be good enough already.  The old way of doing cubemap mapping is messy (I don't recommend it at all).  Anyway, you can download a demo program (with source code) from NVidia website.http://developer.nvidia.com/object/cube_map_ogl_tutorial.html   ;  Thanks for replying. English is not my first language, so let me try to make myself more clear:Quote: Why are you saying "Cube Environment Mapping are view angle dependent"? The current code of Blender Game Engine handles CEM and SEM dependent of the camera angle.What happens then (with the current problematic situation) is that the same point on an object's surface with a texture mapped to the normal will have a different texture mapped to it if the camera rotates on itself even if the surface normal stayed completely the same.It looks similar as if we had specular calculation [1] :glLightModelf(GL_LIGHT_MODEL_LOCAL_VIEWER, 0.0f);instead of:glLightModelf(GL_LIGHT_MODEL_LOCAL_VIEWER, 1.0f);Quote:What is the "seams" of cubemap in your implementation look likes (an image would be excellent)?Images: http://img8.imageshack.us/gal.php?g=reflecbug.jpgAlthough it's not so clear in the first image, it's very clear in the second one. Please notice the seam in the middle of the monkey character.Quote:Fix pipeline functions of OpenGL was dropped in the latest version of OpenGLFrankly, I still need to have that implemented as fix pipeline functions for old computers. However in all the tutorials I found the above-mentioned problem (view angle dependency) for openGL code (no glsl).In fact even in Spherical Environment Mapping glsl code I found this problem. Such as in this SEM implementation: [2]Quote:http://developer.nvidia.com/object/cube_map_ogl_tutorial.htmlI will check again this NVIDIA example later. But from what I remember of it, this is "view angle dependent".Is it more clear now?Thanks again[1] - http://gregs-blog.com/2007/12/21/theres-nothing-wrong-with-opengls-specular-lighting/[2] - http://www.ozone3d.net/tutorials/glsl_texturing_p04.php   ;  I'm not quit sure what you are talking about.However, the seams appears in the second image is probably because you are preparing your cubemap texture incorrectly in the first place.Please describe more precisely what you are trying to do.  Maybe I can write a demo program for you.   ;  In fact for the fulldome I'm not using cubemap images. I'm manually creating 4 images:"It uses the multipass texture algorithm as described here [1]. Briefly, that involves rendering the scene 4 times and placing the subsequent images onto a mesh designed especially such that the result, when viewed with an orthographic camera, is a fisheye projection. " [2]The CEM and SEM are being used in the materials of the scene (e.g. in the squirrel).Quote:Please describe more precisely what you are trying to do.I'm trying to write an openGL and GLSL shader for SEM and CEM where the mapping doesn't change when I rotate the camera on itself.For example if I do:glTexGeni(GL_S, GL_TEXTURE_GEN_MODE, GL_SPHERE_MAP);glTexGeni(GL_T, GL_TEXTURE_GEN_MODE, GL_SPHERE_MAP);glEnable(GL_TEXTURE_GEN_S);glEnable(GL_TEXTURE_GEN_T);OR[Vertex_Shader]void main(){gl_Position = ftransform();gl_TexCoord[0] = gl_MultiTexCoord0;vec3 u = normalize( vec3(gl_ModelViewMatrix * gl_Vertex) );vec3 n = normalize( gl_NormalMatrix * gl_Normal );vec3 r = reflect( u, n );float m = 2.0 * sqrt( r.x*r.x + r.y*r.y + (r.z+1.0)*(r.z+1.0) );gl_TexCoord[1].s = r.x/m + 0.5;gl_TexCoord[1].t = r.y/m + 0.5;}[Pixel_Shader]uniform sampler2D colorMap;uniform sampler2D envMap;void main (void){vec4 color = texture2D( colorMap, gl_TexCoord[0].st);vec4 env = texture2D( envMap, gl_TexCoord[1].st);gl_FragColor = color + env*0.4;}(codes from ozone3d [3])The mapping changes whenever I rotate the camera (therefore producing the problems in Fulldome).Therefore what I need is a SEM code where the mapping changes only relatively to the camera position, not it's orientation.The same stands for a CEM (although I have it working in glsl already [4]).[1] - http://local.wasp.uwa.edu.au/~pbourke/papers/graphite2005/[2] - http://local.wasp.uwa.edu.au/~pbourke/miscellaneous/domemirror/BlenderiDome/[3] - http://www.ozone3d.net/tutorials/glsl_texturing_p04.php[4] - http://www.pasteall.org/5547   ;  Sphere map is problematic.  It is heavily distorted along the boundaries of the hemi-spheres.  Unless you are using a 3D model tessellated with an exceptionally high quality (i.e. almost saying each pixel onscreen is corresponding to a distinct vertex), it will never free of artifacts.In case you had to use Sphere map, there is a simple improvement you can apply to your code.  Move the sphere map coordinates convention routine to pixel shader.  Therefore, the following three lines go to pixel shaderfloat m = 2.0 * sqrt( r.x*r.x + r.y*r.y + (r.z+1.0)*(r.z+1.0) );gl_TexCoord[1].s = r.x/m + 0.5;gl_TexCoord[1].t = r.y/m + 0.5;And, in the vertex shader, you should pass r to pixel shader.  By the way, r MUST NOT be normalized before it reaches pixel shader (i.e. rasterization & interpolation).  The following line in the vertex shadervec3 u = normalize( vec3(gl_ModelViewMatrix * gl_Vertex) );should be changed tovec3 u = vec3(gl_ModelViewMatrix * gl_Vertex); [Edited by - ma_hty on May 13, 2009 12:44:24 PM];  Be frank, sphere map is really outdated.  I bet there are no one interested about it.  Why bother to implement it?  Educational purpose?If you insist that only two textures can be used, you should try Dual-Paraboloid map.  While the computational cost is similar, the distortion along the boundaries can be reduced considerably.Anyway, cubemap is far better than sphere map and Dual-Paraboloid map.  Not only because it has the best quality at the same computational cost, but also because it is hardwired in all display card nowadays.  Unless you are trying to make your engine compatible with the computers 8 years old or older, you should use cubemap.I have a working demo of dynamic environment mapping using cubemap.  If I can find it tomorrow, I send it to you.   ;  By the way (again? ^^), what have you done to the gl_Position?It is very an important factor for the correct interpolation of the others attributes during rasterization.   