Questions about Perspective Divide + Z-Clipping

[kazade]

I'm working on the last major piece in my new GL implementation which is near-Z clipping, and I could use a bit more understanding about perspective division, and the Dreamcast coordinate system.

I'm looking at the coordinates generated by libGL after perspective division. What I'd expect is that the Z coordinates would be normalized between 0 and 1, with 1 being at the far plane and 0 being at the near plane (like this: https://stackoverflow.com/a/25587175/48362), although what I'm actually seeing is the reverse, 1.0 is the near plane and 0 at the far plane (maybe I'm wrong... but that's how it appears)

So first question, when working directly with the pvr and sending stuff via store queues, what's the final coordinate system?

The next question is about near-z clipping. I'm trying to define an algorithm to do this while minimizing copies, and I'm wondering why libGL performs clipping before the perspective divide? Is it just to avoid dividing on vertices that might never be seen or is there some other reason?

[111]

iirc Z-coordinate ranges from 0 to whatever positive value you want. Vertices with negative Z (<= 0 to be exact) are automatically discarded by hardware. So yes, as you said, libGL performs clipping before the perspective divide to avoid dividing on vertices that might never be seen.
Y-coordinate starts at top-left corner, so positive Y goes down.

It's been a long while, so maybe I remember it wrong. The best way to to test this is to try rendering triangles without any transformations (that's what I did in the first place anyway)


also, I find older\original libgl kinda easier to understand (in fact, I just copypasted it's near z clipping to my custom 3d engine lol). To avoid problems with clipping for modifier volumes (as described here), I did a cheap trick: instead of discarding vertices with Z < near_z, I just placed them at near_z (or something like that), so meshes are kinda "scaled" against "camera" (as long as at least one vertex is in front of "camera"). As dirty as it is, it's definetily faster (and easier) than generating capping polygons.

[kazade]

Thanks! Glad to see you back 111

I'll do some playing around, but if anyone else stumbles on this topic this is the best explanation of perspective division that I've found: http://www.learnopengles.com/tag/perspective-divide/

[111]

Well, I don't think I'll ever come back to dreamcast programming (just hanging around here and there sometimes), but you are welcome.

Also, regarding this thread, keep in mind that this fix is somewhat incomplete, unfortunately (although I don't remember exactly in which cases and what exactly was wrong). And as if that was not enough, it did not take too long after that before I encountered other weird glitches (parts of my models randomly dissappear etc.) for no apparent reason (and it seems I was not the only one here). That (and many more issues, not only related to graphics) was enough for me to finally give up with KOS and move on.

One more advice: do something "serious" for testing (like "stress tests" (rendering many high poly meshes) or rendering some game maps with many textures etc), not just "rotating cubes" or something like that. It's almost a quaranteed way to face some serious KOS\PVR limits\bugs (and if that is not enough, you can certainly add some sounds and bgm playback (which is a different story))


... but good luck anyway.


PS: it's definetily possible to fix many (if not all) KOS\PVR issues. "DCDBSysArc990907E.pdf" is the place to start, in case anyone feels like doing this.

[kazade]

Yeah FWIW your complaints about libGL influenced my decision to write a new one. Mine focuses on memory usage and correctness over performance (for now). Hopefully I can solve these issues there. Maybe.

[111]

^
To be honest, memory usage is the only notable flaw of libGL (performance is alright. Not good enough for a serious project, but not that bad either). Few glitches aside (it is not hard to come up with workarounds in most cases), it is actually very well made (considering it is built on top of KOS' pvr api, which is not complete, to say the least), so PH3NOM did a great job there.

Problem is, even if you manage to fix some of the issues, you can't possibly achieve decent performance without in-depth knowledge of dreamcast hardware (store queues are nice and all, but that's not enough). Official SDKs not only hide all the complexity from you (especially with Ninja library), but they are also (obviously) designed to make best use of the hardware and "just work" as you expect (I did some simple benchmarks, as I said here). I would even argue that Dreamcast was already "pushed to it's limits" (thanks to SEGA's excellent tools), so games like PSO, SA2, Shenmue etc. are the best possible on that hardware.

PS: viewtopic.php?p=1054706#p1054706

The most relevant thing I've learned from that, from a gamedev perspective, is to never try to create a complete game using unfinished and unpolished tech.

I wholeheartedly agree.