Hyperion Entertainment Message Boards

Hi!

I'm really sorry to bother you with Warp3d since I'm maybe the only guy on earth using it. I promise this is my last question

I don't know if I'm facing a bug or just a limitation. Let me explain you.

To my knowledge, Warp3D scissoring is a 2D hardware clipping. Meaning, If I give it a scene at least CPU clipped by a znear (to avoid negative Z), or if I'm only working with "2D" polygons (like Hurrican), Warp3D scissoring should be able to do the whole 2D screen clipping (top/bot/left/right)... Right?

The problem I'm facing:
-With small polygons, it works perfectly.
-With large polygons, when they are going out of screen more and more, there is a "dead limit" where the polygon suddenly disappear. I don't konw if I explain it right. It's like scissoring was able to work with only a limited area of XXX pixels out of the screen. If your polygon is in this limit, it's perfectly displayed. If any vertex goes out of this band (max screen width + "dead limit", or 0 - "dead limit"), then the polygon just disappear.

This "dead limit" is not related to screen resolution. It looks fix. The problem is hard to reproduce at 640x480 (because big polygon are still quite small), quite easy at 1280x720 (cause polygon are bigger), very very easy at 1920x1080 (same).

I don't know if it is a limitation of our board, if scissoring has been designed to do very minimal clipping, or if it's a bug.
First case: I'll do with it.
Last case: Fixing this bug may be a way to DRASTICALLY unload the CPU and improve Odyssey performances on small CPU like PPC440.

'Hope I don't bother you ahah. Thanks.

Crisot wrote:To my knowledge, Warp3D scissoring is a 2D hardware clipping. Meaning, If I give it a scene at least CPU clipped by a znear (to avoid negative Z), or if I'm only working with "2D" polygons (like Hurrican), Warp3D scissoring should be able to do the whole 2D screen clipping (top/bot/left/right)... Right?

Yes. Scissoring (unlike Clipping) basically just discards pixels that are outside the scissor rectangle. Since there is no "real" 3D view volume, real clipping is not possible on an API level

The problem I'm facing:
-With small polygons, it works perfectly.
-With large polygons, when they are going out of screen more and more, there is a "dead limit" where the polygon suddenly disappear. I don't konw if I explain it right. It's like scissoring was able to work with only a limited area of XXX pixels out of the screen. If your polygon is in this limit, it's perfectly displayed. If any vertex goes out of this band (max screen width + "dead limit", or 0 - "dead limit"), then the polygon just disappear.

The feature is called (confusingly) "guardband clipping" on the Radeon (it doesn't really do any clipping). That basically adds a "guard" area around the scissor rectangle, and if a polygon is within that guard area, it will be drawn correctly and with the right scissoring applied. Polygons outside the guard area are discarded. The reason for this is to avoid infinite loops in the rasterizer hardware in case the polygon is extremely degenerate (like +/-inf coordinate).

I'm afraid there isn't much the APi can do. Your 3D engine has to do its own view frustum clipping. Scissoring is really only useful to catch the few polygons that have vertices outside the screen due to rounding errors.The only "fix" would be to rewrite the driver pipeline to use the TCL engine. In theory, it could be set up as a parallel projection with clipping planes. However, that is a pretty big change and

'Hope I don't bother you ahah. Thanks.

No, I am actually quite interesting to see your Dungeon Crawler turn into a finished game

Thanks for the fast answer.

Even though it's not as powerful as expected, it's still and excellent news! After some search on the internet, looks like early 2000 PC coders have found a way to take advantage of this.

The idea is to CULL (discard, NOT clip) polygons fully outside of the view frustum, then to CLIP polygons partially outside of "view frustum + guardband".
This way only visible polygons going outside guardband are CPU clipped. Every other polygons are "GPU scissored".

This is a great news \o/

Crisot wrote: The idea is to CULL (discard, NOT clip) polygons fully outside of the view frustum, then to CLIP polygons partially outside of "view frustum + guardband".
This way only visible polygons going outside guardband are CPU clipped. Every other polygons are "GPU scissored".

That's actually why the thing is called Guard Band Clipping. By only clipping against the guard band and culling against the clip rectangle, you can get away with less clipping operations (which usually are pretty expensive). In today's age of programmable 3D pipelines on chip, the technique has become somewhat neglected, but for a pure rasterizer API this is still a viable option.

Just to note, the next version of the main library has extents checking wherever Scissors are used. Scissors that fall partially outside the area of the target BitMap (for draw regions) or Texture (for sub image updates) will be cropped internally.

2 posts, 2 great news

Really good idea, will make scissor way more powerful.

Since you planned to "play" with the guardband, have you considered giving the possibility to developper to query the guardband size? Something like W3D_Q_GUARDBANDLEFT(RIGHT/TOP/BOTTOM).
Found on the web most modern Radeon got (+/-)8192, but I can't find informations about our 9xxx. May be useful.

Crisot wrote:2 posts, 2 great news

Really good idea, will make scissor way more powerful.

Since you planned to "play" with the guardband, have you considered giving the possibility to developper to query the guardband size? Something like W3D_Q_GUARDBANDLEFT(RIGHT/TOP/BOTTOM).
Found on the web most modern Radeon got (+/-)8192, but I can't find informations about our 9xxx. May be useful.

The reason for adding extents checking to the scissor was that I found it was possible to pass scissor areas that go outside the target area but are still passed unchecked to the driver. For texture sub image updates at least, this is very bad and can result in illegal memory accesses.