gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS development > DS 3d graphics questions

#63063 - hawken - Thu Dec 08, 2005 11:40 am

Hiya guys and gals

I run a little modelling challenge over at http://boards.polycount.net every week or month and we are increasingly starting to make 3d models restricted by DS and PSP specs.

I was wondering if you guys could help me out on a wee question or two? (as I've scoured the internet and can't find anything)

(1) - DS can draw 2000 polygons per screen at 60 fps, does 4000 polies at 30fps look any good?

(2) - what is the max texture sheet size? (PSP is a reported 128px x 128px)

(3) - what is the total texture memory allocation? IE: how many textures can I display per screen.

(4) - in your estimate, how many polygons does the average Mario Kart DS track use? Considering the tracks are never drawn in thier entirety. Bonus question: Can anyone guesstimate the average specs of the characters in mario cart (polygons + texture)

Thanks for your time!

(if anyone ever needs any 3d models for messing about with...)
_________________
hawken.dadako

#63070 - Webez - Thu Dec 08, 2005 12:36 pm

Hi.

I'll try to answer as far as I can

1) DS can draw 2000 but I doubt it can be done at 60 fps

2) I have tried 256x256 textures and they work ok but libnds let you use 1024x1024 textures

3) I think the max memory allocation for textures is 512 KB

4) I don't know how much polygons they use in karts but if in a race there are 8 models and a circuit and ds can only draw 2000 polygons....

This is a demo I have done for loading md2 models directly (without display lists). Only 2 models can be drawn at the same time (the third one is cut). It uses a 256x256 texture and you can change interpolation (SELECT/START) , animation fps (less is more X/Y) and animation (A/B). Elapsed frames is the number of frames that has passed since last loop (frames are increased in vblanks).I hope it helps you.


http://www.4shared.com/file/571555/2882d4b/md2.html

#63073 - hawken - Thu Dec 08, 2005 1:17 pm

Hey thanks for the swift reply! The texture info is really usefull.

I'm guessing the tracks in mariocart are way more than 2000 polygons, although they must be cleverly made because there's virtually no "popup" at all.
_________________
hawken.dadako

#63075 - M3d10n - Thu Dec 08, 2005 2:25 pm

The polycount in MKDS tracks are probably defined by curve segments.

When the developers designed the tracks, they could know, beforehand, how far into it one could see from each point. The player can only see objects until the next curve, so it's possible to calculate an average polycount for each track segment.

There's also the possibility that they optimized the game to switch/update display lists between scanlines. The 2000 (2048) polygon count isn't based on speed/fillrate, like on normal GPUs where you can happily throw more polygons than it can handle and it'll just slow down. If you throw more than 2K polygons to the DS GPU, it'll now slowdown - it'll simply not render them.

That limit is there because the DS sorta renders the polygons like sprites, on the fly per scanline. That's the size of the polygon register/buffer/something. The GPU reads that every scanline, and renders the polygons to a 256x1 buffer, that is then sent to the LCD memory.

It's said to be possible to empty and load new polygons into the buffer mid-render. Maybe MKDS (and some other games) do this. I can see this working on MK, since the camera does have some restrictions, even when it appears it doesn't. As example, if the camera is always a bit highg and looking a bit down, the objects far away into the track will be in different scanlines than the racers and the track itself.

It's also said to be possible to make the LCD "hold" it's image and draw more polygons on top of it into two or more passes. You woudln't be able to do any Z-buffer tests against the previous content, though, since the LCD memory only stores colors, not Z-values. So you'd need to "split" your scene into "far" and "near" slices and render the "far" first and the "near" later.

#63109 - crossraleigh - Thu Dec 08, 2005 6:49 pm

My understanding is that the limit of 6144 vertices (in other words, 1536 quads or 2048 tris) applies after culling. See the BoxTest demo.
_________________
My world is black and white, but if I blink fast enough, I see it in grayscale.

#63115 - hawken - Thu Dec 08, 2005 7:05 pm

after culling?

I've not got the gubbins to link roms to the DS, just interested in making "DS ready" models as it were.
_________________
hawken.dadako

#63116 - Webez - Thu Dec 08, 2005 8:05 pm

The only thing you need to know is the limit is 2048 triangles. What you do for culling or oclusion is another topic . I think models should be under 400 triangles if you want to have some models at the same time and a decent level. I think the level has less problems with this vertex limit beacuse there are a lot of ways to draw only what is visible. But if you make models too complex then you will be more limited in other areas. Look at nintendogs. They need to use fog even in the house and I think that it is because of the detail of the dog

#63119 - ector - Thu Dec 08, 2005 8:40 pm

PSP can do 512x512 though it's not really practical because it would eat too much memory. The fastest texture format on PSP is 4-bit paletted, although 8-bit paletted is not far behind.

#63198 - hawken - Fri Dec 09, 2005 5:48 pm

thats quite interesting about the PSP texture size. I've heard it's 128x128. With no real clear info for hobby artists I've setup a page on the same forum to try and set some guidelines:

http://boards.polycount.net/showflat.php?Cat=0&Number=87756&an=0&page=0#87756
_________________
hawken.dadako

#63336 - Marill - Mon Dec 12, 2005 2:49 am

Depending on which VRAM blocks A/B/C/D you use for tex memory, that's your limit. each block is 128KB, if you use all 4, then you have 512KB.

#63484 - hawken - Tue Dec 13, 2005 3:43 pm

heres my final specs to help those starting out:

suggested polygon count for performance (total visible): 2000
texture memory (per screen): 512kb
max texture size: 1024px x 1024px
screen colour depth: 18-bit (260,000 colours)
3d data format: (custom exporters)
texture format: TGA, NNS Targas
alpha blending: 5-bit? (32 colours)
suggested texture size: under 128, 64, 32 etc
_________________
hawken.dadako

