HSR in Andre's new book

Started by
1 comment, last by Uthman 20 years, 8 months ago
hello all- i just recently picked up a copy of andre's tricks od the 3d game programming gurus; execellent book, and i highly recommend it to all of you +1. my question is this - andre has a pretty simple algo that does Back Face Removal in world space; he calculates a polygon's normal and checks the dot product between that normal and a sight vector (cam-polygonpnt[0]). (see scenario 1, red lines are visible polygons) this technique seems to work well with his engine, but when i tried implementing it into mine, failure occured. the sight vector (cam-vertex) does not take into account camera rotations, so even if i rotate my camera 180 degrees, it'll all look the same to the hsr function, considering all of this is happening in world space. (See scenario 2) Right now, to take a single polygon from world->camera coordinates, it takes my engine 27 multiplications and a hoard of additions. if i add HSR after i have camera coordinates, it works perfectly, but the only speed ill get is from not having to rasterize the polygon, and right now im at a place where my rasterizer is fast enough that i dont care about drawing a few more hundred polys or so. but if i can get HSR working *BEFORE* the world->camera transformation, i can save [(27multiplications+27additions) <--- world->camera and (6multiplications+6subtractions) <--- camera->screen] PER polygon, which would boost my engine speed ~20-40 percent if im rendering a dense object (such as a bull, or human, or any convex object in the universe) thats roughly 50% invisible from any given point of view. Is there a way to do hsr before world->camera that doesnt reqire too many calculations and corrects my problem, or am i just doing something wrong? Help! btw, this is a ss of xGL, my 3d engine for PocketPC devices! this is a computer executable (so that i can take the screenshots) and it actually runs about 8x slower on the actual device (~52fps). not bad considering if you had just a loop that did nothing except flop back->front image buffer, you'd never hit more than 55fps [edited by - Uthman on August 12, 2003 7:10:39 AM]
"a low level aho master like you couldn't kill me even if I let you"
Advertisement
you could transform the camera's location into the object space of what you are rendering, but it requires an inverse matrix (or a headache), which is a pretty expensive operation. my matrix inverse (a rather naive one) uses 52 + 192 multiplications, (52 for determinant, 192 for the 'core' of the inverse function), and 27 + 96 add/subtracts (again 27 for determinant, 96 for the invert function). so, if you are rendering a mesh with more than around 20-30 backfacing triangles (if you do nothing BUT the inverse its about 9, but my matrix function requires a temp matrix, copy constructor, plus stuff that would happen to the camera position). also, there might be a faster way to do matrix inversion, i only need generally a few per frame, so on the PC this isn't going to kill anything but in your case, you would want to look into a faster inversion. i'm guessing it will be worth it if your mesh has any more than 100 triangles given my matrix inversion function, i'm sure you could come up with something faster/more efficient.

you are apparently not using matrices, so you are on your own for calculating the 'inverse' transformation. what you basically want, whether you do it with matrices or 'optimized' transforming, is to get the camera's position relative to the object for backface culling. with matrices, an inverse of the camera matrix achieves this.

[edited by - billybob on August 12, 2003 7:43:36 AM]
I did 3D backfack culling for a 3D engine I wrote in flash, I used a method very similar to this...

http://www.cubic.org/~submissive/sourcerer/backcull.htm#ma3

Oh, and Andre''s book is great I went through all of it in about three days, highly reccomended.

This topic is closed to new replies.

Advertisement