Sniper Elite 3 & 4 .asr/models

[dimis9138]

Hey, I was messing around with SE4 and was wondering if anyone ever figured out the models.

Textures are great and easily extracted with asura.bms but about the models, it just extracts them as generic files.
I've attached a model extracted from the game below, I played around with it with MR but couldn't get the right offsets etc.
Was wondering if there's info about this format anywhere.

carcano scope.rar

[shakotay2]

Half floats are harder to track, this is not perfect but may serve as a starting point, using hex2obj:
.

l3#carcano_scope_camo.png

[Bigchillghost]

Using AXE:

l3#carcano_scope.png

[dimis9138]

Using AXE:
l3#carcano_scope.png

Damn, I gotta figure out how to use mesh reaper :s.

Thank you both.
This was the result I was getting with model researcher, same for DJ Normality.

https://i.imgur.com/l1JAVEp.png

I'll try to use Ghost's AXE and see if I can work something out that way. Looks way more complicated than MR but hopefully I can understand how it works (time to read the wonderful tutorial posted by Ghost ) .

[dimis9138]

Here is the file from said screenshot from above. I used the same format as the one in your post but with the offsets that worked for me in model researcher. I get a same result, was wondering if it's not just me and if it is me using AXE wrong what the difference is with model researcher to get the models to actually work with AXE where-as with model researcher they're broken like in said screenshot above. If you could look at some point ghost since you know how to use AXE better that'd be nice. I also put a link in the bottom of this post to a download of more SE4 stuff including an actual human model if anyone's interested in having a go at that.

Offset I used was 2D7EC.

kar98k_snow.rar

More files: https://mega.nz/file/thp0HLTK#dTlREBNr2 ... bnGtco9A4w

[Bigchillghost]

I'll try to use Ghost's AXE and see if I can work something out that way.

You know, it sounds kinda weird that you address me like that and I "officially" disapprove it.

I used the same format as the one in your post but with the offsets that worked for me in model researcher. I get a same result, was wondering if it's not just me and if it is me using AXE wrong what the difference is with model researcher to get the models to actually work with AXE where-as with model researcher they're broken like in said screenshot above.

AXE uses the low-level vertex index count to describe polygons as it's not possible to know the exact polygon amount for encodings like triangle strip without interpreting the data first. You should not just copy the params without adjusting them according to your circumstances, though some of them might still be the same. In your screen you forgot to adjust the relative address for vertex attributes. That's the only param you need to adjust for vertex attributes btw.

It took me a while to figure out what you mean by "broken" then I just realized the data type for positions should actually be unsigned short, which sadly had not been revealed by that previous sample.

kar98k_snow.png

[dimis9138]

I'll try to use Ghost's AXE and see if I can work something out that way.

You know, it sounds kinda weird that you address me like that and I "officially" disapprove it.

I used the same format as the one in your post but with the offsets that worked for me in model researcher. I get a same result, was wondering if it's not just me and if it is me using AXE wrong what the difference is with model researcher to get the models to actually work with AXE where-as with model researcher they're broken like in said screenshot above.

AXE uses the low-level vertex index count to describe polygons as it's not possible to know the exact polygon amount for encodings like triangle strip without interpreting the data first. You should not just copy the params without adjusting them according to your circumstances, though some of them might still be the same. In your screen you forgot to adjust the relative address for vertex attributes. That's the only param you need to adjust for vertex attributes btw.

It took me a while to figure out what you mean by "broken" then I just realized the data type for positions should actually be unsigned short, which sadly had not been revealed by that previous sample.
kar98k_snow.png

Oh so the relative to address in AXE is the address for vertices? I didn't quite understand that hah. I will play around with some more samples and post something here. Thanks a lot man, I really appreciate it. Now all we need like Normality said is a tool that makes another tool off these settings hahah.

[dimis9138]

After using MR I could produce this result:

After putting this in AXE I got this error: Polygon vertex index count could not evenly divide by 3. I realized by looking at your screenshots that you simply * 3'd the vertices amount (something I guess MR does automatically with shorts?) to get your results and did the same but I'm now just getting this error: Error occured while checking params, file too small for required size of polygon vertex index data which makes me think I've simply went out of the file's size but reducing it simply gives a pretty damaged result.

MR settings:

File attached, sorry for being a pain but I'm just trying to learn how to use AXE better because it seems to be a really great tool and I'm not sure if there's a way to override it or not.

kar98k_scope.rar

[dimis9138]

I've also looked at another file which I linked (g43_snow in the picture & g43) which appears to be everything correctly set up such as vertices, faces etc but the end result is a flat plane with all the faces overlapping. If anyone knows what could be causing this please let me know.

AXE settings:

End result:

However the positions seem fine in the interpretation.

Also, this program is really great. Thank you for releasing this.

g43.rar

[Bigchillghost]

Oh so the relative to address in AXE is the address for vertices?

There're two modes for how vertex attribute addresses can be specified. You can either specify the absolute addresses for every vertex attributes, by enabling the "Absolute" radio button, in which way you'll have to modify the values every time for another file or sub-mesh. Or, you could just use the relative mode, to specify a base address for the vertex attributes, and then specify the offsets for corresponding attributes, relative to that address. In this way, so long as the vertex layout doesn't change, you don't need to change the offset for every attribute. Instead, you just need to reassign the base address (or called a relative address), which obvious will be a great relief for the lazy.

