3D graphics/BLACK ART OF 3D GAME PROGRAMMING

My question pertains to the book BLACK ART OF 3D GAME PROGRAMMING. I'm using Turbo C++ 3.0, and when I code the part on making 3d graphics in mode 13h, I get some problems. First in drawing the cube in wire frame. The lines stop being draw if I move the cube too far right or left. And then when I tried to draw the cube with flat shading. The program breaks it into triangles but not all the triangles work. If you want to take a look at the code just email me (omh16@yahoo.com) I appreciate anyone's help







Comments

  • : My question pertains to the book BLACK ART OF 3D GAME PROGRAMMING. I'm using Turbo C++ 3.0, and when I code the part on making 3d graphics in mode 13h, I get some problems. First in drawing the cube in wire frame. The lines stop being draw if I move the cube too far right or left. And then when I tried to draw the cube with flat shading. The program breaks it into triangles but not all the triangles work. If you want to take a look at the code just email me (omh16@yahoo.com) I appreciate anyone's help


    i havnt got that book so i may be way off base here, but does the code include any clipping for the wire-frame code or determining which faces are showing for the shading code?

    without clipping, if you move the cube to the edge of the screen things are going to go wierd as the pixel coordinates wrap.

    without face ordering, the triangles at the back of the cube may be showing through the front ones.

  • your right about the pixel coordinates wrapping if there's no
    clipping on the lines, but I have a function that clips the line to the screen (mode 13h). It's just when I move the cube to the middle right screen (not all the way right)it just disappears, polygon by polygon. I know I can draw lines in this area, I've tested it, but for some reason it can't work with my cube.
    I was thinking about the face ordering algorithm you said, it might be why it doesn't work. The book says check to see if the dot product of the normal of the triangle plane, and the user's point of view and checks if this dot product is greater than zero. If it is then its visible, it gets draw according to the algorithm. I get a dot product of about 48000,or -48000. The problem is I think that dot product is being taken in the wrong direction (toward the center of the cube) and thats why it displays the back part of cube, and not the front. How it got this way I don't know, but I would like to know more about the face ordering. And would somebody like to look at the code?(email me) It should be understandable to anyone who knows about 3d coding.


  • Firstly, some of the source code listed in the Black Art Of 3D Game Programming book contains bugs.. quite a few actually. Make sure to understand the code so you can quickly find the author's errors.

    For the backface culling you're talking about, make sure to use the vector from the polygon to the viewer, not the other way around. Use any of the face's vertices to calculate this vector, or the face's center if you want, it doesn't matter. Your dot product will have large numbers if your normals aren't normalized. Otherwise, they'll lie between -1 and 1. Either way is fine for backface culling cuz you're just checking the sign of the result.

    Scorpion


    : I was thinking about the face ordering algorithm you said, it might be why it doesn't work. The book says check to see if the dot product of the normal of the triangle plane, and the user's point of view and checks if this dot product is greater than zero. If it is then its visible, it gets draw according to the algorithm. I get a dot product of about 48000,or -48000. The problem is I think that dot product is being taken in the wrong direction (toward the center of the cube) and thats why it displays the back part of cube, and not the front. How it got this way I don't know, but I would like to know more about the face ordering. And would somebody like to look at the code?(email me) It should be understandable to anyone who knows about 3d coding.
    :
    :


  • Well I discovered a bug in the code as you said. Andre
    took Cross_Product with the variables mixed. he did v x u
    when he said it needed to be u x v for this coordinate system (left hand I think) but there's still something wrong with it.
    Here's what I get after fixing the one bug:
    http://members.fortunecity.com/omh16/CUBE.gif
    http://members.fortunecity.com/omh16/CUBE1.gif
    when I watch it run, some faces are kinda transparent, some completely solidly shaded. Also Two triangles on the same face have different shades. Strange no?

  • : Well I discovered a bug in the code as you said. Andre
    : took Cross_Product with the variables mixed. he did v x u
    : when he said it needed to be u x v for this coordinate system (left hand I think) but there's still something wrong with it.
    : Here's what I get after fixing the one bug:
    : http://members.fortunecity.com/omh16/CUBE.gif
    : http://members.fortunecity.com/omh16/CUBE1.gif
    : when I watch it run, some faces are kinda transparent, some completely solidly shaded. Also Two triangles on the same face have different shades. Strange no?
    :
    hehe, nice pics :)

    its hard to tell whats wrong with it. are you sure all your triangles have their vertices defined in the same order, eg theyre all defined clockwise.

  • From the weird edges in those pics, I'd say you have problems in the triangle rasterizer. As MrEd mentionned, you should probably re-order your vertices to flip those normals, and quadruple-check them cuz it's an easy mistake to make. Also, since you seem to be moving the cube around, did you remember to transform the normals as well? They need to be rotated with the object. Without this, the polygons will drop in and out when rotating.

    Scorpion

    : Well I discovered a bug in the code as you said. Andre
    : took Cross_Product with the variables mixed. he did v x u
    : when he said it needed to be u x v for this coordinate system (left hand I think) but there's still something wrong with it.
    : Here's what I get after fixing the one bug:
    : http://members.fortunecity.com/omh16/CUBE.gif
    : http://members.fortunecity.com/omh16/CUBE1.gif
    : when I watch it run, some faces are kinda transparent, some completely solidly shaded. Also Two triangles on the same face have different shades. Strange no?
    :


  • Well I fixed the problem, it wasn't the normals of the polygons. The normals are recalculated for each polygon right before I do the cross_product. I also made the cubes visible when the dot product between the line of sight and is greater OR EQUAL to zero. This was something he said, I thought it was a good idea to change it. The thing was rewriting the 3d file(.PLG files). It couldn't handle quadralaterals, so I made them all triangles. This made it work. Also I wasn't setting the visible variable!! Thats why all the polygons showed up in the back. Once I did this I realized it can't draw quadrilaterals because I only had 3 vertices in my polygon structure. I put four and it works! Here is a picture, and thanks for the comentary!! it helped me look for the right things
    http://members.fortunecity.com/omh16/CUBEWORK.gif

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories