#85286 - jdxpolygon - Sun May 28, 2006 6:14 pm
Hi
I was wondering, does the Nintendo DS generate its textured polygons with the correct perspective? I don't know if that's the right word to use, but what I mean is, if I had a single long quad that stretched from the foreground into the background, with some repeating texture pattern on it, would the scale of the texture diminish with the geometry, or would it warp, kind of like on the PS1? My initial thought was that there'd probably be no perspective texturing, mainly because other basic texture enhancements like filtering aren't present either, but now I'm not sure. I'd probably be able to see for myself if I had a DS, but I'm holding off until the new model comes out in a month or so.
I started wondering this after looking for information on whether or not repeating textures can be used on a single polygon like on a regular graphic accelerator (I thought maybe things would be more limited on the DS). I expected for some reason that this would also not be possible due to the type of numbers used to specify TC's (I think I presumed it to be 4:12 like vertices), but I read somewhere that it can be done - Admittedly I haven't gotten onto reading a lot about TC's on the DS. I suppose both questions are related in that either function not being present would increase the number of polygons required to render certain things, whether it's to repeat a pattern or to reduce texture warping.
I'd appreciate any info that could be offered on this subject. Thanks for your time.
J
#85290 - gladius - Sun May 28, 2006 6:55 pm
What you are looking for is called perspective correct texture mapping. The DS uses affine texture mapping, which is much faster, but less accurate. Perspective correct mapping requires a division per scanline, and a multiply per pixel extra generally.
The DS texturing looks similar to the PS, where the texture appears to "swim" when put in a scenario like you mention. One way around this is to tesselate the ground plane more heavily. Or avoiding polygons that stretch for long distances in the z plane.
#85307 - jdxpolygon - Sun May 28, 2006 9:19 pm
Thanks for the info. This was pretty much what I was expecting, although I hoped it wasn't the case. At least, from what I've heard, the DS doesn't create as many gaps as the PS1's GPU did when tesselating - that was always really visible to me, even before I understood exactly what was happening and why.
Did the N64 have perspective correct? And this is a bit tangential to the subject, but any idea if the PS2, when running a PS1 game, adds perspective correct texturing to the game retrospectively?
#85314 - Payk - Sun May 28, 2006 10:25 pm
hmhm gladius...i got same gap problem like most poeple have.
So i render about 13x13 smaller planes which become a ground (with different heights). So i have 4 textures i use there. each of it holds 16 textures. Bit strange but makes sence...but later
1. texture includes some ground plates...grass , marmor...dunno
the other 3 are autotilesets.
Each planepart has same size in that ground.
The interesssting thing is that the gaps appear on those parts of grounds where the different textures are used. So if i only use texture parts of 1. set there are no gaps. when i add a autotiled gras to it they appear on their borders...
on the size i use, u can imagen that they arent streched trough the z axis.
And most strange thing is, when i just scale that plates larger in order to let them overlap, i get shitty graphics + gaps. they dont dissapear....realy strange things. I tought about adding all ground textures to one texture to avoid it. But that would cause that i cant use 8bit because pals are to small. Result would be one texture-vram bank for grounds ...if i use autotiles or not....hmhmh not very cool...
#85329 - gladius - Mon May 29, 2006 2:11 am
Gaps between polyons (that are not texture mapped) is caused by lack of precision in the transformation calculations. From what I've seen the DS is pretty good about this.
The N64 did have perspective correct texture mapping, and yes, the PS2 does have an option to add perspective correct mapping to PS1 titles.
Payk: Your scenario sounds like the polygons are wrapping before the edge of the polygon because of lack of precision. The solution of using one texture is probably the easiest way to fix it. You could try adjusting the u,v co-ordinates of the polygon and see what happens (add some correction factor for the z-difference between the min/max of the polygon).
#85337 - DekuTree64 - Mon May 29, 2006 3:29 am
| gladius wrote: |
| What you are looking for is called perspective correct texture mapping. The DS uses affine texture mapping, which is much faster, but less accurate. |
Really? It looks perspective correct to me. It does seem unusual that textures don't hurt the fill rate if it is doing a divide per pixel though. Can you find any specific examples in games (or homebrew demos) of where affine warping is visible?
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#85344 - gladius - Mon May 29, 2006 5:15 am
You know, I think you are right Deku. For some reason I believed that the DS used affine texture mapping, but playing around with it some more it appears to not to.
I think my eyes are just too used to trilinear filtered pixels to remember the bad old days of affine :). All the cases of texture warping I see can be explained by the lack of bilinear filtering. One of the examples I checked out was the first track in mario kart ds (in gp mode) and the way the checkered stripe along the edge of the track bent out of line and snapped back into place if you looked at it right. This can be explained by lack of filtering also though.
And you don't need a divide per pixel, if you interpolate 1/z across the polygon you only need two multiplies to get the correct u&z values. You do need a divide extra per span though.
Sorry about that jdxpolygon.
#85359 - Payk - Mon May 29, 2006 10:38 am
Thanx gladius for hind i will try when i come back from "vacation" (some kind of journey with class). Its interessting Topic about those texture mapping things and i have never heared of those methods ps1 n64 and the rest are using...I should read a bit about that when i come back.
Again thanx gladius.
#85381 - silent_code - Mon May 29, 2006 5:16 pm
from what i read there seems to be either perspective correct mapping with low res coordinates or just no pcm... whenever textures bend it is a hint for not having pcm. i have no nds myself, so i can't check it out... :(
an example: you have a quad that's rendered with two triangles. if you draw it quite in front of the near plane and rotate it AND the textures on the tri that's closer to the near plane starts to whobble and strech and bend, then there's some non pcm going on. this usually happens when you draw big triangles that fill a big portion of the screen space. again, i haven't checked that out on the nds, it's just a way to find out when the texture mapping process yields odd results. knowing that you can think of solutions to bypass that behaviour.
i think i'll get a look at some homebrew demos and look for myself (i don't know if the emularots resemble the hardwares behaviour in that case, though!)
...
ok, i have tested the drunkencoders texture demo and drawing the low res cylinder and rotating it, i couldn't find any texture warping etc. i guess the nds' gpu has more or less (i tend to saying more) the same funcionality as the n64s but without the filtering. having only nearest neighbour filtering and no mipmapping (haven't seen any use of hardware mipmapping, though i think it might be doable by hand - one had to try) the image looks a bit jumpy (instantly changing pixel colors - like when the dominant pixel of a 128x128 mappes character renderered to a 2x2 quad changes) when it comes to wide open scenes. but in low to low mid visibility scenes there should be no problem.
as a result i think the nds' gpu is doing pcm and the only issue is precision with very small triangles drawn very close to the near plane (so they take up a low of screen space - that will exaggerate the low res coordinates).
hope i'm not too wrong and it helps you :)
greets!
Rob
#85528 - M3d10n - Wed May 31, 2006 11:45 am
The DS has a few precision issues when things are too big or too small, but perspective correction is surely there, otherwise it would be impratical to use tiling textures across a single polygon.
Check this screen:
http://media.ds.ign.com/media/682/682877/img_3191298.html
#85531 - jdxpolygon - Wed May 31, 2006 12:23 pm
That seems to be a good example of perspective correct texturing in action, provided you can be sure it is in fact a road built from one quad. You can see the difference in size of the projected texels over quite a short distance though, so looks like it is perspective correct and not just well tesselated.
#85865 - Payk - Fri Jun 02, 2006 7:38 pm
Ok thoose grounds are gapfree and i agree that it could be one quad (its seems like). But when they would make a terrain...and i know that mariokart has hills... Hmhmh nds uses some kind of a render list i think....
(trianglelist or something). So that 2 ground types i use only have that gaps between each other...if they are same type they dont have.
The renderscene goes like
-----------------
//ground1 (for single grounds without borders)
for(a=0;a<13x13;a++)
//ground2 (autotiles for sand snow gras)
for(a=0;a<13x13;a++)
-----------------
So that lets me think that when i make that all just with one texturebind and all in one glbegin glend part....the gaps could disapear...
There is one thing which also "forces" me to think so:
my md2 dont has any gaps. just one glbind one glbegin...
i zoomed in. it realy seems to be gapless...
So i would say nds has some kind of a correction but result depends on the order of trianglelist (not sure but i will make some tests this weekend)
#86854 - Payk - Fri Jun 09, 2006 10:59 pm
Ahh u all know these nds examples.
There they often use vertexpos 0 as an int. all others they use f32 or v16 v16tofloat or something. try to replace the 0 with an v16 valued zero. then u will have just half of those gaps left...(it was for me like that....dont understand why but it was like that)
so just like v16tofloat(.0) instead just 0. try that out and notify me please.