forums.ps2dev.org

cadaver · Joined: 07 Aug 2005 Posts: 21

I'm trying to render some big triangles (2 for a floor). The problem is, that they disappear when they are rendered at a small distance. It is not that parts of them are clipped, they completly disappear. With small triangles no problem. Also no problem, when they are rendered in a greater distance.

Jim · Joined: 02 Jul 2005 Posts: 487 Location: Sydney

Just a guess, but perhaps there's a numeric overflow in your calculations which is causing the triangles to wrap around or produce NAN coordinates, or perhaps the PSP has some kind of 2d guard-band. I've seen apps for the PS2 that go wrong if the coordinates lie outside (1024,-1024)-(1024,1024)

Jim
_________________
http://www.dbfinteractive.com

chp · Joined: 23 Jun 2004 Posts: 313

If your object is going to go near the camera or the edges, enable clipping with sceGuEnable(GU_CLIP_PLANES). Detecting this is rather easily done using some kind of bound-detection (spheres, AABB).

The PSP has a guard-band of 4096x4096, so the largest coordinates are (-2048,-2048)-(2047,2047).
_________________
GE Dominator

cadaver · Joined: 07 Aug 2005 Posts: 21

it can be reproduced in the gu samples, so I don't think it is something special in my source.
(just take the cube sample, disable the animation, render only the top quad to y = -2 or so and make it bigger)

cadaver · Joined: 07 Aug 2005 Posts: 21

chp,

you are right, sceGuEnable(GU_CLIP_PLANES) changes the behaviour. but how can I set the clip planes ?

chp · Joined: 23 Jun 2004 Posts: 313

RustyFunkNut · Joined: 26 Sep 2005 Posts: 17 Location: London, UK

Are there any issues with this when using an orthographic projection (e.g. sceGumOrtho())?

I'm seeing some really crazy clipping (or lack of it), but I am enabling GU_CLIP_PLANES.

CyberBill · Joined: 26 Jul 2005 Posts: 86 Location: Redmond, WA

The PSP does (pitiful) hardware clipping. If you zoom into any triangle enough, eventually it'll disappear.

The only way to get around it is to make your triangles in the scene small enough, and to keep your camera away from triangles.

The check is that it tests all 3 points to see if they are on the screen + some amount, if they are all off of the screen, the triangle isnt rendered.

Heres a picture....

The green area is the normal screen area (480x272 pixels), the yellow area is some amount of buffer... I honestly dont know how big this is but with some testing it could easily be found out. The red area is "bad" area.

Triangle 1 is your typical nonclipped triangle. All points are on the screen, thus it should definately be drawn. Triangle 2 shows the necessity for the 'buffer' area. If this area was not there, then any time a triangle was off of the screen as this triangle is, it would be completely clipped. In this case the triangle should be drawn.

Triangle 3 shows one bad part of this.. That triangle has no pixels on the screen, yet it will still be 'drawn'. This is the reason the buffer must be kept small, to keep rendering times up.

Triangle 4 is a bad triangle. It is clearly off screen, as all of its points are out side of the buffer and screen. It is not shown.

Triangle 5 is the one that causes everyone trouble. Even though all of the triangles points are in the 'bad' zone, it is still visible, however will be clipped. Notice with even our relatively small buffer area, a triangle has to be pretty big to have this error occur. Thus, the best thing to do is to keep your triangles small.

You should realize though that no matter how small your triangles are, if you get close enough to them you can still run into issues.

Also note that this does not just affect triangles... lines will also be clipped.

RustyFunkNut · Joined: 26 Sep 2005 Posts: 17 Location: London, UK

That's a really great reply - thanks CyberBill. It's certainly helped me straighten a few things out in my head.

My problem is that I have very little control over the geometry, as it's all coming through from the rom running under my emulator :(

It looks like I'm going to have to look at manually clipping the triangles myself, to keep them within the guard band.

I can just see a whole new world of pain opening up :)

Cheers,
Paul

Ratty · Joined: 18 Sep 2005 Posts: 18

I've noticed that increasing the near clipping range appears to help this problem, i don't know why. But i set it to 4.0 for my scene to get things looking good. If you can live with this then it might be a good solution.

CyberBill · Joined: 26 Jul 2005 Posts: 86 Location: Redmond, WA

Rusty, if you are in a situation like that, my recomendation is to turn off clipping. If it runs too slowly, then work on optimizing the sprites/quads/triangles yourself, by implementing clipping somehow. Or maybe you just need to split up each triangle into 4 (imagine the TriForce). This effectively doubles the imaginary 'buffer' size.

If you are dealing with it on a sprite level, its really easy to do a bounding box check to see if it is on the screen, and chances are that'll end up being more efficient than letting hardware handle it. (You do 3 ifs to cull 2 triangles, they do 3 transforms & 3 ifs to cull 1 triangle)

RustyFunkNut · Joined: 26 Sep 2005 Posts: 17 Location: London, UK

Thanks for the further suggestions guys.

Ratty: I have to use an orthographic projection, but it's possible that I can tweek the near plane that I'm using to see if this helps a little.

CyberBill: I managed to get Sutherland-Hodgman clipping working today (to an extent). It looks promising but there are a number of bugs I still need to fix as it looks like it's not quite clipping things to the frustum correctly :(. I like the idea of splitting large polys down - it should be a lot easier to implement and might be good enough for what I need. I could keep subdividing until the triangle's area hit a certain lower limit. I'm massively CPU-bound at the moment so it doesn't look like rendering more polys/frame is going to slow things down too much at this stage.

Thanks again!

skistovel · Joined: 17 Jul 2006 Posts: 14

I know that the subject has been beaten to death - but I am having the same problem. Large triangles, gets clipped off if 2 or more points of the triangle are off the screen.

The thing is, I disabled CLIP_PLANES and SCISSOR_TEST, but still gets clipped. Is that normal behaviour ( I thought by disabling clipping, all geometry gets drawn independent of their position inside/outside frustum)?

It is not a big problem, it is just the fact that I spent two days of my life on the subject thinking that I am doing something wrong with my code.. :-(

Jim · Joined: 02 Jul 2005 Posts: 487 Location: Sydney

Nothing with vertices outside the (-2048,-2048)->(2047,2047) guard-band will draw. Clipping/scissoring ON is designed to fix it.

Jim
_________________
http://www.dbfinteractive.com

skistovel · Joined: 17 Jul 2006 Posts: 14

No, nothing THAT big, actually not bigger that 4-5 units! Its just the fact that as you hover the camera around, sometimes 2 points of the triangle (the half of the floor in my case) will be outside the frustum and so you will be seeing the background color instead of the floor.

But it doesn't matter, I decided to create new geometry where the frustum splits a triangle. Whats the point of drawing something outside the view? :-)

skwi · Joined: 16 May 2006 Posts: 22

you should increase the "near" of guprojection, this should hepl

Ghoti · Joined: 31 Dec 2005 Posts: 288

Hi folks,

I have the same problem indeed, (maybe this should be a sticky for future help for others), I have to put the near value to 8!!!

i'm going to make my triangles smaller i guess because this just won't do.
If someone has allready found a good solution to it, plesae share it with us.

Some much for lowpoly programming....

greets ghoti
_________________
My PSP games:

Boxy II: http://www.ghoti.nl/boxyii.php
Elementals: http://www.ghoti.nl/Elementals.php

Jim · Joined: 02 Jul 2005 Posts: 487 Location: Sydney

The solution is called 3D clipping. Clip the object in camera space, before the projection, to make sure all projected points end up on screen.

Jim
_________________
http://www.dbfinteractive.com