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.001604          0.000000         0x3AD236FB         0x0000B489         
         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.001623          0.000000         0x3AD4B6FD         0x0000B489         
         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

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

Hi,

thanks for your reply.

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

hm. that would explain why one of the words in the two DWORDs is unused...

Thanks for your help. Works fine now:

www.dajudge.com/shot1.jpg

Cheers,
Alex

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...