Jump to content

Recommended Posts

  • Engineer
Posted (edited)

You could use the parameters from the first picture here (H2O file for hex2obj).

0x2F3A72 8589
Vb1
44 16
0x120B84 20792
020000
0x0 255

 

Or use the bms script from h3x3r which produces 3 Index and 72 vertex buffers from the Camaro.

The real magic is in finding out which indices fit for which vertex blocks. I.e. finding the starting addresses of sub index blocks.

Camaro chassis

(Will need some fine tuning and scaling but basically it's the chassis.)

Camaro chassis scaling

Edited by shak-otay
  • Like 1
  • Engineer
Posted (edited)

camaro_face_index_blocks_stopp_start

camaro_interior

Still dividing face index blocks manually...

 

edit: could anyone make sense of the IDs? Example:

|BODY_COL|BODY|BOOST_L2|BOOST_L2_EXTERIOR_ONLY

is addressed/linked to in two ways here

# 0xf946: 10000 449b 1 0 be8 #58 28 35 b6 4e f4 1e 0 58 0x1336e

by the ID #58 28 35 b6 4e f4 and by the offset 0x1336e.

There are other IDs (or signatures) which seem to mark  a (lod?) group, like 010057d12351.

Edited by shak-otay
  • Like 1
  • Engineer
Posted (edited)

Couldn't find a sense of logic here: both face index blocks are far, far away from each other:

Camaro_checking_FI_blocks

 

A good trick is to find/reduce a vertex block to one module, such as the cabin here.  Then find the suiting face index block dependent on the vertex count of that module:

camaro cabin (and point cloud)

---------------

Chevi_Camaro-parts-missing

Edited by shak-otay
  • Like 1
  • 3 weeks later...
  • Engineer
Posted

My turn... LaFerrari FXXK but it missing 3 things.

Tires. I was able get only uv :(

Back glass. Same, only uv 😞

And lastly scale factor. Not sure where to get. I found one but it wasn't even close.

laferrari-fxxk.jpg

  • Like 1
  • Engineer
Posted (edited)

I'm using an estimated scale factor of 2.2

btw, the connection between mesh names and vertex blocks - did you get them by using the ids?

If so, how?

Edited by shak-otay
  • Engineer
Posted (edited)

As I said before it's stored in *.Mesh file.

For example file > ferrari_laferrari_fxxk\intermediates\vehicles\art\vehicles\ferrari_laferrari_fxxk\maya\ferrari_laferrari_fxxk_exportbackup.mb\_BODY_COL_BODY_BODYShape.Mesh

I have a template which prints info about vertex block and index block.

     Model Index: 0
Vertex Buffer Id: 4060042755
 Index Buffer Id: 3886391541
    Vertex Count: 12939
    Index Offset: 28
     Index Count: 120

    Vertex Count: 12895
    Index Offset: 268
     Index Count: 216

    Vertex Count: 12817
    Index Offset: 700
     Index Count: 1242

    Vertex Count: 12499
    Index Offset: 3184
     Index Count: 10584

    Vertex Count: 10210
    Index Offset: 24352
     Index Count: 18288

    Vertex Count: 6477
    Index Offset: 60928
     Index Count: 3168

    Vertex Count: 5328
    Index Offset: 67264
     Index Count: 1752

    Vertex Count: 4494
    Index Offset: 70768
     Index Count: 12822

    Vertex Count: 567
    Index Offset: 96412
     Index Count: 2016

So i combine 4060042755.VertexBuffer and 3886391541.IndexBuffer and print *.obj from given values. Index offset is header size 28 + given offset. Vertex offset/count doesn't matter since it's controlled by indices. I just print whole *.VertexBuffer.

Most messy thing there is stride order. For example stride 44 has 7 types.

 

EDiT: I just realized that there is also collision vertex buffer. So here we go... tire

image.thumb.png.2a43ef498d9fcf49724b930b5d7142d9.png

Also realized that collision has correct scale factor and it has a same amount of vertices/indices. But no uv or normals.

Edited by h3x3r
  • Thanks 1
  • Engineer
Posted
1 hour ago, h3x3r said:

As I said before it's stored in *.Mesh file.

Well, see. Must have overread that. Had/used the rpk file only.

What a waste of time and life...

Thanks anyways!

  • Engineer
Posted (edited)

Well it start to be tricky. I noticed that *.HierArchy is constructor for collision meshes. It has matrix4x4. Also collision meshes uses only 3 floats all the time. So there is no confusion in order type. But it lack uv's a normals somtimes.

So my best bet is output all collision meshes then extract uv's and merge it together. Which will be pain in ass without automation.

EDiT: So far so good... Collision mesh. Some parts must be corrected with matrix.

coll.jpg

Assembled...

coll0.jpg

Edited by h3x3r
  • Like 5
  • 4 weeks later...
  • 2 months later...
  • 3 weeks later...
Posted
On 16.07.2024 at 12:34, h3x3r said:

Ну, это начинает быть сложным. Я заметил, что *.HierArchy - это конструктор для сеток столкновений. У него есть matrix4x4. Также сетки столкновений используют только 3 float все время. Так что нет путаницы в типе порядка. Но иногда ему не хватает uv и нормалей.

Так что мой лучший выбор - вывести все сетки столкновений, затем извлечь UV и объединить их вместе. Что будет головной болью без автоматизации.

EDiT: Пока все хорошо... Сетка столкновений. Некоторые части нужно исправить с помощью матрицы.

кол.jpg

Собрано...

coll0.jpg

Hi, I'm new to this topic and didn't quite understand what you did with the rpk file to convert it to a 3d model, I would be very grateful if you could tell me in more detail for beginners what can be done with the rpk to convert it to a 3d model. How working templates for 010 editor?

  • 3 months later...
  • Engineer
Posted (edited)

Hi, Can somebody please figure out vertex normals. They should be byte. But not sure. They are in 3848536924.VertexBuffer.

It's the last thing i need to finish my 010 Editor template exporter.

Here is info:

612424467.VertexBuffer
Vertices
Offset > 0x1C, Stride > 12, Vertex count > 7412 Data Type > Float

3848536924.VertexBuffer
Normals, UV, etc
Offset > 0x1C, Stride > 20, Vertex count > 7412

2139299717.IndexBuffer
Indices
Offset > 0xF5DC4, Index Count > 4320, Data type > uint16

Thanks in advance.

f40_normals.7z

EDiT: Tried this one but it doesn't yield nothing good

byte bx = Var0, by = Var1, bz = Var2;
double length = Math.Sqrt((bx * bx) + (by * by) + (bz * bz));
double dx = bx / length, dy = by / length, dz = bz / length;

EDiT: I got some clues but not sure how they are converted. There is some unknown after x,y,z. maybe it's somehow involved in conversion.

I can see some patern in it. 

001 vn -78 -75 30  	unknown 48  >  vn 0.850738 -0.162228 -0.499926
002 vn -88 -95 46  	unknown 47  >  vn 0.830714 -0.115664 -0.544552
003 vn -88 21 -81  	unknown 46  >  vn 0.830885 -0.172438 -0.529052
004 vn -88 53 -50  	unknown 47  >  vn 0.830573 -0.225279 -0.509311
005 vn -78 37 -97  	unknown 47  >  vn 0.850253 -0.107755 -0.515227
006 vn -3 -47 -81  	unknown 61  >  vn 0.996954 -0.023489 -0.074376
007 vn -3 -63 -49  	unknown 61  >  vn 0.997029 -0.031295 -0.070382
008 vn -78 77 -66  	unknown 48  >  vn 0.850758 -0.213692 -0.480152
009 vn -3 41 0     	unknown 2   >  vn 0.997836 0.019600 0.062759
010 vn -3 -31 -97  	unknown 61  >  vn 0.996948 -0.016643 -0.076276
011 vn -3 -15 -97  	unknown 61  >  vn 0.997050 -0.007840 -0.076350
012 vn -78 -111 95  unknown 47  >  vn 0.850449 -0.054870 -0.523188
013 vn -88 -115 95  unknown 46  >  vn 0.830468 -0.056695 -0.554173
014 vn -3 -79 -17   unknown 61  >  vn 0.997009 -0.039206 -0.066607
015 vn -78 -23 125  unknown 49  >  vn 0.850203 -0.262448 -0.456372
016 vn -88 -55 -83  unknown 48  >  vn 0.830695 -0.278314 -0.482170
017 vn -3 57 -16   	unknown 1   >  vn 0.997786 0.027350 0.060626
018 vn -3 69 -48   	unknown 1   >  vn 0.997821 0.033377 0.056907
019 vn -3 29 32    	unknown 2   >  vn 0.997684 0.013718 0.066627
020 vn -31 -43 48  	unknown 10  >  vn 0.941970 0.103787 0.319252

 

Edited by h3x3r

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...