After putting this in AXE I got this error: Polygon vertex index count could not evenly divide by 3. I realized by looking at your screenshots that you simply * 3'd the vertices amount (something I guess MR does automatically with shorts?)

As I wrote here:

AXE uses the low-level vertex index count to describe polygons as it's not possible to know the exact polygon amount for encodings like triangle strip without interpreting the data first.

It's not the "vertices amount" that you need to multiply with, it's the polygon amount. For ordinary triangle encoding you get the indices count by multiplying the polygon count with 3, or by dividing the total length of the indices data by 2 (for short indices).

The params you used for polygon vertex indices address and count aren't accurate btw.

kar98k_scope.png

sorry for being a pain but I'm just trying to learn how to use AXE better because it seems to be a really great tool

AXE inherited pretty much all features from AMR, which has a detailed document for how it works. Furthermore, AXE simply enhanced that, which's why I didn't bother to write another "specification". I'm just too lasy for that. You can however use that document as a reference for a better understanding of the entire workflow. Link attached below.
AMR - Mesh Format Research Helper

[Bigchillghost]

I've also looked at another file which I linked (g43_snow in the picture & g43) which appears to be everything correctly set up such as vertices, faces etc but the end result is a flat plane with all the faces overlapping. If anyone knows what could be causing this please let me know.

You were just using the wrong params. The relative address for vertex attributes should be 0xA4 and the address for polygon vertex indices is 0x2CB04, and the indices count, 14973.

[dimis9138]

Oh so the relative to address in AXE is the address for vertices?

There're two modes for how vertex attribute addresses can be specified. You can either specify the absolute addresses for every vertex attributes, by enabling the "Absolute" radio button, in which way you'll have to modify the values every time for another file or sub-mesh. Or, you could just use the relative mode, to specify a base address for the vertex attributes, and then specify the offsets for corresponding attributes, relative to that address. In this way, so long as the vertex layout doesn't change, you don't need to change the offset for every attribute. Instead, you just need to reassign the base address (or called a relative address), which obvious will be a great relief for the lazy.

After putting this in AXE I got this error: Polygon vertex index count could not evenly divide by 3. I realized by looking at your screenshots that you simply * 3'd the vertices amount (something I guess MR does automatically with shorts?)

As I wrote here:

AXE uses the low-level vertex index count to describe polygons as it's not possible to know the exact polygon amount for encodings like triangle strip without interpreting the data first.

It's not the "vertices amount" that you need to multiply with, it's the polygon amount. For ordinary triangle encoding you get the indices count by multiplying the polygon count with 3, or by dividing the total length of the indices data by 2 (for short indices).

The params you used for polygon vertex indices address and count aren't accurate btw.

kar98k_scope.png

sorry for being a pain but I'm just trying to learn how to use AXE better because it seems to be a really great tool

AXE inherited pretty much all features from AMR, which has a detailed document for how it works. Furthermore, AXE simply enhanced that, which's why I didn't bother to write another "specification". I'm just too lasy for that. You can however use that document as a reference for a better understanding of the entire workflow. Link attached below.
AMR - Mesh Format Research Helper

Thank you, that answers a lot of my questions. I will try to get into AMR this weekend first and then AXE to try and learn this workflow for reversing models.

[dimis9138]

I've also looked at another file which I linked (g43_snow in the picture & g43) which appears to be everything correctly set up such as vertices, faces etc but the end result is a flat plane with all the faces overlapping. If anyone knows what could be causing this please let me know.

You were just using the wrong params. The relative address for vertex attributes should be 0xA4 and the address for polygon vertex indices is 0x2CB04, and the indices count, 14973.

Damn you're a legend man. I keep getting confused because last time I tried to do this was with cyberpunk models where I could at least see the general shape of the model even if the offsets were slightly wrong so when I see a flat plane I tend to get confused. By the way, you should definitely get a tip link or something where people (like me) can tip/thank you for your work and being this patient as a whole. Thanks a lot man.

[dimis9138]

Only last thing I'd like to ask if it is possible, is how is padding exactly decided/processed/dealt with in AXE? Is it by getting the correct amount of columns for stride so that they're held exactly in 1 row (I'm asking this after briefly reading your AXE demonstration and seeing you detail processing vertex attributes with stride)?

Main reason I'm asking is because I'm confused with the terminology from MR (padding) and assuming that the equal in AXE is stride for attributes.

[Bigchillghost]

Is it by getting the correct amount of columns for stride so that they're held exactly in 1 row (I'm asking this after briefly reading your AXE demonstration and seeing you detail processing vertex attributes with stride)?

Yes, AXE uses the size (or stride) of a vertex element structure (containing all the attributes for one vertex including positions, normals, texcoords, etc.) to determine how the data are aligned. Otherwise you'll have to measure and specify the amount of bytes to skip after reading each attributes, which'll definitely be a huge pain considering so many vertex attributes.