Jump to content
  • Advertisement
Sign in to follow this  
staticVoid2

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.

If you intended to correct an error in the post then please contact us.

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 this post


Link to post
Share on other sites
Advertisement
* 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?).

Share this post


Link to post
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]

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!