Jump to content
  • Advertisement

raRaRa

Member
  • Content Count

    6
  • Joined

  • Last visited

Community Reputation

202 Neutral

About raRaRa

  • Rank
    Newbie
  1. raRaRa

    Terrain patch border issue

    Thanks for all the replies. I ended up having one pixel padding on my heightmap and it solves the problem. However, on my procedural planet this becomes an issue between cube faces.   Let's take one cube face as an example. The cube face coordinates are X = [-1.0, 1.0] Y = [-1.0, 1.0] and Z = 1.0 and with padding it would be something like -1.1 to 1.1 and then it doesn't match the coordinates on the neighbour cube face.   I could do some if statements in the shader, e.g. if X is under -1.0 then it must belong to a different face. I would love to avoid that.   Something tells me I don't need padding for the heightmap and I'm going to investigate it further. Any helpful tips are more than welcome.
  2. Now I'm just thinking out loud about one possible solution. I have one idea in mind that I would like to share and I would love to get feedback.   So, at depth ~12 I would start re-using the normal map from depth 12 for all the children. Then for the children I would interpolate the low res normal map to keep the main features that were seen from space (big mountains and valleys, etc). And another thing I would do is generate local noise for the children, which is seeded by local factors, such as height, slope, etc which is not dependent on the same planet coordinate system, but rather some local coordinate system to avoid the GPU precision problem.   Has anyone done anything similar before? Isn't this how Outerra does it? They have some pre-defined normal map and to make it interesting at low level, they generate local noise.   Thanks!
  3. Hey,   I'm going to share some technical background first before I describe my normal map problem.   The planet is generated using cube to sphere mapping. I have QuadTree for each cube face to handle LOD and I have 18x18 quad mesh in each patch/node. Everything on the CPU side is in double float precision.   For each patch, I pass the patch corners (cube space coordinates) to the position map shader. The shader generates a position map by transforming each texel to cube space and then to object sphere space before it enters as an input to the noise function. Once I get the height value for a texel, I then store the texel's (object sphere space) * height in the RGB channels. So basically each texel in the position map has its sphere object space XYZ coordinates.   Here's the position map shader: // Patch coordinates in cube space vec3 xNW = v0; vec3 xNE = v1; vec3 xSW = v2; // Get the direction, from the origin (top-left) to the end vector (bottom-right). vec3 xDirection = xNE - xNW; vec3 zDirection = xSW - xNW; // Scale the distance by the texture coordinate (which is between 0 and 1). xDirection *= vTextureCoord.x; zDirection *= vTextureCoord.y; // Get current position on the cube face patch vec3 pos = xNW + xDirection + zDirection; // Map the cube coordinate to sphere pos = getSpherePos(pos); float height = fBm3(pos, 0.05, 3.0, 0.7, 1.0, 1.0); gl_FragColor = vec4(pos * height, 1.0); Then in the main shader I generate normals by sampling the position map. Here's the shader: vec3 getNormal() { vec2 tpos = vPositionMapUV; float one = 1.0 / 128.0; vec3 currentPos = getPosMap(vec2(tpos.x, tpos.y)); vec3 e0 = getPosMap(vec2(tpos.x - one, tpos.y)) - currentPos; vec3 e2 = getPosMap(vec2(tpos.x , tpos.y - one)) - currentPos; vec3 n0 = cross(e0, e2); return normalize(n0); } When I reach around depth 15 I start to see artifacts on the normal map, lots of noise and stripes. Here's a picture:     I think the problem is because I'm out of double float precision in the GPU, the vertices are probably like 0.00000005 units apart from each other. I have no clue on how to overcome the issue.    Any help is greatly appreciated.   Thanks!
  4. Hello, I'm working on a procedural terrain engine.   I'm generating a height map for each terrain patch (QuadTree node) and the vertices are lifted up in the vertex program, but the patches have small cracks on the borders. This is happening because the neighbour terrain patch has its own height map and mesh, so the vertices on the borders don't match up perfectly. Please note that I have the same LOD level on all patches at the moment.   One potential fix I can come up with is adding 1 pixel padding on the height map, where the one pixel border is fetched from the neighbour height map. That way the vertices on the edges will be lifted properly. But I've never come across any article talking about this issue, so I'm wondering if I'm doing something fundamentally wrong.   This was never a problem on the CPU side, because the vertices on the border got the same noise value for the given X Y Z input. However, now on the GPU side I'm feeding it with the corners of the terrain patch and then the GPU is interpolating between those corner values, which is the input to the noise function.   Any clues or suggestions on how I can do this properly?   Thanks!
  5. Thanks for the feedback AdeptStrain. It turned out to be a simple mistake on my part when I was converting the HLSL shader to GLSL. The original shader was using inTexCoords which I changed to gl_FragCoord. After switching to the texture coordinates everything started working normally.   Now I just need to figure out how to make each face match each other. :-)   Thanks!
  6. Hello! This is my first post here so be nice! ;)   Like everybody else, I'm working on a procedural planet engine, except it's going to run on your browser using WebGL! The project is going fairly well and I've already morphed a unit cube to sphere using Philip Nowell's method at http://mathproofs.blogspot.com/2005/07/mapping-cube-to-sphere.html   I've also implemented Quadtree for LOD management, frustum view culling and horizon culling. You can try my latest demo at http://jontrausti.com/frustum1/   So far so good! My next step (surprise!) is generating heightmap for each side of the unit cube. I've implemented Simplex 3d noise shader that will render once per terrain patch (quadtree node) to a texture. I pass in the four cube space corners of the terrain patch to the noise shader. My problem is not knowing how to lerp/interpolate between those corner positions.   I've been Googling all day and I came across one blog that was facing the same problem. On his blog he's passing the four cube space corners of a terrain patch to the shader. Here's his shader: (taken from http://britonia.wordpress.com/2009/12/23/noise-part-iii-gpu/) float4 PS_INoise(float2 inTexCoords : TEXCOORD0) : COLOR0 { float land0 = (float)0; // Get the direction, from the origin (top-left) to the end vector (bottom-right). float3 xDirection = xNE - xNW; float3 zDirection = xSW - xNW; // Scale the distance by the texture coordinate (which is between 0 and 1) xDirection *= inTexCoords.x zDirection *= 1 - inTexCoords.y; // Lerp outward from the originSY (top-left) in the direction of the end vector (bottom-right) float3 lerpedWorldPos = xNW + xDirection + zDirection; land0 = doTerrainNoise(lerpedWorldPos); return land0; } Here's my shader converted to GLSL: vec3 xNW = v0; vec3 xNE = v1; vec3 xSW = v2; // Get the direction, from the origin (top-left) to the end vector (bottom-right). vec3 xDirection = xNE - xNW; vec3 zDirection = xSW - xNW; // Scale the distance by the texture coordinate (which is between 0 and 1). xDirection *= gl_FragCoord.x; zDirection *= 1.0 - gl_FragCoord.y; vec3 pos = xNW + xDirection + zDirection; I'm mapping xNW to v0 which is the top left vertex, xNE to the top right vertex (v1) and xSW to the bottom left vertex (v2).   This works fine for the first node that represents a whole side on the cube, but once it splits to four children the top left children gets a correct heightmap but the other 3 (top right, bottom right and bottom left) get the same heightmap as the top left node.   Here's a picture showing the problem more clearly. The first picture shows when the face has one node.     Second picture shows when it has split to four nodes:     And here are the four coordinates I pass to the shader:   The first node before its split to four children: [-1, 1, 1] v0 [ 1, 1, 1] v1 [-1, -1, 1] v2 [ 1, -1, 1] v3 The four children:   Top left: [-1, 1, 1] v0 [ 0, 1, 1] v1 [-1, 0, 1] v2 [ 0, 0, 1] v3 Top right: [0, 1, 1] v0 [1, 1, 1] v1 [0, 0, 1] v2 [1, 0, 1] v3 Bottom left: [-1, 0, 1] v0 [ 0, 0, 1] v1 [-1, -1, 1] v2 [ 0, -1, 1] v3 And so forth...   It would be greatly appreciated if someone could help me in the right direction. In the mean time I'm going to attempt to find out why I keep getting the top left node correct. This has to be some simple problem that I just can't see.   Thanks!   Kindest regards, Jon Arason
  • 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!