I know I know I keep making new topics of existing ones from xentax but I need help with Burnout models from Takedown-era games. And what I mean by Takedown-era burnout, this is about Burnout 3, Revenge, Legends PSP and Dominator. There's a blender plugin from DGIorio for importing Burnout models but it hasn't been updated since 2021 and it doesn't support latest version of Blender, it only works on v2.7, v2.8 and surprisingly it also works in v2.9 and not beyond. And I need help with the result. I just don't know how the models I have imported on my blender scene have mesh splitted by UV and idk if there's a way to fix it. And also this plugin is open-source so anyone can modify it.

Result of models spilt by UV and in-game screenshot original

Result of Burnout bgv/btv models PS2 versions unsupported having mess of UVs

I have uploaded a sample of Burnout Revenge PS2 version in bgv

I've shared the blender plugin if you want to refine and make it support for importing PS2 version of Burnout 3, Revenge and Dominator. So far it has support for Xbox version of (B3, Revenge, Revenge X360,) and PSP (Legends, Dominator, NFS Shift because it uses Dominator engine) and also fixes mesh split by UV

For textures, you have to talk to Edness since he made a noesis plugin for all Burnout games (except Paradise)

CAR1A.7z import_bgv.py

Edited May 8, 20251 yr by UndercoverBoy833
refined my post

2 hours ago, UndercoverBoy833 said:

There's a blender plugin from DGIorio for importing Burnout models but it hasn't been updated since 2021

Honestly I wouldn't waste a minute with this before DGIorio's posts from Xentax have been restored.

22 hours ago, shak-otay said:

Honestly I wouldn't waste a minute with this before DGIorio's posts from Xentax have been restored.

idk what to say about it though and i just don't know what's worthy of my other topics I've created so far

I'm not sure whether this is a BO3 model, but I'd suggest to try XBOX models which you can get uvs from easily:

(Surprisingly the blender script gets the model but not the uvs.)

Edited May 9, 20251 yr by shak-otay

12 hours ago, shak-otay said:

I'm not sure whether this is a BO3 model, but I'd suggest to try XBOX models which you can get uvs from easily:

(Surprisingly the blender script gets the model but not the uvs.)

yes this is the Burnout 3 model and my sample is the PS2 version of bgv file and as I've already showed my result in the opening post, the blender plugin doesn't support UVs for PS2 Burnout files. But yeah I'm still using Xbox models for it at least.

But my small problem is after importing the Xbox models of Burnout 3 in blender, why the meshes are split by UVs, was it intended to have it originally or was the script code that are doing it so? If it were one of the reason, I have to edit some of it in Blender.

I know there are other people like Xenn have ripped some of Burnout 3, Revenge models using different methods and not have "mesh split by UV" results long time ago.

Edited May 10, 20251 yr by UndercoverBoy833

Once I get home I will look at it. Already got city model but still don't know where and how are materials/textures assigned to it. I think it should be in collision meshes data.

Also it uses a lot of instances.

20 minutes ago, h3x3r said:

Once I get home I will look at it. Already got city model but still don't know where and how are materials/textures assigned to it. I think it should be in collision meshes data.

Also it uses a lot of instances.

no worries, and no rush indeed. just take your time

also idk if this is helpful for you guys about vehicle datas and structures https://burnout.wiki/wiki/Vehicle_Data/Burnout_3

 

you don't have to check it out just now, I put it just for reference

Edited May 10, 20251 yr by UndercoverBoy833

why don't you just connect the vertices in a 3d editor. the plugin opens the models, that's all you need. the rest you can work on yourself

3 hours ago, Durik256 said:

why don't you just connect the vertices in a 3d editor. the plugin opens the models, that's all you need. the rest you can work on yourself

that's not the problem, I can at least fix it in some instance. But I wanted to know what's the cause of the mesh split by UV though, even I imported the model onto blender scene and did not touch anything.

Here is Noesis script for all PS2 version of Burnout. Already posted it on burnout discord server.

But not sure how to convert normals... and faces doesn't look good too. Not sure what causing it. Maybe someone more skilled can take a look at it and maybe fix it?

b3t_rev_dom_ps2_bgv_btv.7z

Thanks! Using facecull in Noesis it looks ok, but never saw such a face problem, just a visualization prob, I guess (though the uvs have a strange section, same as here).

Car1.bgv

mesh ok:

edit: CAR1A from the opening post:

Edited February 14Feb 14 by shak-otay

It's not just vizualization problem. The face normals are fliped at random.

To fix this lets say in maya, you need to select blacked faces and reverse them.

Also i found there is float variable> NormalShift and its value is 65537. Can be this somehow involved in byte normal conversion?

Edited February 14Feb 14 by h3x3r

2 hours ago, h3x3r said:

It's not just vizualization problem. The face normals are fliped at random.

My bad, I didn't check that... this random flipping is really strange. I uncommented the rapi.rpgBindNormalBuffer() in your py, I changed the TriList function by leeao, normals keep randomly flipped.

Quote

Also i found there is float variable> NormalShift and its value is 65537. Can be this somehow involved in byte normal conversion?

Maybe. I struggled with a similar problem mrmaller1905 presented but couldn't solve it.

edit: for comparison, createTriList() without 'else':

Edited February 14Feb 14 by shak-otay

So what if duplicate function and change algo?

So there will be 2 face indices pass. It is possible?

First you run standard one and then run with changed algo.

In principle: yes.

How do you want to change the algo? (Other than 1,2,3 2,1,3 versa 1,2,3 1,3,2)

Changed code from leeao:

def createTriList(skipList):# for testing only
    out = NoeBitStream()
    num = len(skipList)
    startDir = -1
    faceDir = startDir
    f1 = 0
    f2 = 1
    for i in range(num):
        f3 = i
        skipFlag = skipList[i]  # skip Isolated vertex
        faceDir *= -1
        if skipFlag != True:
            if f1 != f2 and f2 != f3 and f3 != f1:
                if faceDir > 0:
                    out.writeInt(f1)
                    out.writeInt(f2)
                    out.writeInt(f3)
        else:
            faceDir = startDir
        f1 = f2
        f2 = f3

    startDir = -1
    faceDir = startDir
    f1 = 0
    f2 = 1
    for i in range(num):
        f3 = i
        skipFlag = skipList[i]  # skip Isolated vertex
        faceDir *= -1
        if skipFlag != True:
            if f1 != f2 and f2 != f3 and f3 != f1:
                if faceDir <= 0:
                    out.writeInt(f2)
                    out.writeInt(f1)
                    out.writeInt(f3)
        else:
            faceDir = startDir
        f1 = f2
        f2 = f3

    return out.getBuffer()

edit: as from my last picture it's clear that the "wrong" normals don't belong to one pass.

They appear in both passes.

 

There's 215 vertex chunks, btw.

This list of vcount versa pass1 count shows some small chunks, vCount 7 for example.

...
52 43
52 36
7 4
52 40
52 38
52 39
51 38
52 36
51 38
52 41
52 38
52 38
52 44
52 39
50 44
50 36
51 37
51 34
51 39
52 32
51 30
52 37
52 30
52 29
52 39
51 39
49 37
52 41
52 47
52 38
7 3
52 32
11 6
27 20
25 19
51 36
38 26
51 40
52 38
52 38
52 32
52 28
27 13
...

The idea is to divide body..._007 (that's its name, haha) into these chunks and check the normals of each chunk.

edit 2: as you can see the problem (correct and wrong orientated normals) is in the chunks (chunk 13 of first sub mesh).

So you can't just flip normals of specific chunks.

Edited February 14Feb 14 by shak-otay

car on top use algo > f1 f2 f3 else f2 f1 f3 and car on bottom use algo > f3 f2 f1 else f1 f2 f3

So now how to combine these two algo into one

This also works

F3,F2,F1 else F1,F2,F3

and

F1,F2,F3 else F3,F2,F1

Edited February 14Feb 14 by h3x3r

Cool! But, while it's visually obvious which are "good and bad" faces it's not solvable by just combining the algos, imho.

Instead you have to take one of them and check each normal for pointing out of the mesh or inside it. Then flip the faces where the normals point inside.

These in/out algos (from AI) are Ray casting, Dot product, winding order.

The latter goes like so:

Quote

• Traverse the graph of connected faces.
• Ensure that for any two adjacent triangles, their shared edge is traversed in opposite directions (e.g., edge A->B for triangle 1, edge B->A for triangle 2).
• If they are not, flip the normal of the invalid triangle.
• Final Check: Check the orientation of one face. If it is CW (or CCW depending on your coordinate system convention), it is outside.

but I feel my math is to weak to create it...

edit: what I could do is calculate the normals' angles.

Comparing the angels of the faces of your two cars could give more insights...

Edited February 14Feb 14 by shak-otay

I noticed when triangle is fliped you need to change F1 and F2 order to F2 and F1.

# org correct 2 tris
f  27/27/27 28/28/28 29/29/29
f  29/29/29 28/28/28 30/30/30

# org fliped tris
#f  30/30/30 31/31/31 32/32/32
#f  32/32/32 31/31/31 33/33/33
 f  31/31/31 30/30/30 32/32/32
 f  31/31/31 32/32/32 33/33/33

#f  32/32/32 33/33/33 34/34/34
#f  34/34/34 33/33/33 35/35/35
 f  33/33/33 32/32/32 34/34/34
 f  33/33/33 34/34/34 35/35/35

#f  34/34/34 35/35/35 36/36/36
#f  36/36/36 35/35/35 37/37/37
 f  35/35/35 34/34/34 36/36/36
 f  35/35/35 36/36/36 37/37/37

#f  38/38/38 39/39/39 40/40/40
#f  40/40/40 39/39/39 41/41/41
 f  39/39/39 38/38/38 40/40/40
 f  39/39/39 40/40/40 41/41/41

#f  40/40/40 41/41/41 42/42/42
#f  42/42/42 41/41/41 43/43/43
 f  41/41/41 40/40/40 42/42/42
 f  41/41/41 42/42/42 43/43/43

#f  42/42/42 43/43/43 44/44/44
#f  44/44/44 45/45/45 46/46/46
 f  43/43/43 42/42/42 44/44/44
 f  45/45/45 44/44/44 46/46/46

#f  47/47/47 48/48/48 49/49/49
 f  48/48/48 47/47/47 49/49/49

 

I found that Blender versions above 2.9 have less wrong normals (only 2 here for chunk 13, but hard to see in the pic):

Can you count the wrong normals of chunk 13 in Maya, please (it's car1, not 1A btw)?

 

 

car1_1 - chunks.zip

Looks like 9 tris

Thanks - I had done some calculation using

bmesh.ops.recalc_face_normals(bm, faces=bm.faces)

Result see picture above (2 wrong normals).

Without it there's 9 wrong normals, indeed:

I've recalculated the whole model. (You may check the dae model for less wrong normals.)

 

car1, normals, recalc.zip

Edited February 14Feb 14 by shak-otay

yep this is much cleaner

there is like max 10 vrong normals

Yours on right

Edited February 14Feb 14 by h3x3r

I can pm you the py script. (Would have taken too long to create it myself so I used AI.)

And the remaining errors are not AI related but related to the complexity of the problem, imho. (Dunno whether we can solve this. Maybe Durik256 could help?)

Sure, but not sure how to rewrite it to noesis... If it's even possible...