Cars 2 model exporting problems- please help

[xpunkrockyugox]

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.

Oops- I actually ended up reading over that again and realizing that was already answered shortly after I posted that question, my mistake
I'll go ahead and change that to put in the right labels- I've been working on the Yugo one myself. I found over 25 jump discontinuities but 3 different buffers, so I'm just trying to see which JD addresses are also integral multiples of 3. Since you only had 4 on your diagram, I'm wondering if it's normal to find that many JDs and then kind of narrow it down based on which ones will work.

Annotation 2020-08-26 103233.jpg

Here's the little notes I made so far. Given that I was able to successfully replicate the results and the numbers you got with the Gremlin model, I have confidence that multimesh models won't be so daunting anymore

[Bigchillghost]

I found over 25 jump discontinuities

These are not the so-called jump discontinuities.
You need to understand that the data in the ibuf are all two-byte little-endian short integers. So you need to read from the right to the left.

[xpunkrockyugox]

These are not the so-called jump discontinuities.
You need to understand that the data in the ibuf are all two-byte little-endian short integers. So you need to read from the right to the left.

Oof, I guess that means I probably need to start all over then >.<
So is the right way to find them taking each pair of bytes, reading them right to left, and comparing them to see if they're in order that way?
I'm using HxD for my hex editor, so here's what it looks like when I open the .ibuf.

Annotation 2020-08-27 140022.jpg

Edit: I found an option in HxD to put them into groups of 2 so I switched the attachment to have that image instead. Will comparing those give me a more accurate depiction of where the jump discontinuities truly are? Should I read the last two numbers first and compare those instead of the first two so I'm looking at it in little-endian?

[Bigchillghost]

So is the right way to find them taking each pair of bytes, reading them right to left, and comparing them to see if they're in order that way?

Not exactly.

I'm using HxD for my hex editor

If that works for you.

I found an option in HxD to put them into groups of 2 so I switched the attachment to have that image instead. Will comparing those give me a more accurate depiction of where the jump discontinuities truly are?

No. It actually make it harder.

Should I read the last two numbers first and compare those instead of the first two so I'm looking at it in little-endian?

Not necessarily.

[xpunkrockyugox]

No. It actually make it harder.

Oh, ok. Thanks for telling me. What would the best way be, then? ^^

[Bigchillghost]

What would the best way be, then?

I suggest to use a hex editor that supports color schemes, which's more friendly to human eyes, and easier for recognizing bytes in different ranges.

The proper way is to work on the byte level and focus on the values of the most significant byte (MSB) of the indices. If you can't read the values parallelly, set the columns to a smaller value like 4, then scroll down and find every suspicious address where the data encounter an abnormal change that's causing the discontinuity.

You also need to check the amount of vertices of every vertex chunk first to have something for reference. Simply divide the datasize by its stride to get the exact count.

[xpunkrockyugox]

I suggest to use a hex editor that supports color schemes, which's more friendly to human eyes, and easier for recognizing bytes in different ranges.

Ok, I think that definitely could help, I know that my eyes kinda glaze over and get tired when looking at all those numbers sometimes and it can be easy to lose my place Which hex editor do you use/recommend? ^^

[Bigchillghost]

Refer to this post.
viewtopic.php?p=139002#p139002

[xpunkrockyugox]

Refer to this post.
viewtopic.php?p=139002#p139002

Thanks! I'll download it right away. Before I saw that notification, however, I ended up looking at the Yugo .ibuf a little more. I thought I'd share with you the way I would spot the jump discontinuities, so that you can just check and see if that's ok. Last time you told me that listing all the places where there was a huge difference in the bytes, so I want to make sure I'm doing this right!

Annotation 2020-09-02 155053.jpg

[Bigchillghost]

Last time you told me that listing all the places where there was a huge difference in the bytes

I don't know if you actually understand what a jump discontinuity means. The reason I chose this term is that it's a really vivid concept for such situation.
(reference image from Wikipedia)


Of course it's not totally in accordance with the definition since these values are discrete afterall, which's also why you need to focus on the MSB of the values. Normally I'd say it's a jump discontinuity if there's a difference over 4 between the MSBs of the two values. Another important thing is, that you shouldn't just conclude without looking at the nearby values. If you don't know what a MSB is, better google for it first.

[xpunkrockyugox]

Of course it's not totally in accordance with the definition since these values are discrete afterall, which's also why you need to focus on the MSB of the values. Normally I'd say it's a jump discontinuity if there's a difference over 4 between the MSBs of the two values. Another important thing is, that you shouldn't just conclude without looking at the nearby values. If you don't know what a MSB is, better google for it first.

Thanks for the illustration- I'm looking at the Wikipedia for both MSB and discontinuities right now. My process up until this point was look at two bytes at once and then look at the next two, comparing the first number of each (Like, for example, if I had 2A 05 then 00 0F, I would look at the 2A and 00 because that was the largest byte on the left. Therefore there's a big gap between the two values because 2A is so much greater than 00 and I just ignored the number on the right. I'm starting to think I confused big-endian with little-endian lol)
Of course I've never been super math savvy, but I am still extremely interested in this whole thing regardless of how much math I have to learn!

[Bigchillghost]

Like, for example, if I had 2A 05 then 00 0F ... I'm starting to think I confused big-endian with little-endian lol

Yes, you should read them in little-endian, which's from the right to the left, as I've already said. So it's 0x52a followed by 0xf00, which's almost 3 times of the former value.

but I am still extremely interested in this whole thing regardless of how much math I have to learn!

The jump discontinuity is indeed a mathematical concept, but this situation isn't actually a math related problem so simply try to follow the idea of this so-called "gap".

[xpunkrockyugox]

Yes, you should read them in little-endian, which's from the right to the left, as I've already said. So it's 0x52a followed by 0xf00, which's almost 3 times of the former value.

Yeah, it's definitely starting to make more sense now ^^ Looking at the .ibuf the MSBs (on the right, of course!) don't actually typically change too much while the LSBs have a lot of fluctuation. No wonder I found over 36 when I was reading the data wrong!

The jump discontinuity is indeed a mathematical concept, but this situation isn't actually a math related problem so simply try to follow the idea of this so-called "gap".

I'll definitely do that, thanks! ^^
But that being said, is the formula/analysis thing I did for how you got the numbers for the Gremlin model correct? I think I included a screenshot that had all of those steps, if I didn't just let me know. I'd just like to make sure that I'm following the right steps to plug in the addresses for the Yugo/others ^^

[xpunkrockyugox]

These are not the so-called jump discontinuities.
You need to understand that the data in the ibuf are all two-byte little-endian short integers. So you need to read from the right to the left.

Hey there BCG, quoting this one because it was the last one that related to the addresses in the Yugo file ^^ I've run into a problem when working on the second Yugo submesh. The first one worked just fine, it only contained the axles.

Annotation 2020-09-05 102308.jpg

I'm getting a vertex overflow error message here using these values, and I plugged in all the appropriate numbers from the Yugo files, using the same "formula" (I know it's not really a formula in a math sense, but I just mean that I used the numbers in the same locations- like the first number after the normals buffer, address of first JD, etc. Formula was the best word I could think of to use there ^^) that I figured out from your Gremlin screenshots. In my screenshot I tried to put everything where it was visible- the "formula" from the Gremlin model, the numbers from the Yugo one, and what I had in AMR.
I'm wondering if there's any mistakes you spot that jump out right away there in that picture, like if I added a wrong step into the Gremlin formula thing. Thanks!

[Bigchillghost]

You should upload some clearer images.