Long tristrips slow on PVR?

[bogglez]

Somebody on http://www.pouet.net/prod.php?which=54656 wrote

when you generate strips you don't want the longest possible strips (in my experience 6 to 15 triangles is the optimal size) because the final rendering performance is dependent on the number of tiles covered by the bounding rectangle occupied by the projected stripe.

So if you try to get very long stripes by using fancy libraries, you get the risk of having the bounding box of the stripe to cover the whole screen, which will force the PVR to check every single damn tiles. It's also increasing the memory requirements.

I can't really follow this logic. If he splits up the tristrip into multiple draw calls the other tiles will have to be checked anyway, right? Do you see any truth behind this?
I assume he means that a tripstrip from the top left to the bottom right of the screen would also force the top right and bottom left tiles to be checked, although the tristrip is not there. Don't know whether the PVR works like this, still reading..

[PH3NOM]

That seems quite dependent upon other factors as you have mentioned.

But that brings up an interesting link to Microsoft's Developer Network about optimizing code for WinCE on DC.
http://msdn.microsoft.com/en-us/library/ms834190.aspx

But one thing bothers me there:

In addition, with the Dreamcast hardware, you don't need to clip the triangles to the screen viewport, so there is no need for clipping tests and calculations. This is because the hardware renders graphics tile by tile. As a result, you don't need to test primitives, nor do you need to break up primitives into smaller primitives that fit on the screen.

If that is true that there is no need for clipping tests, why do we seem to need to clip vertices to the Near-Z Plane? Are we doing something wrong with the PVR in KOS?

[BlueCrab]

I think he is solely speaking about the X/Y plane. Later in the same article, he says that Direct3D has to do the near plane clipping:

While the Dreamcast hardware does the viewport clipping, Direct3D does the near plane clipping if the DONOTCLIP flag is not set. The DONOTCLIP flag tells Direct3D not to do clipping calculations. It is best to turn the DONOTCLIP flag on whenever possible. Test each object to see if it touches the near plane. If it does, then you know that all of its triangles won't have the DONOTCLIP flag set.

[bogglez]

But that brings up an interesting link to Microsoft's Developer Network about optimizing code for WinCE on DC.
http://msdn.microsoft.com/en-us/library/ms834190.aspx

Now that sounds completely opposite of what I quoted before..

Send as many vertices as possible in a single DrawPrimitive call. This is the most important optimization you can do. Do everything you can to keep from breaking up primitives.

If that is true that there is no need for clipping tests, why do we seem to need to clip vertices to the Near-Z Plane? Are we doing something wrong with the PVR in KOS?

I got that like BlueCrab.
We don't do the optimization they mention right now at all..
1. Check in rendering engine whether bounding volume is completely in front of the near clip plane
2. If it is, set a flag, call glDraw*
3. In OpenGL, if the flag is set, don't do clipping at all.
Right now we lack such a flag to communicate this. Completely dodging the clipping algorithm would be a huge optimization I think.

[PH3NOM]

I think he is solely speaking about the X/Y plane. Later in the same article, he says that Direct3D has to do the near plane clipping:

While the Dreamcast hardware does the viewport clipping, Direct3D does the near plane clipping if the DONOTCLIP flag is not set. The DONOTCLIP flag tells Direct3D not to do clipping calculations. It is best to turn the DONOTCLIP flag on whenever possible. Test each object to see if it touches the near plane. If it does, then you know that all of its triangles won't have the DONOTCLIP flag set.

Right you are! I should have continued reading through the whole article lol.

But that brings up an interesting link to Microsoft's Developer Network about optimizing code for WinCE on DC.
http://msdn.microsoft.com/en-us/library/ms834190.aspx

Now that sounds completely opposite of what I quoted before..

Send as many vertices as possible in a single DrawPrimitive call. This is the most important optimization you can do. Do everything you can to keep from breaking up primitives.

If that is true that there is no need for clipping tests, why do we seem to need to clip vertices to the Near-Z Plane? Are we doing something wrong with the PVR in KOS?

I got that like BlueCrab.
We don't do the optimization they mention right now at all..
1. Check in rendering engine whether bounding volume is completely in front of the near clip plane
2. If it is, set a flag, call glDraw*
3. In OpenGL, if the flag is set, don't do clipping at all.
Right now we lack such a flag to communicate this. Completely dodging the clipping algorithm would be a huge optimization I think.

Well, the single DrawPrimitive call is sort of how my GL API interacts with the PVR.
It only requires one transfer per list of vertex data to the PVR, and that includes PVR polygon headers in-line with the vertex data.

About the polygon clipping, that part is up to your 3D engine, as mentioned in the article.

And that is how I have arranged things in the Quake 3 BSP renderer I have been working on and off on.
Quake 3 level geometry is based on Faces. A face can contain several triangles.
I use the Bounding Boxes of each Face to determine if the Face is behind the Near-Z plane ( remember my 8 dot-product function you commented on? )
My engine walks the faces, marking with one of 3 flags:
1.) Completely Behind Camera, Cull the Face ( do not send to GL for rendering )
2.) Partially Behind Camera, Clip the Face ( send to GL for rendering with Z-Clipping Enabled )
3.) Completely in Front of Camera ( send to GL for rendering with Z-Clipping Disabled )

[bogglez]

Ah yeah I just remembered you added that glEnable flag! You got me there