# Matt Aufderheide

Member

881

129 Neutral

• Rank
1. ## Trouble with marching cubes

ok I got it working :) should have been like this: vec_set(CELL.p[0],vector(x,y,z)); vec_set(CELL.p[1],vector(x+1,y,z)); vec_set(CELL.p[2],vector(x+1,y,z+1)); vec_set(CELL.p[3],vector(x,y,z+1)); vec_set(CELL.p[4],vector(x,y+1,z)); vec_set(CELL.p[5],vector(x+1,y+1,z)); vec_set(CELL.p[6],vector(x+1,y+1,z+1)); vec_set(CELL.p[7],vector(x,y+1,z+1)); CELL.val[0]=voxel[x][y][z]; CELL.val[1]=voxel[x+1][y][z]; CELL.val[2]=voxel[x+1][y][z+1]; CELL.val[3]=voxel[x][y][z+1]; CELL.val[4]=voxel[x][y+1][z]; CELL.val[5]=voxel[x+1][y+1][z]; CELL.val[6]=voxel[x+1][y+1][z+1]; CELL.val[7]=voxel[x][y+1][z+1];
2. ## Trouble with marching cubes

Changed some things , works better now but still not right...this is what I have now : GRIDCELL CELL; TRIANGLE TRI[5]; vec_set(CELL.p[0],vector(x,y,z)); vec_set(CELL.p[1],vector(x+1,y,z)); vec_set(CELL.p[2],vector(x,y+1,z)); vec_set(CELL.p[3],vector(x+1,y+1,z)); vec_set(CELL.p[4],vector(x,y,z+1)); vec_set(CELL.p[5],vector(x+1,y,z+1)); vec_set(CELL.p[6],vector(x,y+1,z+1)); vec_set(CELL.p[7],vector(x+1,y+1,z+1)); CELL.val[0]=voxel[x][y][z]; CELL.val[1]=voxel[x+1][y][z]; CELL.val[2]=voxel[x][y+1][z]; CELL.val[3]=voxel[x+1][y+1][z]; CELL.val[4]=voxel[x][y][z+1]; CELL.val[5]=voxel[x+1][y][z+1]; CELL.val[6]=voxel[x][y+1][z+1]; CELL.val[7]=voxel[x+1][y+1][z+1]; int i=0; int p=0; int q=0; p=Polygonise(CELL,0.5,TRI);
3. ## Trouble with marching cubes

Trying to implement simple marching cubes using Paul Bourke's code example (http://paulbourke.net/geometry/polygonise/)   I first set up a test voxel field like so: void setup_voxels() {  int x=0;  int y=0;  int z=0;    for(x=0;x<voxel_num;x++)  {   for(y=0;y<voxel_num;y++)   {    for(z=0;z<voxel_num;z++)    {     if (z<4)     {      voxel[x][y][z]=1;     }          else     {      voxel[x][y][z]=0;     }    }    }  }   This would be a 16*16*16 cube, with only the the first four levels  actually set as "on" . I then loop through each cell and try to set up the grid cells and call the polygonise function   for(x=0;x<voxel_num;x++)  {   for(y=0;y<voxel_num;y++)   {    for(z=0;z<voxel_num;z++)    {      GRIDCELL CELL;      TRIANGLE TRI[5];       XYZ tempvec;              tempvec.x=x*16;tempvec.y=y*16;tempvec.z=z*16;        vec_set(CELL.p[0],tempvec);            tempvec.x=x*16+16;tempvec.y=y*16;tempvec.z=z*16;      vec_set(CELL.p[1],tempvec);            tempvec.x=x*16+16;tempvec.y=y*16+16;tempvec.z=z*16;      vec_set(CELL.p[2],tempvec);            tempvec.x=x*16;tempvec.y=y*16+16;tempvec.z=z*16;      vec_set(CELL.p[3],tempvec);            tempvec.x=x*16;tempvec.y=y*16;tempvec.z=z*16+16;      vec_set(CELL.p[4],tempvec);            tempvec.x=x*16+16;tempvec.y=y*16;tempvec.z=z*16+16;      vec_set(CELL.p[5],tempvec);            tempvec.x=x*16+16;tempvec.y=y*16+16;tempvec.z=z*16+16;      vec_set(CELL.p[6],tempvec);            tempvec.x=x*16;tempvec.y=y*16+16;tempvec.z=z*16+16;      vec_set(CELL.p[7],tempvec);      CELL.val[0]=voxel[x][y][z];      CELL.val[1]=voxel[x+1][y][z];      CELL.val[2]=voxel[x+1][y+1][z];      CELL.val[3]=voxel[x][y+1][z];             CELL.val[4]=voxel[x][y][z+1];      CELL.val[5]=voxel[x+1][y][z+1];      CELL.val[6]=voxel[x+1][y+1][z+1];      CELL.val[7]=voxel[x][y+1][z+1];          int i=0;      int p=0;            p= Polygonise(CELL,0.5,TRI);   This is written in something called "lite-c" so it might seem a bit weird. Compiles fine and does return triangles, but they all seem messed up as far as positions and so on. I'm assuming I'm not getting something about the  CELL.val and what the values are actually supposed to be , I just made it one or zero depending on if a voxel cell is filled or not.    I hope this makes at least some sense...maybe I am totally misunderstanding how this method works..?? If anyone has any idea what's going on I'd be happy to get some help.
4. ## Rebuilding normals from position