#64159 - LunarCrisis - Mon Dec 19, 2005 10:14 pm

Kinda unorganized but whatever:
It's important to note that you can only display 2048 _triangles_, each quad is worth 4/3 triangles, so for example if you display only quads you can only show 1536. Also the smallest texture format is 2 bit paletted. The screen colour depth is 15 bits, 5 for each channel. 5-bit alpha is only available for 8-colour textures (bringing the size up to 1 byte per pixel) and 3-bit alpha is available for 32-colour textures (once again 1 byte per pixel). Only 1-bit alpha is available for all other texture formats as far as I can recall. Also, texture filtering is rumoured to be available, but noone has managed to enable it, and I don't know of any commercial games that use it. For texture palette storage you have two options, you can store them in a 16k bank or a 64k bank. each colour takes 2 bytes, so in the 64k bank you would have room for 128 256-colour palettes, 2048 16-colour palettes, etc., more than enough room.
_________________
If a tree falls in the forest and no one is there to hear it, why the heck do you care?

#64173 - bluescrn - Tue Dec 20, 2005 12:09 am

LunarCrisis wrote:
Also, texture filtering is rumoured to be available, but noone has managed to enable it, and I don't know of any commercial games that use it.


I think I can safely say 'that's bollocks'... maybe just wishful thinking?...

If texture filtering was possible, we'd have seen it by now, if only on a title screen or minigame. The only way you'll see texture filtering on a DS is if you're using a software renderer. And then it won't be fast...

I'm rather starting to quite like the DS style of 3D, though - might not be as clean-looking as the PSP, but a decent step above PS1, and it's got character. And the hardware really does encourage 60fps games, something that's quite rare on any other console these days....

#64199 - Darkflame - Tue Dec 20, 2005 5:31 am

hmm..Do you think the Ds probably has large texture sizes compared to the PSP because of Nintendo heritage with Mode7 style effects?

As for filtering...yeah..seems very wishfull.
Nintendo *could* have locked or hidden a function to improve battary life (much like Sonys reduced clockspeed).
But it would have been found out by now.

That said, I suspect we will get Filtering near the end of the DS's life.
Much like the 3D games that appeared on the GBA near the end.
(Asterix & Payback being extream examples of what you can do if your not worried about 15fps. Actualy good games though

#64259 - M3d10n - Tue Dec 20, 2005 6:16 pm

Ah, if hacking in new features on hardware 3D renders were as easy as writing full software renders from the ground up...

Bilinear filtering, when it's avaliable in the hardware, is so lightweight it's virtually free, but it is usually a very expensive operation in software renderers (something to do with reading and alpha-blending 4 texels per fragment, when you only need to read one texel for point sampling).

The closest thing to BF in commercial software renderers that runs at pratical speeds is the Unreal engine dither filtering, that jitters the texture coordinates for each fragment using a diffuse dither table when the texels become big enough, "meshing" the textures pixels when they zoom into the screen.

I doubt that is doable in the DS 3D hardware, unless it featured some sort of primitive fragment program support. It could be implemetend in a SW render, but the final performance is a mistery until someone goes ahead and try it (since the GBA does some rather interesting SW 3D at 12MHz, I suppose the DS could do much better at 67MHz).

#64270 - Darkflame - Tue Dec 20, 2005 8:06 pm

Software 3D would be interesting.
Theres already a VOXAL game out with an apperently good engine (see IGN).

As for texture filtering maybe you could have a secondary pass with a semi-transparent layer with filtering?

Like a Software3D/Hardware3D hybred? Software only applies filtering where its absolutely needed.

My knowledge is limited, so I am probably talking nonsense.

#64434 - M3d10n - Thu Dec 22, 2005 12:10 pm

That brings me a question... does the DS support multi-texturing (rendering two -or more- texture layers blended against each other on a given polygon in a single pass)?

I haven't read all of the docs nor looked enough in the DSLib code to make sure, but some effects in some games makes me wonder about this. The specular/environment map effects in Nanostray (that look additively blended agianst the base texture), the alpha-blended texture transitions in some Mario Kart DS tracks (textures smoothly blends into different ones along some polygons, from sand to dirt as example), and the cloud shadows in FIFA 2006 (but that might be just a big alpha-blended polygon over the field...).

The Nanostray effect puzzles me more, because the game runs at 60fps and there's clearly no room for multi-pass rendering there.

If it does support multitexturing, it's possible to lessen the pixelation by applying the same texture to two texture layers, make the 2nd layer 50% alpha blended and offset it's UVs by a value that correponds to half-texel. That will apply a primitive blur to the texture, and while it will still look pixelated, the resulting image will have texels 50% smaller. Front Mission 3 on the PSOne used this trick on polygons close to the screen, and it did make the textures look slight more soft upon close up..

#64471 - LunarCrisis - Thu Dec 22, 2005 7:17 pm

M3d10n wrote:
The specular/environment map effects in Nanostray (that look additively blended agianst the base texture), the alpha-blended texture transitions in some Mario Kart DS tracks (textures smoothly blends into different ones along some polygons, from sand to dirt as example), and the cloud shadows in FIFA 2006 (but that might be just a big alpha-blended polygon over the field...).

I haven't played Nanostray, but couldn't a sort of multitexturing be applied by drawing the ships twice in the same frame, but have the second one (the one with the environment map in this case) offset a little bit towards the camera? In games like Mario Kart they often do have a very large number of transition texures pre-made, so they will have several choices whenever they go from one terrain type to the other.
_________________
If a tree falls in the forest and no one is there to hear it, why the heck do you care?