Polygons clipped by view? Need help!!

subbie · Post by **subbie** » Wed Dec 07, 2005 6:43 am

http://files.pspupdates.qj.net/cgi-bin/ ... ,0,12,1808 <- viewer
http://files.pspupdates.qj.net/cgi-bin/ ... ,0,12,1809 <- test maps

If someone who is familiar with using the GU & GUM librarys. Take a look at the demo linked above. Load one of the maps (from the second link) and go near a large wall or floor. A polygon should be dropped and allow you to see though when you shouldn't.

Any idea's for what I could do to stop the clipping the psp is doing for large polygons that go though the screen?

I have scissor test & clipping planes enabled.

chp · Post by **chp** » Wed Dec 07, 2005 7:38 am

Although the GE does clip the near plane, for some reason the clever heads at Sony never added clipping of the other 5 planes, which means that if a triangle does go beyond the 4096x4096 grid, it will not be drawn. In the samples the GE is setup to render in the center of this grid, so you have (4096-480)/2=1808 pixels in width and 1912 pixels in height that the hardware will handle with scissoring, giving you some breathing space. There are a few solutions to this:

1) Do the clipping yourself before rendering. Not an optimal approach, but you'd get away with clipping only 4 planes since you really don't have to care about the far plane usually, and the hardware handles the near plane.

2) Don't push triangles that are too large. That should be rather easy to figure out, if the triangle occupy more than N area, it should be subdivided and the test should be re-done until all parts of the triangle have reached acceptable sizes. This could be done offline.

AnonymousTipster · Post by **AnonymousTipster** » Wed Dec 07, 2005 7:53 am

I've had big problems with this in the past, and have had to compromise. chp advised me to increase the near clip pane, because it means that the Z Buffer is more accurate. Increase this as far as you can without it looking wrong. This helped the problems become less noticable in my game.

subbie · Post by **subbie** » Wed Dec 07, 2005 10:51 am

I was afraid thats what the answer would be. Luckly (not in that build but my more recent one). I setup the bsp system so I can just get the cluster of polygons near the camera and just find which one is going to be dropped by the psp and sub divide it.

AnonymousTipster wrote:I've had big problems with this in the past, and have had to compromise. chp advised me to increase the near clip pane, because it means that the Z Buffer is more accurate. Increase this as far as you can without it looking wrong. This helped the problems become less noticable in my game.

What values are you using? I'm using the default .5 used in the demos. I've noticed the z-buffer becomes more accurate the less polygons used in the distance. as noted above, with the bsp tree, i'm removing alot of far polygons.

AnonymousTipster · Post by **AnonymousTipster** » Thu Dec 08, 2005 2:55 am

My code looks like this:
sceGumPerspective(fovAmount,16.0f/9.0f,3.5f,500.0f);
So it's quite close, and in places you can see this clipping, but I try to keep the camera quite above the floor, so it doesn't clip as much.

chp · Post by **chp** » Thu Dec 08, 2005 9:55 am

True, forgot to mention that. Moving the far plane further back will clip with the near plane much sooner and the hardware coordinates have less chance of going out of bounds. Good catch.

subbie · Post by **subbie** » Thu Dec 08, 2005 1:57 pm

AnonymousTipster wrote:My code looks like this:
sceGumPerspective(fovAmount,16.0f/9.0f,3.5f,500.0f);
So it's quite close, and in places you can see this clipping, but I try to keep the camera quite above the floor, so it doesn't clip as much.

Hmm I'll give that ago.

Actualy atm my numbers are 0.5f,2048.0f. Why so far away? Quake 2/3 have the clipping planes set that far (and if I use half, i will see the enviroment get clipped by the far plane).

Oh quick question. What kind of an angle are you using for the fov? Just wondering (i'm using 45deg).