NFS No Limits

[shakotay2]

Chipicao's tool worked greatly. It just doesn't support the latest models because of the newer encryption, but I'm sure that the 3D format is the same. Wouldn't it be better to just continue his work instead of doing the research for this completely from scratch?

As another aspect: Chipicao hasn't been here for a long time, afaics. So it's not sure whether he would agree that someone takes up/continues his work.

When you have a look at GreenTrafficLight's import_sb3d.py script, it's really great, imho.

@GreenTrafficLight: it's your script, is it? Because it reads: "author": "Test"

By the way, It is possible to program a bounding box function from Advanced Mesh Reaper in blender ? It seems that the matrices at the start are important for the placement of the body kit.

You need to give an example, which body kit?
btw: getting rotation/translation from a matrix is not too hard. Decide what type, 3x4, 4x4?
But having a look at mesh_bumper_rear_paint_a_lod00, 0x1EE70 for the bmw_m3, it might be quaternion rotation then translation (or vice versa, just a wild guess).

it's my first steps in blender scripting

what? Would take me months to write such...

[GreenTrafficLight]

When you have a look at GreenTrafficLight's import_sb3d.py script, it's really great, imho.

@GreenTrafficLight: it's your script, is it? Because it reads: "author": "Test"

Yeah, I was just lazy to write the details of the script lol, even if it's a small thing.

By the way, It is possible to program a bounding box function from Advanced Mesh Reaper in blender ? It seems that the matrices at the start are important for the placement of the body kit.

You need to give an example, which body kit?
btw: getting rotation/translation from a matrix is not too hard. Decide what type, 3x4, 4x4?

I only have basic knowledge about model format, but I guess those are 4x4 matrix. Something I noticed is that the float value -0.52 appear a lot, which fit for the translation of the body kit (for example, here, it seems the front bumper fit perfectly the body kit under it, could be just a coincidence though) :

it's my first steps in blender scripting

what? Would take me months to write such...

I mean, when you look at the blender scripts written by other people, mine kinda feel amateur-ish, I only know how to write a blender script thanks to the xentax wiki.

(Though I already worked on this format a long time ago, then just gave up)

[DKDave]

I've managed to analyse the format in a bit more detail, and I can now see the information for which vertex files are matched with the relevant face files - some vertex sections also use more than 1 face file.

Those float tables near the start of the file seem to be skeleton data of some sort - standard 4 x 4 Float matrices. In the Lamborghini file, there are 1060 entries of 0x40 bytes each, followed by another 1060 entries of 0x40 bytes each. The first set is the normal matrix, the second could be inverse matrix data. The table following this is the bone parent information. After that you've got another table related to the bones, with names and other info, which could also be some matrix data. Then you've got separate tables for the face and vertex information. It's very convoluted!

I'm still trying to work some of it out (if nobody else already has), but there's lots of relative offsets to consider, and lots of unknown values.

[shakotay2]

yeah, too many parts. I made a list of possible translation values from the BMW M3 matrices, but only a few values are >1.0 or < -1.0.
(examples)
# 15 0x480: 0.939856 -0.078117 -1.835776 1.000000
# 16 0x4c0: 0.945146 0.045282 1.545409 1.000000
# 17 0x500: -0.952803 0.032095 1.538241 1.000000

I did move (and scale ) the rear bumper manually:
.

rear bumper.png

