Hello,i have done some resherch about the flie and written a noesis plugin to export it.

But i have some problems with reading vertex and face,using rapi.

The vertecies are stored by each model,but the faces are stored by the matial.

So,i use rapi reading all vertex then read the face tristrips individually.

When consturct model,it can`t get the right weight(For example:char3d_ta.MUA).

May be the rapi ignore the vertecies that are not active in context.

I upload a simple model file,a model with problem and noesis plugin.

Seeking for some help,thanks.

 

MUA.7z

Hello, usually Durik256 is known to solve such problems.

I don't have deeper insights to Noesis so I exported the model imported with your script to smd and re-imported it to blender.

Then I used a script from here to get an overview. Maybe it helps.

edit: for reference you'll need a log from the char3D_ta.MUA, of course, like so:

0x1af040
 14.643538 136.755371 10.132233   14.000000 15.000000 -1.000000   0.677071 0.322929 -1.000000
 33.295593 180.019730 -37.910057   15.000000 14.000000 6.000000   0.864654 0.124982 0.010365

...

 24.132101 290.010254 -162.984772   6.000000 15.000000 -1.000000   0.951879 0.048121 -1.000000
 25.731476 305.806091 -196.036621   6.000000 -1.000000 -1.000000   1.000000 -1.000000 -1.000000

Lines are vertex boneID1 boneID2 boneID3 w1 w2 w3

(First -1.0 in the first line indicates that there's 2 bones only "connected" to that vertex as you surely know.)

0.677+0.323 sums up to 1.0, last -1.0 to be ignored.

A way to solve the issue (without understanding it from my side) would be to connect the boneIDs and weights from the log with the vertex groups in blender.

(That's the idea, may be wrong.)

Edited June 24, 20251 yr by shak-otay

8 hours ago, shak-otay said:

Hello, usually Durik256 is known to solve such problems.

I don't have deeper insights to Noesis so I exported the model imported with your script to smd and re-imported it to blender.

Then I used a script from here to get an overview. Maybe it helps.

edit: for reference you'll need a log from the char3D_ta.MUA, of course, like so:

0x1af040
 14.643538 136.755371 10.132233   14.000000 15.000000 -1.000000   0.677071 0.322929 -1.000000
 33.295593 180.019730 -37.910057   15.000000 14.000000 6.000000   0.864654 0.124982 0.010365

...

 24.132101 290.010254 -162.984772   6.000000 15.000000 -1.000000   0.951879 0.048121 -1.000000
 25.731476 305.806091 -196.036621   6.000000 -1.000000 -1.000000   1.000000 -1.000000 -1.000000

Lines are vertex boneID1 boneID2 boneID3 w1 w2 w3

(First -1.0 in the first line indicates that there's 2 bones only "connected" to that vertex as you surely know.)

0.677+0.323 sums up to 1.0, last -1.0 to be ignored.

A way to solve the issue (without understanding it from my side) would be to connect the boneIDs and weights from the log with the vertex groups in blender.

(That's the idea, may be wrong.)

Thanks for your work.

But i don`t think the boneID -1 is the problem,it works fine with other model.

I used rapi.rpgGetVertexCount() to check how many vertecies in contex,and the print value is bigger than it should be.

3 hours ago, tl00000 said:

Thanks for your work.

