a normals problem with voxels
Author
Ok, now that code is for openGL, and I work in directx 9, so a little transformation must be done, but i would like to understand the logic behind that code before doing a 1to1 conversion. Can you give me a small explanation on how this works, I really don't understand how a pixel shader know the direction of the normal, by just looking at a single point.
From what I've read, in minecraft Notch draws the faces of the cubes in batches, ie all north faces in one pass, then all east faces, then all up faces etc. If you figure out the orientation of the player's view, they can only ever be seeing 3 faces of a cube, so with some trickery you can really reduce the amount of drawing you need to do.
He also combines adjacent blocks into larger polys to cut down on the amount of vertex data he has to work with for a given frame.
Another thing to consider is that since you're working with axis-aligned blocks, there's only 6 unique normals in the entire world. You could represent this as a single index and pretty much hardcode it in the shader.
He also combines adjacent blocks into larger polys to cut down on the amount of vertex data he has to work with for a given frame.
Another thing to consider is that since you're working with axis-aligned blocks, there's only 6 unique normals in the entire world. You could represent this as a single index and pretty much hardcode it in the shader.
Ok, now that code is for openGL, and I work in directx 9, so a little transformation must be done, but i would like to understand the logic behind that code before doing a 1to1 conversion. Can you give me a small explanation on how this works, I really don't understand how a pixel shader know the direction of the normal, by just looking at a single point.
As i understand it, the ddx and ddy instructions compute the rate at which a variable is changing. To do this, they compare the value at the current pixel with the value of the adjacent pixel in x or y.
In this case, the variable we are using is the position. ddx() computes how much this position changes as we move to the next position in x. This change of position is a vector which lies along the surface of the polygon. By doing ddy() as well you then have two vectors which lie along the surface of the polygon. The cross product to these is perpendicular to both, and is therefore a normal.
Author
minecraft uses textures to represent different terrains, but I wont have that, I'll use just colors on different gradients like the first image on the post, same for all my objects, characters and so on. And it seems that I have enough blocks already, and I could double the ones I have on screen to 2048 *2048 and still get 60fps, (even I get really tight on memory), I'll probably leave it at 512*512 as it only uses around 250MBs and that will leave me with quite so room to play with, besides also my approach is a little different, this map in infinite in every direction not just X and Z. I'm going for a terraria kind of map on the Y scale. Maybe after Y at -15.000 I'll put an indestructible block with hell just above it but I'll have to think that through. Also I'm not having destruction/construction in a minecraft way, its a different kind of game, the looks are just similar as destruction is much simpler in 1x1x1 blocks.
Poly,
so the ddx and ddy checks the adjacent pixes, and it kinda makes a fake triangle of pixels to find where the perpendicular value to all 3 is. Right?
Poly,
so the ddx and ddy checks the adjacent pixes, and it kinda makes a fake triangle of pixels to find where the perpendicular value to all 3 is. Right?
so the ddx and ddy checks the adjacent pixes, and it kinda makes a fake triangle of pixels to find where the perpendicular value to all 3 is. Right?
Yeah, I guess you could think of it like that.
Author
well the test came out rather well, with no visible performance decrease. and 136 million cubes in mem. not bad.
[attachment=7765:gen test3.png]
thanks a lot for all your input guys.
[attachment=7765:gen test3.png]
thanks a lot for all your input guys.
Author
well it ain't over until the fat lady sings, So I started to put some procedural trees inside, and there seems to be some color bleeding. tree bark is supposed to be brown, and leaves green (for test purposes of course), any ideas on how to fix this?
[attachment=7778:gen test4png.png]
[attachment=7778:gen test4png.png]
Author
duh... obvious what was going here, a pixel can have 2 colors, and since I-m using only one, the first to be written get prioritized, and so only one brown vertex was held, but since I don't want to loose the effect (probably I even can't unless I write several vertexes more) the I just let the creator know that I want my tree bark to be prioritized and such, it looks much better. I will probably change the prioritization of the bark when it hits the grass or something like that, in order to make the tree look more like getting out from the grass itself.
[attachment=7780:gen test5.png]
[attachment=7780:gen test5.png]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
