Page 1 of 1

Near clipping plane

Posted: December 11th, 2016, 8:02 am
by Misscelan
Hi there,

I'm trying to render a custom model using gte.
There is a severe clipping on near polys, I guess some of it could be solved with poly subdivision but I have also read that gte_rtps (the one I'm using) Z values are limited downwards at 0.5 * view plane distance. Is there any alternative to rtps without that restriction? Or any other alternatives to near poly clipping different than subdivision?

Thanks!

Re: Near clipping plane

Posted: December 11th, 2016, 2:52 pm
by LameGuy64
Hardcore PlayStation graphics programmer here, I can't really find much info in regards to Z values being limited to what you've described but I do know that the GTE would saturate the resulting 2D coordinates when a Z value near-clips as a cheap but crude way for tolerating near-clips if you ignore the result in the flag control register as it will return a negative value when a vector passes near-clip.

If you're working with triangle strips, try using gte_rtpt(). It's similar to gte_rtps() but processes 3 vectors at once. Use gte_ldv3() to load 3 vectors to the GTE at once and gte_stsxy3() to store the 3 2D coordinate results to memory.

Re: Near clipping plane

Posted: December 12th, 2016, 3:35 am
by Misscelan
Thanks for the info!

The rtps info about the Z value I found it in the "All the things you wanted to know about psx but were afraid to ask" pdf.
There is some info for all the gte commands, there it reads that if you want to retrieve smaller z values you will have to implement your own function.

This issue seems to happen in all the psyq examples but one- ZIMEN tuto4, unfortunately the code for tuto4 is not available :(. But I assume subdivision works well with that particular geometry only.

Before, trying to do some subdivision with gte, I tried to see if using normal functions RotAverageNclip3 and DivideFT3 would get the results I wanted.
But then I came across with an example on the psyq sdk that reads the following:
"The Divide function judges normal clipping only once before division.
This means that large polygons that have approached a viewpoint are
all clipped prior to divison. This can produce situations where a
section which is expected to be drawn is not. To prevent this from
happening, use the RCpoly function instead of the Divide function as
shown below."

Then I used some assembler code for subdivision that I got from one of the examples, it seems to "work", the problem with subdivision is that, at least on my case, you don't have much room selecting where in the z distance you want to start and how many divisions because soon it either starts lagging or simply goes bananas.
So in my case, subdivision doesn't really helps much with clipping.

The model I'm using has some large polys in some areas and probably that's making the near clipping problems worse, but it bugs me a bit that none of the examples really tackles this issue in a general way, and I've seen many graphical problems in psx games, but none having near clipping problems.
This leads me to think that the solution might not be too difficult or that I'm simple doing something wrong with my code.

EDIT:
Browsing the ref docs for some info I found out:

There is a bit that can be set for TMD objects using GsDOBJ2 to ignore that.
"Bit 7: Near clipping
If this bit is set, in cases where the polygon end point is very close to the viewpoint (distance between
viewpoint and polygon < (distance between viewpoint and screen) /2), a polygon that has overflowed
during perspective transformation will not be simply clipped, but can be forcibly displayed, even if its
shape is distorted."

Also, most of the RotPMD, RotRMD,SMD, etc.. functions include an attribute nclipmode that also controls that:

"If nclipmode = 0, polygons are far and near clipped by sz=[0,2^16].
If nclipmode = 1, polygons are far and near clipped by sz=[h,2^16] (h=distance of eye to screen)."

But I cannot find any similar settings for custom models render with gte_ instructions :(