Cars 2 model exporting problems- please help

[Bigchillghost]

Does AMR have an option to get textures out?

Nop. That's not a task for AMR. You can use PVRTexTool to unwrap the pixel data but for this game, the textures are already in ordinary dds formats.
However the nested format of the oct container is really annoying so instead of parsing the whole file structure, I just searched for the "TexturePool" mapping identifier to locate the textures and extract them to the drive.

Here's the mentioned Noesis script.

fmt_Car2_oct.zip

There're also a "VertexBufferPool" and a "IndexBufferPool" recorded in the oct file. But aside from the size of the vbuf/ibuf file, there's no vertex/indices count so guess you'll have to calculate them yourself.

[xpunkrockyugox]

Nop. That's not a task for AMR. You can use PVRTexTool to unwrap the pixel data but for this game, the textures are already in ordinary dds formats.
However the nested format of the oct container is really annoying so instead of parsing the whole file structure, I just searched for the "TexturePool" mapping identifier to locate the textures and extract them to the drive.

Here's the mentioned Noesis script.
fmt_Car2_oct.zip

Thanks again! I assume that Noesis is something like QuickBMS that I can use to extract the DDS textures, right? Here's what the TextureFinder tool gave me, I think I'll try one of those methods you mentioned too, because that would likely give me a higher quality output instead of getting it sorta mixed up like this one did because the only bits I recognize in the picture are his hat-roof thing, hood and license plate XD

[Bigchillghost]

Thanks again! I assume that Noesis is something like QuickBMS that I can use to extract the DDS textures, right?

This is one of the textures you'll get with the Noesis script.

axelrod_body_d_wii.png

Just throw the script into the "plugins\python" folder of Noesis and load the oct files within the application. You'll see what's extracted from the debug window.

[xpunkrockyugox]