Works perfectly, thanks so much
5. ## Rebuilding normals from position

Works perfectly, thanks so much
6. ## Rebuilding normals from position

HI, I'm trying to reconstruct approximate normals in a pixel shader using only the inputs from the vertex shader...This is because the mesh I am rendering doesn't have proper normals, and it's too costly to recomputed them  any time I deform it in the application. Don't want to use a normal map because the mesh is too big (its a terrain).   I know you can render a depth texture out and reconstruct normal from that, but I wanted to try to do it all at once without rendering depth.. I don't know If this is possible.   I was thinking I could simply pass a few different positions from the VS and do something in the pixel shader.. but not sure what...   The basic result ought to be flat normals in view space or world space...
7. ## Help with Simplex Noise

What shader model are you compiling this for? Because ps 3.0 only has 224 constant registers as far as i know.
8. ## Screen Color Precision

What problems are you referring to.. i dont see any banding ... the gradations look a bit different but both seem very smooth.
9. ## Calculating LOD steps

Thanks I will give that a try
10. ## Calculating LOD steps

Maybe this question was too general... when calculating LOD distance steps for terrain patches, should you use the center of the patch or some kind of bounding box, ...if so, how do you test the distance to a bounding box/sphere? What if you are inside the bounding box? Also, is there a normal method for calcualting LOD steps based on distance?
11. ## Calculating LOD steps

Say i have a large sphere (planet) made of patches. I have 8 LOD steps for each patch. Each patch has a position at it's "center" (because it's curved the center isnt exactly at the center of the patch but its "sphere" position --the sphere starts out as a cube). What's a good way to calculate LOD step distances for these 8 steps...besides doing it manually with lots of trial and error which I'm having trouble with. Also, should I calculate the distance based on the position or some kind of bounding sphere/box for each patch?
12. ## Scaling a cube of patches

Say i have a cube made out of flat square patches... each face of the cube is made out of 16 patches. Assume cube is always going to be centered at 0,0,0 and each patch has its own position and is oriented in the correct manner to make a cube.. Now i want to scale this uniformly...so obviously i need to scale the patches themselves which is simple, and then adjust their positions accordingly. I tried something like this: 1) scale patches 2) pvector=normalize patch position 3) new position=pvector*some number... this doesnt work..i think the basic idea is wrong and i cant think of a correct way.
13. ## Speeding Up Blur

Also you can optimize your blur passes a bit. First make sure the target is as small as it can be. Usually half-size of screen resolution is ok for blurring. Also, you may want to turn off all color writes besides red, and use the red channel for all the data, because usually SSAO uses a single channel anyway.
14. ## make object face camera (not so simple)

OK, thanks but I'm not trying to do actual billboarding, so view plane alignment wont work for me; I dont want the object moving around when i rotate the camera. Let me restate things: 1)I am trying to rotate an object to always face camera. 2)It must not move when the camera rotates. 3)It shouldn't spin around when the camera is above or below the object. 4)I have to be able to rotate in "increments" of degrees or radians While I have mainly been trying to rotate it using Euler angles, i tried a lookat matrix with the same problems. To me, whatever this problem is called, it seems as though the rotation axis is the important thing. I wish i could explain better, but the practical reason I am doing this is as follows: I want to render a spherical terrain (planet). I am using vertex textures generated on the fly to displace the terrain and I use a series of flat nested square patches to represent the terrain(they will be displaced and "spherized" in the vertex shader). These patches must rotate around a centerpoint to always face the camera (to maintain the highest vertex density near the viewer) , but they have to move in specific increments so the vertex texture always aligns with the vertices in the same way (otherwise you get this swimming effect). I think you can see then why this "spinning" is a problem. It works fine when the camera is rotating the planet around the equator, but as you go up toward the poles this spinning starts. I tried to explain it in the simplest way possible without all this other stuff.
15. ## make object face camera (not so simple)

Ok as i understand it gimbal lock is loss of a degree of freedom when using Euler angles to rotate. It seems to me that roll has no effect when the camera is near the poles of the object to be rotated. Maybe this isnt the case...im a bit confused now. Basically though i think i need to use a dynamic axis for rotation...