(Don't have the sb3d file, the chunks only, so can't tell, whether the importer places that bumper correct already.
Plus dunno, whether it's really mesh_plastic_bumper_rear_a_lod0 that I used.)


When I have more spare time I'll care for porsche_911_gt3_991.sb3d, but from a quick glance the importer put all pieces correct.
edit: well, see, the "usual suspects" , mesh_plastic_bumper_rear_a_lod00 is misplaced there (scaling correct), z coord too deep, it's easy to correct manually.
Same goes for mesh_headlight_cluster_a_lod00, y pos affected, too.

[GreenTrafficLight]

When I have more spare time I'll care for porsche_911_gt3_991.sb3d, but from a quick glance the importer put all pieces correct.
edit: well, see, the "usual suspects" , mesh_plastic_bumper_rear_a_lod00 is misplaced there (scaling correct), z coord too deep, it's easy to correct manually.
Same goes for mesh_headlight_cluster_a_lod00, y pos affected, too.

Yeah, those pieces are the reasons why I think the matrix at the start play a role in their position.

I found that the matrix at the start aren't ordered, each mesh has a bone index (as highlighted in the image, at offset 0x275DC) which is tied to the matrix. For example, the mesh_bumper_rear_plastic_a_lod00 has a bone index of 301



Each matrix does 64 bytes, so 64 * 301 = 19264, which give the matrix located at 0x4BD0, that has a y translation of -5.96046447753906E-8. And when I try this translation in blender, the mesh does not move (as seen at the top-left).





However, I tried with the inverse matrix (they start at 0x8FD0), which is the matrix at 0xDB10, that has a y translation of 0.555474698543549 (the x coord is -1.18329133138289E-32 and doesn't move the mesh), the plastic rear bumper placed perfectly with the other mesh.





I tried with mesh_headlight_cluster_a_lod00 and it seems to work, it had the same y translation (bone index of 374, matrix at 0x5E10 and inverse matrix at 0xED50).

All of this can be a coincidence though, but It's the same problem that Chipicao had before.

Everything is fine once you use the correct vertex bias and scale:

Assigning groups will probably put everything together even better.

(Hope my post isn't too confusing since english isn't my first language.)

[shakotay2]

The first set is the normal matrix, the second could be inverse matrix data.

However, I tried with the inverse matrix (they start at 0x8FD0), which is the matrix at 0xDB10, that has a y translation of 0.555474698543549 (the x coord is -1.18329133138289E-32 and doesn't move the mesh), the plastic rear bumper placed perfectly with the other mesh.

Yeah, cool! (Those damxed inverse matrices! )

[GreenTrafficLight]

So, yeah, the matrix did play a role in the position of some of the object. I don't know what is the purpose of the inversed matrix though.





Still, there are still plenty of things left like the normals (the rear bumper of the porsche doesn't look smooth) and the scale/position of UV. And also the hierarchy.

(btw, I managed to bring the origin to the center of the mesh instead of being at the bottom-right. And don't try to go into edit mode when you select all the object, it will crash Blender instantly).

[shakotay2]

And don't try to go into edit mode when you select all the object, it will crash Blender instantly).

Generally I'm interested in the lod00 objects only, so after selecting and moving them I could delete all the unwanted lower lods.

quote from quora.com, Zachary Bingham:
"The only problem arises when we want to divide a matrix, as there is no division operation that can be applied to the matrix. Thus, we have the Inverse."

Seems it's faster to have those inverse matrices present in (RAM) data instead of calculating them during runtime.

[zimex25]

Some issues what I find:
- Mesh doesen't smooth when export in Blender and import in 3ds Max
- Some parts have problem with UV Map, when model import in 3ds Max (.obj and Evo VI)
and what about textures? The only method what I know is NOX + Ninja Ripper maybe somebody making faster method?
Function from NFS Hot Pursuit/Most Wanted importer will be awesome - when import new file, scene will be reset.

[zimex25]

For pack files from newer version game, use this script.
NFSNL_packUnpacker.zip


Note: if you're gonna copy files to another folder, don't forget about the folders of the same names as the corresponding pack files, if there were any. Or you can simply leave the whole data folder untouched, the script will automatically create an individual folder for outputs.

and also this script (for me) don't unpack all files, some cars is missing just like DMC or 718 Cayman GT4.

[GreenTrafficLight]

Am I doing the conversion from byte to decimal wrong ? Because I wonder if it's why normal are broken.

Code: Select all

n1 = vertexBuffer.readByte() / 127;
n2 = vertexBuffer.readByte() / 127;
n3 = vertexBuffer.readByte() / 127;
normals.append([n1,n2,n3])

Edit : Seems to be char rather than byte ? (I don't know how to convert a char to decimal in python)




Edit 2 : So I remplaced the code with

Code: Select all

n1 = vertexBuffer.readByte() * 2 / 255;
n2 = vertexBuffer.readByte() * 2 / 255;
n3 = vertexBuffer.readByte() * 2 / 255;
normals.append([n1,n2,n3])

Which gave me almost the same results as Advanced Mesh Reaper



However, Blender doesn't apply the normals and I don't know why.

[shakotay2]

However, Blender doesn't apply the normals and I don't know why.

Does it happen for special parts/models only?
.

porsche_911_gt3_991.sb3d-normals.jpg

[GreenTrafficLight]

Does it happen for special parts/models only?

Nope, it seems to apply to all parts.

It's weird because it's seems that converting normals from byte to float doesn't seem to work on blender. For example, I did a blender version of the Captain Tsubasa Rise of New Champions noesis script, and it's also have the same problem since it's also use unsigned bytes to store the normals.
(left is ripped with Advanced Mesh Reaper, right is ripped with the script)



However, when I was working on a blender script for Initial D Arcade Stage, the normals worked fine because they are stored as float.



I will probably try to do something like DGIorio blender scripts which use the bmesh function to create the mesh, to see if it change anything.

[Bigchillghost]

Edit 2 : So I remplaced the code with

Code: Select all

n1 = vertexBuffer.readByte() * 2 / 255;
n2 = vertexBuffer.readByte() * 2 / 255;
n3 = vertexBuffer.readByte() * 2 / 255;
normals.append([n1,n2,n3])

For unsigned integer types, what you need to do is to normalize the values into the interval [0, 2], and then shift them into [-1, 1].
In this case for unsigned bytes, you need to edit your code like this:

Code: Select all

n1 = vertexBuffer.readByte() * 2 / 255 - 1.0;
n2 = vertexBuffer.readByte() * 2 / 255 - 1.0;
n3 = vertexBuffer.readByte() * 2 / 255 - 1.0;
normals.append([n1,n2,n3])

But make sure this "readByte" method actually read as unsigned byte instead of signed one.

Probably it's because the values from your convertion fall out of the range of -1 to +1, so Blender just discarded everything. Just a wild guess though.

[shakotay2]

For unsigned integer types, what you need to do is to normalize the values into the interval [0, 2], and then shift them into [-1, 1].
In this case for unsigned bytes, you need to edit your code like this:

Code: Select all

n1 = vertexBuffer.readByte() * 2 / 255 - 1.0;
n2 = vertexBuffer.readByte() * 2 / 255 - 1.0;
n3 = vertexBuffer.readByte() * 2 / 255 - 1.0;
normals.append([n1,n2,n3])

Sounds like a good idea!

But make sure this "readByte" method actually read as unsigned byte instead of signed one.

Using GreenTrafficLight's code (typo correction 'b' ->'B')

Code: Select all

    def readUByte(self):
        return struct.unpack(self.endian + "B", self.read(1))[0]

then
n1 = vertexBuffer.readUByte() * 2 / 255 - 1.0;
...

I couldn't get better results - best results I got not creating the normals by the script and letting blender do the job.
But we need the texture for the normals (bump map?) to judge.
.

porsche_bumper_rear.jpg