But i don`t think the boneID -1 is the problem,

I don't think so, too. I just mentioned the -1.0 because it could confuse people.

The problem is the way how the vertices and boneIds/weights are connected in the Noesis script.

(I thought that was clear.)

It's a boring task but comparing the vertexIDs and weights in the Model.txt file with those in the mentioned log from the MUA file will reveal where it goes wrong

(not why, of course).

(More interesting for me: "connecting" vertices with weights in blender to understand how it works other than having it hidden in a rapi function.)

edit because I'm not a python fan I have to search how others are dealing with vertex groups/weights.

Edited June 25, 20251 yr by shak-otay

5 hours ago, shak-otay said:

I don't think so, too. I just mentioned the -1.0 because it could confuse people.

The problem is the way how the vertices and boneIds/weights are connected in the Noesis script.

(I thought that was clear.)

It's a boring task but comparing the vertexIDs and weights in the Model.txt file with those in the mentioned log from the MUA file will reveal where it goes wrong

(not why, of course).

(More interesting for me: "connecting" vertices with weights in blender to understand how it works other than having it hidden in a rapi function.)

edit because I'm not a python fan I have to search how others are dealing with vertex groups/weights.

OK,i will try blender later.

Dunno, whether it's an issue or my usual problems with blender, (not all scripts work with all versions, etc) ...

2 thirds of vertex groups (from number 36 on) don't have weights assigned

edit: this seems to be a real issue (not of the script)

Strangely the vertex block in the MUA holds no boneID > 35. That's the reason why the max boneID in the vertex groups of the exported smd is 35 only, too,

although there's 91 bones in the char3D_ta.MUA file.

(There's a small chance that the boneIDs 37 to 91 are located in the vertex block of a lower body MUA?)

 

From smd:

3
  9 581.382629 -10.273155 -585.296387 -0.571330 -0.579106 -0.581565 0.740624 0.374967 3 9 1.000000 35 0.000000 0 0.000000
  9 585.635925 1.536335 -584.953857 -0.578914 0.564260 -0.588617 0.739690 0.388446 3 9 1.000000 35 0.000000 0 0.000000
  35 585.722290 0.170201 -587.624512 -0.579951 0.565400 -0.586498 0.736193 0.387031 3 35 1.000000 9 0.000000 0 0.000000
3
  35 595.949463 0.208918 -586.367188 0.568319 0.569574 -0.593800 0.734050 0.409280 3 35 1.000000 9 0.000000 0 0.000000
  35 585.722290 0.170201 -587.624512 -0.579951 0.565400 -0.586498 0.736193 0.387031 3 35 1.000000 9 0.000000 0 0.000000
  9 585.635925 1.536335 -584.953857 -0.578914 0.564260 -0.588617 0.739690 0.388446 3 9 1.000000 35 0.000000 0 0.000000

Edited June 26, 20251 yr by shak-otay

22 hours ago, shak-otay said:

Dunno, whether it's an issue or my usual problems with blender, (not all scripts work with all versions, etc) ...

2 thirds of vertex groups (from number 36 on) don't have weights assigned

edit: this seems to be a real issue (not of the script)

Strangely the vertex block in the MUA holds no boneID > 35. That's the reason why the max boneID in the vertex groups of the exported smd is 35 only, too,

although there's 91 bones in the char3D_ta.MUA file.

(There's a small chance that the boneIDs 37 to 91 are located in the vertex block of a lower body MUA?)

 

From smd:

3
  9 581.382629 -10.273155 -585.296387 -0.571330 -0.579106 -0.581565 0.740624 0.374967 3 9 1.000000 35 0.000000 0 0.000000
  9 585.635925 1.536335 -584.953857 -0.578914 0.564260 -0.588617 0.739690 0.388446 3 9 1.000000 35 0.000000 0 0.000000
  35 585.722290 0.170201 -587.624512 -0.579951 0.565400 -0.586498 0.736193 0.387031 3 35 1.000000 9 0.000000 0 0.000000
3
  35 595.949463 0.208918 -586.367188 0.568319 0.569574 -0.593800 0.734050 0.409280 3 35 1.000000 9 0.000000 0 0.000000
  35 585.722290 0.170201 -587.624512 -0.579951 0.565400 -0.586498 0.736193 0.387031 3 35 1.000000 9 0.000000 0 0.000000
  9 585.635925 1.536335 -584.953857 -0.578914 0.564260 -0.588617 0.739690 0.388446 3 9 1.000000 35 0.000000 0 0.000000

You said right, boneID only <= 35.Not sure why MUA file store weight like this.

I will do more test in game.

I exported the vertices and their IDs of the vertex group of a forearm and compared them to the logged vertices from the MUA file (where I assumed to take the line numbers as the IDs )

and had no match. (when selecting vertex groups their names and which vertices are highlighted usually doesn't match, too, btw )

(Just in case, if someone is confused about what I'm doing; just trying to learn what I missed 10 years.)

On 6/25/2025 at 8:05 AM, tl00000 said:

I used rapi.rpgGetVertexCount() to check how many vertecies in contex,and the print value is bigger than it should be.

 

That's no vertnums (except for the 8706), that's the count of face indices. The vertex count of the first sub mesh is 3109:

edit: I reduced it to one sub mesh (more or less) by adding these lines:

            if GIndex != 0:
                GFNum[GIndex] = 3

but it still moves odd.

Edited June 26, 20251 yr by shak-otay