Jet Set Radio HD Level Model File

[screenracer]

What happens if you rotate the scene (by 90 degrees for example) and take another rip? Are the same objects distorted or others?

The rips always export near the origin point at the same spots, so some repositioning is required.


After repositioning, I get something like this.


It seems the farther an object is from the camera the more distorted it gets, and the whole thing appears to be stretched at an odd angle and bent out of proportion. I'm not entirely sure if these rips could be usable, no matter how much I resize or rotate it I can't seem to get it to look right.

[shakotay2]

It seems the farther an object is from the camera the more distorted it gets, and the whole thing appears to be stretched at an odd angle and bent out of proportion.

Is this a "known issue" with the ripper tool you used? If not you could inform the author. Might be fixable by applying a suiting matrix multiplication or something like this. (The ripper rips directly from video RAM, doesn't it?)

btw: afair there's more than one 3D ripper available. Did you check a 2nd one?

It seems the farther an object

So you could move in the scene, take several rips at different places each and combine them. A tedious task, I know, but should work, shouldn't it? (Better than nothing... )

[screenracer]

Is this a "known issue" with the ripper tool you used?

Not really. It only does it with this game, due to the way the game renders stuff I guess. The same thing happens with other dreamcast games too. I also heard it happens with PS2 games as well, but I haven't tried. All rippers seem to turn out like this if not worse.

Here's how Ninja Ripper rips it...


Very strange rendering method... I can only wonder why they decided to do it this way.

So you could move in the scene, take several rips at different places each and combine them.

That would work, but the models right up in front of the camera are still distorted, just not as bad as the farther ones.

[shakotay2]

Are the single objects (buses for example) part of the map(s) or in separate files? Can't seem to find them in the points clouds from the st1dat.bin file.
Checking separate files (if any) with objects could help to understand how the face indices are organized.

[screenracer]

Are the single objects (buses for example) part of the map(s) or in separate files? Can't seem to find them in the points clouds from the st1dat.bin file.
Checking separate files (if any) with objects could help to understand how the face indices are organized.

I'm pretty sure they're in seperate files, but I could be wrong. The games files aren't too well organized, so here's a few other files of different objects. Not sure if they are the traffic models or not though.
https://mega.nz/#!9z5hUbZR!Iwxffx8r2eGS ... V5MQcFMevg

I can probably guess what a lot of these might contain, but I may be wrong.

Code: Select all

stchkdat.bin - some map?
bikedat.bin - police bike
keikandat.bin - police officer character
patcardat.bin - police car
people1dat.bin - pedestrians and maybe traffic vehicles

I haven't been able to get anything out of anything but the map files. Not even vertices. Though I also don't really know what i'm doing and just go with the trial and error route lol

[shakotay2]

For the bikedat.bin I found the vertex blocks are marked by FF000000 patterns, so addr of even find (count start=0) +8 = start of vertex block,
addr of odd find= end of vertex block (seems to be the same for st1dat.bin).

This is the result for the bike (with a normals sphere in the midst):
.

bikedat-bin.png

For the face indices: I give up, it's too weird...

[screenracer]

This is the result for the bike (with a normals sphere in the midst):

So that's what that spherical thingy was that I kept getting when trying to rip character models...

For the face indices: I give up, it's too weird...

Well thanks for the attempts, they got these files locked down like fort knox. I'm gonna keep coming back to it in bursts, Hopefully i'll uncover something one of these days.

[JSS442]

I spent sometime over the summer trying to crack the format as well. Here's what I found hope it helps.

If you load cheat engine's memory viewer and view the games memory at address 0x20801000 the entire bin file of whatever character you're playing should be loaded into memory there and you can make live edits.
I did most of my research on the file EREKIDAT.bin in the PLAYER.afs archive. So the follow info comes from his bin file. Maybe some of it will be applicable to the stage files.

The bin file separates the model into segments for each body part. Each segment has its own set verts, uv, and triangle indices. However the indices of model are the same for all segments. So indices 1 and 2 refer to the same vertices for all model segments. I do not know if all vertices are the same for all segments.

Also there's two models, maybe three models per character. One for character, one for outline, and another for the shadow.

The indicies are packed right next to uv coords the format is as follows
[size in bytes,purpose]

before the indicator there is 2 bytes that determine how many groups there are. It also used to determine the facing direction of triangles
[2 bytes, IUV Group count]

[2,quad or tri indicator] if tri the next part has 3 groups if quad it has 4

Index UV Group
[2,vertex index][2,UV Cooardinate X][2,UV Cooardinate Y]



Here's an image to illustrate it



all of these offsets map 1:1 at 0x20801000 in game

pink is a ARGB color overlay
brown is a different type of indicator. I think it determines whether or not to render the tris or to use them as uvs of some sort.
purple is the tri/quad indicator
green is IUV Group
orange is the number of tris/quads to render this one is funny it does not always add up to this number
yellow is like purple but its negative and the sign value determines whether or not the tris are front or back facing.

Vertex and Normal are right next to each other as well
[3 floats,XYZ position][3 floats,XYZ Normal]

[egregiousguy]

So I was wandering around the forum to see if there were any posts about Jet Set Radio as someone recently asked if I could take a look at the file format. Then I saw your screenshot of the mesh in hex and noticed right away that it's a variant of the .nj format. I've been staring at the .nj format for Rent-A-Hero recently so I recognized it instantly. The difference though is that it seems that the meshes and pointers are in reverse order compared to the .nj format so renaming it to an .nj and throwing it into Noesis doesn't work since the pointers for the vertices and indices are all off. I was able to reconstruct the first mesh manually for the EREKIDAT.bin file and load it up into Noesis. It looked like fingers to me but the mesh was a bit off. I'm planning to write a script (who knows when) to gather the mesh data and reconstruct the pointers to a usable .nj format unless it can get implemented into Noesis directly.

Beat (Fingers).png

[egregiousguy]

Worked on it a bit more to test out the structure. Managed to go a bit further into the model and got his arm loaded up. Looks like I'm on the right track.

Beat (Arm).png

[egregiousguy]

And there we have it. Beat in .nj format. I wonder if the .njm is packed in the bin file as well.

Beat.png

[egregiousguy]

Player models were easy to extract as seen below. I haven't worked enough with .nj files to get them textured but I figure that it shouldn't be that difficult to do.

I started taking a look at the map file but looks to be a bit more complicated. The stage 1 data seems to be separate models that get loaded at 0,0,0 and further into the .bin is another "file" that sets the coordinates of each object. One thing to note is that there seems to be a pointer offset of 0x8CB00000 for the all the 3D models (except for the player ones) so you'd either have to fill in 0x8CB00000 bytes before the file (which I don't recommend as it'll leave you a 2Gb+ file) or subtract that much from each pointer to make things work. If you've worked with .nj files before then this will make a lot of sense.

[screenracer]

Player models were easy to extract as seen below. I haven't worked enough with .nj files to get them textured but I figure that it shouldn't be that difficult to do.

Nice! The rig also looks the same as the future models, which I assumed it would be since they reuse animations between the games and I didn't think that would of been possible unless the rigs were identical. I hope you can manage to get them uv'd/textured, I know the JSR community would love to see these models finally cracked, even if it's just character models.

[egregiousguy]

The UV's seem to be intact so that's a big time saver. I just need to figure out how .nj files load textures then we should be in business.

[egregiousguy]

Well that was quicker than I thought. I just need to do this for the rest of them and then I guess I can call it a day.