Hey there!I just wanted to say thanks again for all the help. I got the Axlerod model working perfectly now! Well, perfectly for someone that doesn't know how to animate in Blender yet, that is lol
I've moved on to converting another one by myself, but I'm stuck on the AMR step right now, it keeps giving me this goofy error message every time I do. The way I got that number, by the way, was using the Disney Infinity model exporter and opening the .obj file in Notepad++. I'll provide a Google Drive link to the one I'm working on now (https://drive.google.com/file/d/16CKlAd ... sp=sharing) but all I really need is just to know how to find out the actual vertex count in a way that AMR likes so that I can easily do this process by myself for the rest of them. (I'm actually planning on making a Youtube tutorial video on how I did this and walking the viewers through converting one random Cars model!)
Again, I'm just confused about what exactly I got stuck on here because with Axlerod I didn't get stuck there, and would like to know how I can fix it so that I can do the others without problems. Thanks!

Edit: Nvm, turns out my problem was that I had the wrong normals address XD

[Bigchillghost]

I've moved on to converting another one by myself, but I'm stuck on the AMR step right now, it keeps giving me this goofy error message every time I do.

You really need to know what you're actually doing instead of complaining about the tool being stupid to you.
As I've said already:

pacer.png

The way I got that number, by the way, was using the Disney Infinity model exporter and opening the .obj file in Notepad++.

Which is totally unnecessary.

all I really need is just to know how to find out the actual vertex count in a way that AMR likes so that I can easily do this process by myself for the rest of them.

AMR doesn't LIKE or prefer any specific vertex count. What it does is to simply check whether the param you input is a valid vertex count (>= 3) and compatible for all attributes in the file scope.

[xpunkrockyugox]

That makes sense. Sorry for making that mistake lol
Moving on though, I am curious what this glitching I'm getting when exporting some of the models means. Not sure what happened but some of the vertices are scrambled once I open the .FBX in Blender. I'm going to include both these screenshots of AMR and of Grem, and 2 different models that come out glitchy no matter what end address I use. Again, sorry for asking so many questions. I mostly knew what I was doing, following that same streamlined, easy to understand process. But it didn't look right in the case of these two rebels. Got a couple of rogue vertices and I'm not sure if I'll have to manually drag them back into place with Blender, or if I've made a mistake in the numbers.
https://drive.google.com/file/d/1ejjQgD ... sp=sharing
https://drive.google.com/file/d/1kWQSw6 ... sp=sharing

[xpunkrockyugox]

You really need to know what you're actually doing instead of complaining about the tool being stupid to you.

Right, my bad. Sorry for complaining instead of actually taking a minute to figure out what was wrong because it turned out I had skipped one of those steps. >.< Generally speaking this is a pretty straightforward and easy to understand process, like for Acer and Axlerod, but unfortunately we've also got a few rebels like Grem and the generic Yugo model, that have some weird rogue vertices glitches.
Is there anything that can be done to prevent those rogue vertex glitches or will I just have to manually move them back into place in Blender?
Here's a picture of the Yugo model in Blender looking weird.

yugo_glitch.png

[Bigchillghost]

Again, sorry for asking so many questions.

First of all, no one blames you for asking questions. What I'm disapproving is that disrespectful tone.

I mostly knew what I was doing, following that same streamlined, easy to understand process.

You might be able to handle most single-mesh models with that workaround, without knowing the principles and logics behind it. But this model is involving the concept of submeshes which can't be explained in a word or two. Try to understand the connections between these params and the data at corresponding addresses.


Preview of all 3 submeshes:

gremlinAll.png

[xpunkrockyugox]

First of all, no one blames you for asking questions. What I'm disapproving is that disrespectful tone.

Oh crap, I'm sorry. I didn't know I sounded disrespectful. I really didn't mean to D:

You might be able to handle most single-mesh models with that workaround, without knowing the principles and logics behind it. But this model is involving the concept of submeshes which can't be explained in a word or two. Try to understand the connections between these params and the data at corresponding addresses.

Mm, I think I understand. I'll have to download those pictures and study them, kinda see if I can tell what's going on. I've learned a lot about how 3D modeling works over the course of this project, so that's definitely a good thing! ^^

[xpunkrockyugox]

You might be able to handle most single-mesh models with that workaround, without knowing the principles and logics behind it. But this model is involving the concept of submeshes which can't be explained in a word or two. Try to understand the connections between these params and the data at corresponding addresses.

Hmm... I've been looking at the picture, opening up the files in AMR and even trying to look at it in a hex editor, and I'm not entirely sure how you got the numbers to plug in in the screenshot you sent me. I'm probably being kind of a pain rn, and I do apologize in advance, but could I possibly ask where you got the numbers from in the Grem screenshot? I have to say, it's really amazing and impressive that you can do this hex editing and params stuff so easily!

[Bigchillghost]

I've been looking at the picture, opening up the files in AMR and even trying to look at it in a hex editor

EVEN? Observing the data within a hex editor is what you're supposed to start with.

but could I possibly ask where you got the numbers from in the Grem screenshot?

Refer to the below image:

gremlin_ibuf_grouping.png

As you can see the indices are in ascending order as they generally are. And you'll encounter the 1st jump discontinuity, or say, a pretty obvious gap between the two values, at address 0x5364. Then the indices are ascending again untill you encounter the 2nd jump discontinuity at address 0x53C4, and so on you'll find the 3rd jump discontinuity at address 0x71A0, and the 4th at address 0x7278. Then you can test these indices in AMR using the address of the jump discontinuities you found, combined with the addresses of different vertex chunks in the vbuf file, which can be acquired only from a hex editor.
Then you'll see the indices between the 1st and the 3rd jump discontinuities actually belong to the same submesh group, so as those from the the 3rd jump discontinuity to the end of file. So all together there're 3 submeshes, as you've seen in my previous post.

I have to say, it's really amazing and impressive that you can do this hex editing and params stuff so easily!

So you see, it's nothing magical but only some trials and errors based on experience. And it's obvious that you can't handle such cases without looking into the data itself. So I suggest you to learn from the beginning. Check the 1st link in my signature if you're interested.

[xpunkrockyugox]

EVEN? Observing the data within a hex editor is what you're supposed to start with.

Oops lol
I don't know how to read hex numbers and addresses, so that was why I saved checking it for last I suppose that would be my first step, learning how to read what the hex editor tells me! I was looking at it and frantically searching for the exact things you typed and getting myself utterly lost on the first screenful of addresses

As you can see the indices are in ascending order as they generally are. And you'll encounter the 1st jump discontinuity, or say, a pretty obvious gap between the two values, at address 0x5364. Then the indices are ascending again untill you encounter the 2nd jump discontinuity at address 0x53C4, and so on you'll find the 3rd jump discontinuity at address 0x71A0, and the 4th at address 0x7278. Then you can test these indices in AMR using the address of the jump discontinuities you found, combined with the addresses of different vertex chunks in the vbuf file, which can be acquired only from a hex editor.
Then you'll see the indices between the 1st and the 3rd jump discontinuities actually belong to the same submesh group, so as those from the the 3rd jump discontinuity to the end of file. So all together there're 3 submeshes, as you've seen in my previous post.

So you see, it's nothing magical but only some trials and errors based on experience. And it's obvious that you can't handle such cases without looking into the data itself. So I suggest you to learn from the beginning. Check the 1st link in my signature if you're interested.

Thank you so much! I think hopefully that's the last time I'll go "HALP I'M A NOOB NUMBERS NOT NUMBERING RIGHT!!" I really can't say thanks enough for all the help and patient thorough explanations, very grateful ^^

Edit- when looking for the vertex chunks in the .vbuf, do I also look for JDs or are they signified in a different way?

[Bigchillghost]

I was looking at it and frantically searching for the exact things you typed and getting myself utterly lost on the first screenful of addresses

Believe me, most people feel the same when they attempted to take the shortcut instead of learning from the beginning. Yet not much people have the passion and patience to learn for themselves. So you're doing quite well so far. Keep going!

when looking for the vertex chunks in the .vbuf, do I also look for JDs or are they signified in a different way?

Depends on how you define the discontinuity. The following figure should help you understand the trick.

[xpunkrockyugox]

Believe me, most people feel the same when they attempted to take the shortcut instead of learning from the beginning. Yet not much people have the passion and patience to learn for themselves. So you're doing quite well so far. Keep going!
Depends on how you define the discontinuity. The following figure should help you understand the trick.

Thanks!
I've hit a bit of a problem in analyzing this however. This time I did something different and tried to take notes of everything I was doing and connections I made between the numbers. (I decided to practice with the Gremlin model you already did, using the screenshots for reference and trying to arrive at all those same numbers the way that you got them so I might be able to try that process with any other multi-mesh ones I run across.)

Annotation 2020-08-24 220559.jpg

I'm trying to figure out where the 168 for the vertices count on the windshield/last submesh came from, would you mind letting me know how you got that last one?

[Bigchillghost]

This time I did something different and tried to take notes of everything I was doing and connections I made between the numbers.

Make sure to use proper terms like position address, normal stride, texcoord type etc. instead of phrases like "top address", to avoid confusion.

I'm trying to figure out where the 168 for the vertices count on the windshield/last submesh came from, would you mind letting me know how you got that last one?

You've already been told:

Then you'll see the indices between the 1st and the 3rd jump discontinuities actually belong to the same submesh group, so as those from the the 3rd jump discontinuity to the end of file.