
Announcements

November GameDev Challenge: Pong! 11/01/17

Matt Aufderheide
Members
Content count
881 
Joined

Last visited
Community Reputation
129 NeutralAbout Matt Aufderheide

Rank
Advanced Member

Trouble with marching cubes
Matt Aufderheide replied to Matt Aufderheide's topic in Graphics and GPU Programming
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]; 
Trouble with marching cubes
Matt Aufderheide replied to Matt Aufderheide's topic in Graphics and GPU Programming
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); 
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 "litec" 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.

Rebuilding normals from position
Matt Aufderheide replied to Matt Aufderheide's topic in Graphics and GPU Programming
Works perfectly, thanks so much 
Rebuilding normals from position
Matt Aufderheide replied to Matt Aufderheide's topic in Graphics and GPU Programming
Works perfectly, thanks so much 
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...

What shader model are you compiling this for? Because ps 3.0 only has 224 constant registers as far as i know.
 3 replies

1

Screen Color Precision
Matt Aufderheide replied to jameszhao00's topic in Graphics and GPU Programming
What problems are you referring to.. i dont see any banding ... the gradations look a bit different but both seem very smooth. 
Calculating LOD steps
Matt Aufderheide replied to Matt Aufderheide's topic in Graphics and GPU Programming
Thanks I will give that a try 
Calculating LOD steps
Matt Aufderheide replied to Matt Aufderheide's topic in Graphics and GPU Programming
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? 
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?

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.

Also you can optimize your blur passes a bit. First make sure the target is as small as it can be. Usually halfsize 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.

make object face camera (not so simple)
Matt Aufderheide replied to Matt Aufderheide's topic in Graphics and GPU Programming
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. 
make object face camera (not so simple)
Matt Aufderheide replied to Matt Aufderheide's topic in Graphics and GPU Programming
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...