   any problems with this code?
  hi, I've wrote this code for frustum culling, which works, but I've noticed the clipped poly to jump around a bit at certain edges.Clip(Polygon_t *polyin, Polygon_t *polyout){   Polygon_t *n = new Polygon_t;   polycpy(polyin, n); // copy polyin to n   Polygon_t *temp;  // temp pointer for swapping   Polygon_t *a = n, // make a point to the copied poly   *b = polyout; // make b point to polyout   /* clip poly a to b and then swap the pointers to increment the clipping process */   for(int c = 0; c < 5; c++) { // for the 5 sides of the frustum if(!planeClipPoly(a, b, planes[c])) { // clip poly a to poly b    polyout->nVertices = 0;    break; } temp = a; // swap the pointers a = b; b = temp;   }   delete n; // delete the copy of polyin}planeClipPoly just clips poly a to poly b and returns the number of new vertices. because the loop iterates 5 times it works out that the final clipped poly should be in polyout. I noticed that the jumpiness was in the left and top sides,planes[0] = leftplanes[1] = rightplanes[2] = topplanes[3] = bottomplanes[4] = z nearwhich is every even number, where the clipped poly is being stored directly in polyout, can anyone see whats causing this?[Edited by - staticVoid2 on March 18, 2008 2:39:51 PM]
* My eyes, they burn. *Your algorithm needs a massive readability re-haul. Of special interest is the appearance of polyout->nVertices = 0; in a loop where polyout is being aliased by a and b. I guess I can understand why it doesn't cause a problem, but I'm still not sure. Ultimately, I suspect that the entire pointer-swapping approach was a failed optimization attempt. Consider:Clip(Polygon_t *polyin, Polygon_t *polyout){  polyout->nVertices = 0;    Polygon_t a;  if(!planeClipPoly(polyin, &a, planes[0])) return;  Polygon_t b;  if(!planeClipPoly(&a, &b, planes[1])) return;  Polygon_t c;  if(!planeClipPoly(&b, &c, planes[2])) return;  Polygon_t d;  if(!planeClipPoly(&c, &d, planes[3])) return;  planeClipPoly(&d, polyout, planes[4]);}One less dynamic memory allocation, and one less polygon copy, and it's more readable too. If this method causes the same bug, then it's coming from something else (such as your plane definitions, or floating-point precision). Otherwise, the problem is coming from your strange function there.As a side note, you have reinvented copy constructors (why don't you write Polygon_t *n = new Polygon_t(*polyin) ?), std::swap (why don't you write std::swap(a,b) ?) and auto variables (why is n allocated dynamically if you know it's going to be destroyed before the function ends?).   ;  It must be somthing else that's causing the jitter. I tried your code and it's doing the same thing(although probaly a bit faster).Quote:(why is n allocated dynamically if you know it's going to be destroyed before the function ends?).I was going to change that, I usally just throw things together to try and get code to work and then revise it.thanx.Edit:I'm calculating the line plane intersections using the plane normal and distance from origin, when i set distance to 0.0001 instead of 0 it seems to work.[Edited by - staticVoid2 on March 18, 2008 3:26:53 PM]