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 > VTX_16 vs VTX_10 vs VTX_XY/VTX_ZX/VTX_YZ vs VTX_DIFF

#147927 - kusma - Sun Dec 30, 2007 6:04 pm

Okay, I'm trying to understand a bit about the DS 3D hardware, and especially the vertex specification. Currently, I'm wondering what the real difference between the different ways of specifying vertices are. I assume the best result is given by combining the methods.

Here's my current observations:
  • VTX_16: Full precision and range. The biggest and most flexible vertex format in terms of range, precision and usage. Requires 64 bits to specify, where 16bits are used for padding.
  • VTX_10: Low precision, low range. Smaller and less accurate version of VTX_16. Fits in a 32bit word, where only two bits are used for padding.
  • VTX_XY/VTX_ZX/VTX_YZ: Full precision and range, and no padding. But the same 32-bit word is used for two vertex positions.
  • VTX_DIFF: Medium precision, medium range. A bit more tricky to encode than the other methods.

Now, here's my questions:
  • Is there a limit to the memory used for specifying vertex data? What prevents me from just using VTX_16 for everything? The gfx-fifo is in main RAM anyway, and I have "plenty" of that (compared to VRAM) ;)
  • How big of an impact does vertex-data bandwidth usage have on performance of the geometry processor / the system as a whole?
  • Can normals, texture coordinates and/or colors be changed between a pair of vertices specified in a VTX_XY/VTX_ZX/VTX_YZ format?
  • Can integer wrap-around in the VTX_DIFF-format be "abused" to take long "leaps" to the other side of the coordinate system?

I've searched GBATek, but I can't really find much info on this subject.

#147944 - M3d10n - Sun Dec 30, 2007 10:16 pm

I can help only with the two first questions:

Quote:
# Is there a limit to the memory used for specifying vertex data? What prevents me from just using VTX_16 for everything? The gfx-fifo is in main RAM anyway, and I have "plenty" of that (compared to VRAM) ;)


I was using VTX _16 for everything until just now. No issues on a 4K triangles scene (characters+level). I don't think the FIFO would have any problems even if you filled all your RAM with geometry, other than the DS missing a frame or two before it could clip all of it.

Quote:

# How big of an impact does vertex-data bandwidth usage have on performance of the geometry processor / the system as a whole?


I modified me model converter to use VTX_10 for everything. Reduced the display list files' sizes by 20% but barely registered a change on my profiler (getting rid of redundant color/normal commands helped much more).

But it impressed me that my prototype still looks the same with the lower precision. I can't notice any artifacts or displaced vertex due to the lower precision anywhere, even on characters' fine details (but I'm normalizing all my meshes' vertices, so that might get around the lower precision coordinates). 20% less RAM usage with no visual glitches? Deal.

Never used the offset and paired formats, so can't help with those.

#147946 - kusma - Sun Dec 30, 2007 10:30 pm

Thanks a lot. Since none of the other formats have smaller foot-print than VTX10, I guess there's no big need to optimize any further. I can probably use VTX10 for most meshes anyway.

#147947 - DekuTree64 - Sun Dec 30, 2007 11:07 pm

Yeah, RAM usage is probably the biggest advantage. But it does help speed a little bit, since the CPU or DMA has one less word to copy.

For character models, 10 bits should be more than enough to look good on a 256x192 pixel screen. But when you start getting into large scene models, 1024 steps isn't that much. But then all the vertices in a triangle/quad should be close together, so VTX_DIFF works nicely. Especially with strips.

XY/XZ/YZ seem a bit less useful to me, but I guess they would make heightmap rendering faster since you're only packing 2 coordinates together instead of the 3 for a diff, plus you can just plug in the Y coordinate from the heightmap directly instead of subtracting the previous vertex's Y.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku

#159014 - a128 - Tue Jun 24, 2008 9:58 am

DekuTree64 wrote:


XY/XZ/YZ seem a bit less useful to me,


it's very usefull

draw a box and you have a lot of same X or Y or Z values

#159015 - kusma - Tue Jun 24, 2008 10:12 am

a128 wrote:

it's very usefull

draw a box and you have a lot of same X or Y or Z values


Good point. I recon it should be possible to design indoor-levels so that most polygon lies in the x, y or z planes without everything looking crap.

#159020 - a128 - Tue Jun 24, 2008 11:26 am

Here is a tool I use in my current projects

It converts ac3d *.ac 3d scenes into displaylists (incl. textures and many more)

Check the readme for more details

it uses XY/XZ/YZ for triangles/quads if possible (only checked for one primitive)

http://www.freewebtown.com/festival2005/ac2nds.tgz

#159022 - kusma - Tue Jun 24, 2008 12:20 pm

Cool. Personally, I've already made my own Collada-converter that does a lot of similar optimizations, so I doubt I'll look much into it. But it might be very usefull for other people :)

#159025 - a128 - Tue Jun 24, 2008 1:10 pm

kusma wrote:
Cool. Personally, I've already made my own Collada-converter that does a lot of similar optimizations, so I doubt I'll look much into it. But it might be very usefull for other people :)


Release it..if you like. Sharing informations is great!

#159029 - a128 - Tue Jun 24, 2008 2:35 pm

kusma wrote:

[*]VTX_XY/VTX_ZX/VTX_YZ: Full precision and range, and no padding. But the same 32-bit word is used for two vertex positions.
[/list]

VTX_XY/VTX_ZX/VTX_YZ needs VTX_16 as a first VTX command because of the resolution, VTX_10 does not work for the first VTX command

#159033 - naleksiev - Tue Jun 24, 2008 5:14 pm

Offtopic

kusma wrote:
Cool. Personally, I've already made my own Collada-converter that does a lot of similar optimizations, so I doubt I'll look much into it. But it might be very usefull for other people :)


I'm a huge fan of XML and I do have quite some experience with it. I start making a COLLADA converter about 2 months ago. There are a lot of things I particularly didn't like in the COLLADA specification. Anyway I struggled with it for some time until I found that there is something that doesn't make sense in the specification. I believe it was in the Joint node but I'm not 100% sure anymore. First I found that two different COLLADA exporters are exporting the ID of the joints using different attributes (as I said I'm not 100% sure it was the joint). One is using ID and one SID. I found out that the one in the specification was SID and when I thought about it for a second I found out that it doesn't suppose to be SID but ID.
Too bad that something generic that suppose to have exporter in every 3D editor doesn't do the job right. For now I just made my own simple Maya to XML exporter in MEL and then I'm compiling it to Binary.