#### Archived

This topic is now archived and is closed to further replies.

# NMB file format problem

## Recommended Posts

Hi all, I am currently reverse engineering the NMB file format used for NVidia''s Dawn demo (just for fun project...). So far things have gone pretty smooth and I am pretty much ready to display some geometry: I read the whole file, cut it into chunks, I know where the geometry is to be found, topology information etc. I just have a problem interpreting some vectors. The format stores positions, normals, tangents, texcoords etc. in separate chunks on a per-object set. So, for each object you get positions, normals, etc. sparately. Positions don''t seem to be a problem so far, they are stored as simple float[3] vectors. Unfortunately normals and tangents are stored in what seems to be float[2] packets. So I am wondering how to interpret those values. Since we operate in R3 here I expected to find float[3] for those as well. My current guess is that they use some sort of vector compression using some quantization method since that''s not really uncommon for unit vectors. I exclude the idea that those are texture coordinates for a normal map since some values are negative. The idea of compressed vectors is also supported by the fact that the new NMB format v2.0 also supports that method. However in that case quantization values are also stored in the file which I can''t find in the Dawn file. And in v2.0 they simply store the vectors in signed WORD values probably using a range of -32K to +32K to represent -1 to +1 as float value. However that would make 6 bytes per Vec3 which is not found in the Dawn file as well. There we have 8 bytes per vector which I know for sure since the vector count is specified and the chunk ends exactly at the expected position. For clarification I add a short part of the ASCII dump I made from such a Normal-Chunk:
        -0.000002          0.000000         0xB6093B47         0x00003162
-0.000000          0.000000         0x94303BFF         0x00009865
-0.000000          0.000000         0x91243BFF         0x000097FB
-0.000001          0.000000         0xB5443B83         0x00002DDB
0.000089          0.000000         0x38BB3A12         0x0000B455
0.000103          0.000000         0x38D83A29         0x0000B24D
0.001146          0.000000         0x3A9636D5         0x0000B5F4
0.002551          0.000000         0x3B27321A         0x0000B674
0.003848          0.000000         0x3B7C31AA         0x0000B4D6
0.003044          0.000000         0x3B478001         0x0000B6A0
0.004959          0.000000         0x3BA2820D         0x0000B4C5
0.002559          0.000000         0x3B27B21A         0x0000B674
0.003856          0.000000         0x3B7CB1AA         0x0000B4D6
0.001142          0.000000         0x3A95B6D5         0x0000B5F3
0.000090          0.000000         0x38BBBA12         0x0000B455
0.000103          0.000000         0x38D8BA2A         0x0000B24D

Each line represents a set of 8 bytes, first displayed as 2 floats then displayed as 2 DWORDs. The second DWORD does definitely look somewhat strange since they all begin with 0x0000 which I assume is somewhat unlikely for realy float values... I''d be happy about every idea that comes to your mind. Any help would be greatly appreciated. Thanks in advance, Alex

##### Share on other sites
Hm, spent the day further investigating that stuff but didn''t really come to a solution, yet. However, the rest of the importer works really well at the moment as you can see at the following screenshot:

http://www.dajudge.com/shot1.jpg

So, if anyone has an idea about those normals I''d be really eager to hear it since it''s the only thing that keeps me from using per-pixel lighting on that model at the moment.

Cheers,
Alex

##### Share on other sites
I did the same thing last year, for fun too...
didn't have time to finish and fully extract the bones, only had a few days during summer holidays to reverse the format. if you're interested, I wrote some stuff about it clicky.
these are stuff as wrote as I discovered the format, sorry if it's a little bit messy, you might find what you're looking for in it, I don't remember the details now...
btw, I only read your post quickly, if you've got problems with normals/tangents, etc.. in some of their format, they store them as halfs, not floats.

EDIT: cross

[edited by - sBibi on May 26, 2004 6:12:19 PM]

##### Share on other sites
Hi,

Your site was a great ressource during development even though it was for Dusk''s file format which seems to be slightly different. Actually it was your site that inspired me to write a NMB importer for my little playtime-engine.

If you could that normal/tangent format to me I''d be very happy - I actually never worked with halfs so I''m a little bit confused there atm. But it does definitely look like that, yes.

Cheers,
Alex

##### Share on other sites
oh, glad to see it was useful to someone

about halfs, you can go have a look at ILM''s OpenEXR sources to give you an idea on how to convert floats to halfs and halfs to floats. http://www.openexr.com/
it''s free software, and it has 16 bits floating point support.

##### Share on other sites
hm. that would explain why one of the words in the two DWORDs is unused...

##### Share on other sites
Thanks for your help. Works fine now:

www.dajudge.com/shot1.jpg

Cheers,
Alex

##### Share on other sites
quote:
Original post by sBibi
I did the same thing last year, for fun too...
didn''t have time to finish and fully extract the bones, only had a few days during summer holidays to reverse the format. if you''re interested, I wrote some stuff about it clicky.
these are stuff as wrote as I discovered the format, sorry if it''s a little bit messy, you might find what you''re looking for in it, I don''t remember the details now...
btw, I only read your post quickly, if you''ve got problems with normals/tangents, etc.. in some of their format, they store them as halfs, not floats.

EDIT: cross

[edited by - sBibi on May 26, 2004 6:12:19 PM]

Excellent link! NMB here I come...
One thing I remembered is when you wrote "NVIDIA guys seem to like those ffffff". I think this is because of an extension called NV_primitive_restart. Normally, one value is reserved to indicate that the primivite being rendered should restart (in this case a strip). Normally, ffffff is the value choosen...
That means that a single glDrawElements call can have several GL_TRIANGLE_STRIP...

##### Share on other sites
Yes, that''s the case in the NMB file format. Multiple triangle strips are stored in a single array separated by a 0xFFFF index value. Plus chunks end with 0xfffffffc and chunk names are tagged by 0xfffffffd...
sBibi describes that pretty well on his page...

• ### Forum Statistics

• Total Topics
628368
• Total Posts
2982293

• 10
• 9
• 13
• 24
• 11