Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

137 Neutral

1 Follower

About Sword7

  • Rank

Personal Information

  • Role
    Amateur / Hobbyist
  • Interests

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Ok, I now found your blog after I searched for that. Thanks. I will work on new LOD method to replace my old code that use trigonometry for LOD determination, etc.
  2. Where is your blog that you mention? I have a book of "3D Engine Design for Virtual Globes" book.
  3. I switched to all 64-bit transform matrix on my code (CPU side) and converted to 32-bit matrix for rendering. Also I implemented per-tile world matrix before rendering each tile. void TerrainTile::setWorldMatrix(renderParameter &prm) { int nlat = 1 << lod; int nlng = 2 << lod; double lat = PI * double(ilat) / double(nlat); double lng = PI*2 * (double(ilng) / double(nlng)) - PI; double dx = /* prm.obj.orad * */ sin(lat) * cos(lng); double dy = /* prm.obj.orad * */ cos(lat); double dz = /* prm.obj.orad * */ sin(lat) * -sin(lng); // Determine offsets from object center for tile center prm.dtWorld = prm.obj.orot; prm.dtWorld[3][0] = dx*prm.obj.orot[0][0] + dy*prm.obj.orot[0][1] + dz*prm.obj.orot[0][2] + prm.obj.cpos.x; prm.dtWorld[3][1] = dx*prm.obj.orot[1][0] + dy*prm.obj.orot[1][1] + dz*prm.obj.orot[1][2] + prm.obj.cpos.y; prm.dtWorld[3][2] = dx*prm.obj.orot[2][0] + dy*prm.obj.orot[2][1] + dz*prm.obj.orot[2][2] + prm.obj.cpos.z; } I tried dtWorld with radius size and ran it. Planet is exploding all directions! I had commented 'prm.obj.orad' out and it was back to normal. I brought camera a few centimeters above ground. Everything are very stable (no shaky) but 32-bit float errors are clearly visible. Terrain is not flat. When I move camera around, terrain jumps up and down like blocky movement. I am still figuring why terrain is not flat but looks like saw-like wave but camera movement and orientation is very smooth. I tried per-tile matrix (tile center is origin) for higher accuracy but it did not work. I am looking for another solution for tile center as origin for world matrix.
  4. Well, I just split model from view and project matrix and ran it. Good news! Dynamic shaky was gone!!! Now static errors occurs. I will now work on per-tile matrix. Yes, I have a book called "3D Engine Design for Virtual Globes". #version 420 // vertex buffer objects layout (location=0) in vec3 vPosition; layout (location=1) in vec3 vNormal; //layout (location=2) in vec3 vColor; layout (location=2) in vec2 vTexCoord; uniform mat4 gWorld; uniform mat4 gViewProj; out vec4 myColor; out vec2 texCoord; void main() { gl_Position = gViewProj * gWorld * vec4(vPosition, 1.0); myColor = vec4(0.7, 0.7, 0.7, 1.0); // vec4(vColor, 1.0); texCoord = vTexCoord; } prm.model = glm::translate(glm::transpose(prm.obj.orot), prm.obj.cpos); prm.mvp = prm.mproj * prm.mview; uint32_t mwLoc = glGetUniformLocation(pgm->getID(), "gWorld"); glUniformMatrix4fv(mwLoc, 1, GL_FALSE, glm::value_ptr(prm.model)); uint32_t mvpLoc = glGetUniformLocation(pgm->getID(), "gViewProj"); glUniformMatrix4fv(mvpLoc, 1, GL_FALSE, glm::value_ptr(prm.mvp));
  5. OK, I figured out why... Yes, I assigned tiles at 6371 km from origin. I tried normalized coordinate from planet origin and did not resolve that problem. I tested both on IEEE 754 float convertor link above and both failed due to float errors. That is a float-related problem. I think that a problem is applying world space to planet origin due to float errors. In Scene::render prm.mproj = glm::perspective(glm::radians(OFS_DEFAULT_FOV), float(gl.getWidth()) / float(gl.getHeight()), DIST_NEAR, DIST_FAR); prm.mview = glm::transpose(glm::toMat4(prm.crot)); In TerrainManager::render prm.model = glm::translate(glm::transpose(prm.obj.orot), prm.obj.cpos); prm.mvp = prm.mproj * prm.mview * prm.model; I now found that problem above because it is using local world space relative to planet center (origin). For possible solution, I have to split model (world space) from view and projection matrix and have to apply world space to each tile center (origin) to render. I will try that and see what happens... (planet position + tile position) - camera position.
  6. Ok, I will work on it about clipping test tomorrow. My camera moved and panned very smooth by using my keyboard as movement controls. Here are my video clips to watch. Update: I decided to test clipping. I set 1.0 to far and see nothing as result. Good. I commented a line out in fragment shader code and saw nothing as result. Should I set any simple color to see it as test? https://youtu.be/-GHSpStO5Pc https://youtu.be/pAnQTJtRrC8
  7. Ok, I updated my code by switching to all 64-bit vertices, etc... Converted to 32-bit floats for rendering/vertices buffer with 32-bit model/view/projection matrix. Distorted is now gone but vertices are still shaky. LOD determination is now stable. Rendering is now faster and smoother than before. I believe some issues inside GPU space due to float errors through shader processing (limitation of 32-bit floats). A few hundred meters above ground, they look stable but landing on ground (a few meters above) is becoming shaky or "earthquake effect".
  8. I had not implemented elevation yet but just flat texture at this time. I calculates 32-bit vertices from origin (0, 0, 0) in normalized or planet-sized coordinate system for spherical vertices with 16-bit indices and 32-bit texture coordinates. It uses GL_TRIANGLES with CCW winding orders. Both coordinates resulted same (locally shaky/distorted). I am using glEnable(GL_DEPTH_TEST) and glDepthFunc(GL_LEQUAL). I am using GL_LINEAR for texture mapping. glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR); Here are my shader programs to rendering planet textures. Here is vertex program. #version 420 // vertex buffer objects layout (location=0) in vec3 vPosition; layout (location=1) in vec3 vNormal; //layout (location=2) in vec3 vColor; layout (location=2) in vec2 vTexCoord; uniform mat4 mvp; out vec4 myColor; out vec2 texCoord; void main() { gl_Position = mvp * vec4(vPosition, 1.0); myColor = vec4(0.7, 0.7, 0.7, 1.0); // vec4(vColor, 1.0); texCoord = vTexCoord; } Here is fragment program. #version 420 // #extension GL_ARB_shading_language_420pack: enable Use for GLSL versions before 420. layout (binding=0) uniform sampler2D sTexture; in vec2 texCoord; in vec4 myColor; out vec4 fragColor; void main() { fragColor = texture(sTexture, texCoord); // fragColor = myColor; }
  9. Ok, When far away, textures are stable (no shaky or distorted). I believe possible float inaccuracies due to large offset between viewpoint and vertices since planet's radius is 6400km and using one unit per one kilometer. One meter is each .0001 unit. At horizon, distant textures are more stable than local textures. I tried to reduce planet size to normalized coordinate system (one unit is one planet radius) and moved it to (0,0,-5.0) but it still got shaky and distorted - no difference. I tried different near and far planes but it did not resolve that problem. When I tried smaller far plane, it got worse shaky/distorted. Original was near .001 and far 1.0e9 (need that see stars in 3D coordinates system). I tried near .0000001 and far 10.0, it got worse shaky and distorted. I set camera position is always (0, 0, 0) as origin to relative world coordinate system by subtracting view position from planet position (relative world coordinate system). I still need solution by remove an offset from viewpoint and vertices to eliminate shaky/distorted.
  10. No, when landing from air or space, ground is more shaking and distorted. I think values are too small to rendering. One meter is .0001 each. When further from terrain textures, they are more stable.
  11. I am working on planet terrain rendering with OpenGL 4.x shader programming. When I move closer to ground, ground is becoming more earthquake. Does anyone know any solution with 'earthquake effect' elimination when closer to ground for landing, etc? I use unit per cubic kilometer for terrain mapping.
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!