3D Questions

[Lokiem]

Hey guys, sorry if I'm posting in the wrong area or any such rookie mistake.

I've recently begun to fiddle arond with programming on the Nintendo DS, I've got the background skills of C++, C, OpenGL, and general theory of programming in 3D. But I've hit a snag, which I don't really know my way around, I can only assume I'm making a mistake.

To keep it simple, I used the example that already exists in the NDS examples folder (devkitPro\examples\nds\Graphics\3D\Display_List_2), however replacing that teapot, with any other model converted to a .bin using a tool aptly named NDSModelExporter (which converts .3ds, .x, .mesh, and so forth into the .bin type used by the NDS) results in losing all the lighting effects.

The code itself, remains unchanged. To show what I mean, here are two images, the example as it comes, and then the example with the .bin as the only thing changed:

http://i50.tinypic.com/nns3o2.jpg
http://i45.tinypic.com/23r5m3q.jpg (It's an icosahedron, made in 3ds converted to .bin, I imagine similar to what was done with the teapot.bin)

It has to be the .bin, but I've not come across any other tool to convert to .bin, and short of opening up the .X file to shred out the mesh data, I'm stuck.

What exactly is going wrong? Could any of you point me in the direction, or be so kind as to offer an example of a loaded, 3d model, lit?

Edit: To expand on the problem, the conversion tool provides a 'normal flip' option, which I have tested both on and off, and both appear the same as the above model. I've also tried some of the DirectX sample files, such as Tiny, models that have correct lighting in the DirectX Model Viewer. I can't help but think the conversion tool is broken.

[zeromus]

Looks like that tool creates display lists which contain a color set for every vert, probably the ambient from the original model. It is a bit inefficient regardless. here's a triangle from the exporter:

3D command 0x40: BEGIN_VTXS(00000000) (FIFO size 172)
3D command 0x21: NORMAL(00079800) (FIFO size 171)
3D command 0x20: COLOR(000066D2) (FIFO size 170)
3D command 0x22: TEXCOORD(0141010D) (FIFO size 169)
3D command 0x23: VTX_16(014CF9D3) (FIFO size 168)
3D command 0x23: VTX_16(0000FAE4) (FIFO size 167)
3D command 0x21: NORMAL(00079800) (FIFO size 166)
3D command 0x20: COLOR(000066D2) (FIFO size 165)
3D command 0x22: TEXCOORD(0129010A) (FIFO size 164)
3D command 0x23: VTX_16(014CF99C) (FIFO size 163)
3D command 0x23: VTX_16(0000FC9A) (FIFO size 162)
3D command 0x21: NORMAL(00079800) (FIFO size 161)
3D command 0x20: COLOR(000066D2) (FIFO size 160)
3D command 0x22: TEXCOORD(0129010D) (FIFO size 159)
3D command 0x23: VTX_16(014CF9D3) (FIFO size 158)
3D command 0x23: VTX_16(0000FC9A) (FIFO size 157)

Note the color after every normal command. This overwrites the color produced by the lighting model set by the geometry engine upon processing of the normal command.

Here's the teapot:

3D command 0x40: BEGIN_VTXS(00000002) (FIFO size 179)
3D command 0x22: TEXCOORD(01F801CE) (FIFO size 178)
3D command 0x21: NORMAL(2A5BA704) (FIFO size 177)
3D command 0x23: VTX_16(0DFFFE14) (FIFO size 176)
3D command 0x23: VTX_16(0000FF85) (FIFO size 175)
3D command 0x27: VTX_YZ(FF850DFF) (FIFO size 174)
3D command 0x22: TEXCOORD(01EB01E2) (FIFO size 173)
3D command 0x21: NORMAL(22B21F68) (FIFO size 172)
3D command 0x28: VTX_DIFF(330368C5) (FIFO size 171)

no color commands. Also this was exported by some different tool I would imagine due to the more clever use of vertex commands. I have no idea which tool.

That java program just shells out to NDS_Mesh_Converter.exe. You could modify that (source code is available) not to export vert colors which would be easy. But youd be better off finding a better tool.

[Lokiem]

Hey, thanks for the reply, I'll see about modifying the code to begin with.

Could I just ask how you got that information? It'd be handy with 3D debugging.

[zeromus]

printfs from desmume

[zeromus]

http://dl.dropbox.com/u/4260750/temp/ND ... verter.zip (this file may expire at any time)

this puts the color before the normal. i'm don't have time to study it further right now, but it may make sense to set color and then normal, considering the behaviour of bit15 of diffuse/ambient. Its behaviour seems a little confusing to me, I need to write a test case. At any rate, in normal circumstances, the color will get ignored and the subsequent normal command will get used to set the color according to the lighting engine, as you want.

please note: the teapot display list sets its own material properties, so the display_list_2 demo doesnt do that. if you export your own models using this tool, youll have to set material properties in your code, otherwise it will be black and reflect nothing.