# any problems with this code?

This topic is 3922 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

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] = left planes[1] = right planes[2] = top planes[3] = bottom planes[4] = z near which 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]

##### Share on other sites
* My eyes, they burn. *

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?).

##### Share on other sites
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]

1. 1
2. 2
Rutin
18
3. 3
4. 4
5. 5

• 26
• 11
• 9
• 9
• 11
• ### Forum Statistics

• Total Topics
633701
• Total Posts
3013443
×