Printable View
Hello wikiman, welcome. Thank you for your interest.
I think I echo GrumpyOldMan's heartfelt wish, any chance
of a roadmap for the headers/footers for the mesh format
or is this outside your purvue? Just being opportunistic
here, no pressure. Again, a pleasure to see you.
I'm pretty sure some are :2thumbsup:Quote:
Originally Posted by GrumpyOldMan
One of our programmers sent me this a few mins ago, hope its of some help.
Please feel free to ask another other questions. If you need more info on the mystery block, pm me with details.
// [item] means there is an array of items, usually saved as count followed by items
mesh file =
{
[Meshes],
[Materials],
BoundingSphere
}
Meshes =
{
[MeshVariation],
NumVertices,
[float2 vertex streams],
[float3 vertex streams],
[byte4 vertex streams],
[bool vertex streams], (unused for characters)
BoundingSphere,
BoneMap
}
Materials =
{
Name,
[TextureNames],
ZCompare,
ZWrite,
Culling,
AlphaBlendSettings,
[ColorParameters],
[FloatParameters],
TextureMatrix[2] (unused for characters)
}
MeshVariation =
{
GroupName,
MeshName,
[Triangles],
bool Optional,
[stream of bools] (unused for characters)
}
Triangle =
{
int16 index0, index1, index 2
}
BoneMap =
{
[Bone],
}
Bone =
{
Name,
Index
}
vertex stream
{
Semantic,
[Elements],
Name
}
Caliban, a pleasure to see you as well! Thank you for the information.
We'll try to digest this and I'm sure we'll have some questions once we
do. Any help is greatly appreciated at this point.~:)
@Casuir
Well, no luck with the obj format. It keeps crashing Milkshape 3D.
Tried a reboot and it looks like I'm clobbering one of its DLLs, probably
a buffer overrun. I'm not missing a header or anything am I? I did
vertices first:
v float float float
...
then uv coords
vt float float
...
finally triangles
g hat_01
f #/# #/# #/#
...
with the numbers the same on both sides of the slash and including
all the groups. I didn't use any other information to separate things
and of course I didn't try including anything else than this basic information.
I'm going to pursue GOM's thread for file formats. He probably used
Milkshape's native ASCII format and it worked for him. (Of course this one
gave me fits because I couldn't find a spec for it.) If I can find a format
spec I'll try that.
Hi All
Whoo-hoo, great responses from the CA team, I've pm'd Caliban with details of the mystery blocks so I'll go back and look at the header/footers.
Double Whoo-hoo, 45 mins without a reboot :laugh4: .
@KE
The main thing wrong with the OBJ format is vertex bone assignment and weighting. If you have a look at the Milkshape SDK it has file formats included. It may not be much but I can try to hang a GUI on the software I've written - it at least breaks up the MESH into component parts but with no vertex assignments.
Cheers
GrumpyOldMan
That looks ok KE, can you send me the exported obj file?
@Casuir
Hmmm, I tried but I can't find an attach file button when I hit the PM button
on your post. Could you tell me how to do this?
@GOM
Great news. You wished for a CA dev and you got two!
Can you wish for bags of gold next, please?
Edit: Actually, if Caliban would answer another question,
could you ask what format they use to export out their models
from 3dsmax. Presumably they have some outside program
that converts it to a mesh. Or they may have written their
own plugin to do it it which case the question is moot. If the
question makes sense then that is probably the format to target.
Quick observation on headers/footers. I turned off data output
in my script and just output the strings and footers for arquebusiers_lod0
and levy_spearmen_ug1_lod0. Here's the output, arquebusiers first:
Now levy_spearmen_ug1:Code:22serialization::archive
3 4 4 4 8 1 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 4 0 1 3 1 0 0 0 0 0 7 0 1 0 2 0 0 0 0 0
num_groups = 26
0 0 11 0 1 3 3 0 0 0
mesh type name: Helmet
mesh group name: hat_01
number of triangles, n = 236
0 0 0 0 0 0 0 0 0 10 0 1 0 4 0 0 0 11 0 3 0 0 0 11 0 5 0 0 0
mesh type name: Head
g head_01
0 0 0 0 0 10 0 6 0 0 0 11 0 5 0 0 0 11 0 7 0 0 0
mesh type name: Attachments
g strap_01
1 0 0 0 0 10 0 8 0 0 0 11 0 7 0 0 0 11 0 9 0 0 0mesh type name: Body
g RN_Light_Body_01
0 0 0 0 0 10 0 10 0 0 0 11 0 9 0 0 0 11 0 11 0 0 0
mesh type name: Arms
g arms_light_01
0 0 0 0 0 10 0 12 0 0 0 11 0 11 0 0 0 11 0 13 0 0 0
mesh type name: Legs
g Legs_light_01
0 0 0 0 0 10 0 14 0 0 0 11 0 13 0 0 0 11 0 15 0 0 0
mesh type name: Head
g head_02
0 0 0 0 0 10 0 16 0 0 0 11 0 15 0 0 0 11 0 17 0 0 0
mesh type name: Body
g RN_Light_Body_02
0 0 0 0 0 10 0 18 0 0 0 11 0 17 0 0 0 11 0 19 0 0 0
mesh type name: Body
g RN_Light_Body_03
0 0 0 0 0 10 0 20 0 0 0 11 0 19 0 0 0 11 0 21 0 0 0
mesh type name: Legs
g Legs_light_02
0 0 0 0 0 10 0 22 0 0 0 11 0 21 0 0 0 11 0 23 0 0 0
mesh type name: Legs
g Legs_light_03
0 0 0 0 0 10 0 24 0 0 0 11 0 23 0 0 0 11 0 25 0 0 0
mesh type name: Legs
g Legs_light_04
0 0 0 0 0 10 0 26 0 0 0 11 0 25 0 0 0 11 0 27 0 0 0
mesh type name: Head
g head_03
0 0 0 0 0 10 0 28 0 0 0 11 0 27 0 0 0 11 0 29 0 0 0
mesh type name: Head
g head_04
0 0 0 0 0 10 0 30 0 0 0 11 0 29 0 0 0 11 0 31 0 0 0
mesh type name: Head
g head_05
0 0 0 0 0 10 0 32 0 0 0 11 0 31 0 0 0 11 0 33 0 0 0
mesh type name: Head
g head_06
0 0 0 0 0 10 0 34 0 0 0 11 0 33 0 0 0 11 0 35 0 0 0
mesh type name: Helmet
g hat_02
0 0 0 0 0 10 0 36 0 0 0 11 0 35 0 0 0 11 0 37 0 0 0
mesh type name: Helmet
g hat_03
0 0 0 0 0 10 0 38 0 0 0 11 0 37 0 0 0 11 0 39 0 0 0
mesh type name: secondaryactive0
g ren sword secondary_12
0 0 0 0 0 10 0 40 0 0 0 11 0 39 0 0 0 11 0 41 0 0 0
mesh type name: secondaryactive1
g ren sword secondary_13
0 0 0 0 0 10 0 42 0 0 0 11 0 41 0 0 0 11 0 43 0 0 0
mesh type name: primaryactive0
g arquebus_32
0 0 0 0 0 10 0 44 0 0 0 11 0 43 0 0 0 11 0 45 0 0 0
mesh type name: primaryactive1
g arquebus_33
0 0 0 0 0 10 0 46 0 0 0 11 0 45 0 0 0 11 0 47 0 0 0
mesh type name: ramrod0
g hand ramrod_42
0 0 0 0 0 10 0 48 0 0 0 11 0 47 0 0 0 11 0 49 0 0 0
mesh type name: equipment20
g powderbag_43
0 0 0 0 0 10 0 50 0 0 0 11 0 49 0 0 0 11 0 51 0 0 0
mesh type name: equipment20
g powderbag_44
0 0 0 0 0 10 0 52 0 0 0 11 0 51 0 0 0 11 0 53 0 0 0
mesh type name: equipment20
g powderbag_45
0 0 0 0 0 10 0 54 0 0 0 11 0 53 0 0 0 6 0 1 0 55 0
0 0 7 0 2 0 0 0 85 19 0 0 0 0 2 0 0 0 0 0 18 0 1 0 56 0 0 0 4 0 0 0 0 0 0 0 0 0 17 0 1 0 57 0 0 0 18 0 56 0 0 0 18 0 58 0 0 0 1 0 0 0
number of vertices in vertex weights: 4949
0 0 0 0 17 0 59 0 0 0 18 0 58 0 0 0 0 0 1 0 0 0 0 0 23 0 1 0 60 0 0 0 0 0 0 0 0 0
number of vertices in vertex vectors: 4949
0 0 0 0 22 0 1 0 61 0 0 0 23 0 60 0 0 0 0 0 4 0 0 0 0 0 28 0 1 0 62 0 0 0 2 0 0 0 0 0
number of vertices in vertex bones: 4949
0 0 0 0 27 0 1 0 63 0 0 0 28 0 62 0 0 0 28 0 64 0 0 0 3 0 0 0
number of vertices in mystery block: 4949
0 0 0 0 27 0 65 0 0 0 28 0 64 0 0 0 28 0 66 0 0 0 10 0 0 0
number of vertices in mystery block: 4949
0 0 0 0 27 0 67 0 0 0 28 0 66 0 0 0 28 0 68 0 0 0 11 0 0 0
number of vertices in mystery block: 4949
0 0 0 0 27 0 69 0 0 0 28 0 68 0 0 0 0 0 0 0 0 0 0 0 0 0
0.0678303465247 0.289312928915 0.570569753647 1.44378435612
0 0 0 0 26 0 0 0 0 0
Processing bone strings
11 bone_pelvis 0
11 bone_rthigh 1
14 bone_rlowerleg 2
10 bone_rfoot 3
8 bone_abs 4
10 bone_torso 5
9 bone_head 6
8 bone_jaw 7
12 bone_eyebrow 8
14 bone_rclavical 9
14 bone_rupperarm 10
11 bone_relbow 11
10 bone_rhand 12
14 bone_lclavical 13
14 bone_lupperarm 14
11 bone_lelbow 15
10 bone_lhand 16
11 bone_lthigh 17
14 bone_llowerleg 18
10 bone_lfoot 19
13 bone_weapon01 20
11 bone_weapon 20
13 bone_weapon02 21
13 bone_weapon03 22
13 bone_shield01 22
11 bone_shield 22
3 0 1 0 70 0 0 0 4 0 1 0 0 0 0 0 1 0 0 0 0 0 39 0 1 4 71 0 0 0
number of chars 13
characterlod0
17 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 4 0 0 0 1 0 0 0 3 0 0 0
101 185 63 0 4 0 0 0 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 9 0 0 0
0 0 0 64 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 8 0 0 0 2 0 0 0 0 0 0 0 128 63 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 128 63 0 0 0 0 0 0 0 0 2 0 0 0 0 0
128 63 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 128 63 0 0 0 0 0 0
0 0 2 0 0 0 0 0 128 63 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
128 63 0 0 0 0 0 0 0 0 2 0 0 0 0 0 128 63 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 128 63 0 0 0 0 0 0 0 0 2 0 0 0 0 0 128 63 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 128 63 0 0 0 0 0 0 0 0 2 0
0 0 0 0 128 63 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 128 63 0 0
0 0 0 0 0 0 2 0 0 0 0 0 128 63 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 128 63 0 0 0 0 0 0 0 0 2 0 0 0 0 0 128 63 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 128 63 0 0 0 0 0 0 0 0 38 0 1 0 72 0
0 0 39 0 71 0 0 0
0.0678303465247 0.289312928915 0.570569753647 1.44378435612tell says we are at 257826
bytecount says we are at 257826
Bytecount is now 257826
I've put in red some interesting differences. The arquebusiers have ONECode:22serialization::archive
3 4 4 4 8 1 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 4 0 1 3 1 0 0 0 0 0 7 0 1 0 2 0 0 0 0 0
num_groups = 25
0 0 11 0 1 3 3 0 0 0
mesh type name: Hands
mesh group name: hands_01
number of triangles, n = 202
0 0 0 0 0 0 0 0 0 10 0 1 0 4 0 0 0 11 0 3 0 0 0 11 0 5 0 0 0
mesh type name: Head
g head_02
0 0 0 0 0 10 0 6 0 0 0 11 0 5 0 0 0 11 0 7 0 0 0
mesh type name: Head
g head_05
0 0 0 0 0 10 0 8 0 0 0 11 0 7 0 0 0 11 0 9 0 0 0
mesh type name: Head
g head_04
0 0 0 0 0 10 0 10 0 0 0 11 0 9 0 0 0 11 0 11 0 0 0
mesh type name: Legs
g Legs_01
0 0 0 0 0 10 0 12 0 0 0 11 0 11 0 0 0 11 0 13 0 0 0
mesh type name: Head
g head_01
0 0 0 0 0 10 0 14 0 0 0 11 0 13 0 0 0 11 0 15 0 0 0
mesh type name: Arms
g Arms_01
0 0 0 0 0 10 0 16 0 0 0 11 0 15 0 0 0 11 0 17 0 0 0
mesh type name: Arms
g Arms_02
0 0 0 0 0 10 0 18 0 0 0 11 0 17 0 0 0 11 0 19 0 0 0
mesh type name: Arms
g Arms_03
0 0 0 0 0 10 0 20 0 0 0 11 0 19 0 0 0 11 0 21 0 0 0
mesh type name: Arms
g Arms_04
0 0 0 0 0 10 0 22 0 0 0 11 0 21 0 0 0 11 0 23 0 0 0
mesh type name: Legs
g Legs_02
0 0 0 0 0 10 0 24 0 0 0 11 0 23 0 0 0 11 0 25 0 0 0
mesh type name: Legs
g Legs_03
0 0 0 0 0 10 0 26 0 0 0 11 0 25 0 0 0 11 0 27 0 0 0
mesh type name: Legs
g Legs_04
0 0 0 0 0 10 0 28 0 0 0 11 0 27 0 0 0 11 0 29 0 0 0
mesh type name: Hands
g hands_02
0 0 0 0 0 10 0 30 0 0 0 11 0 29 0 0 0 11 0 31 0 0 0
mesh type name: Head
g head_06
0 0 0 0 0 10 0 32 0 0 0 11 0 31 0 0 0 11 0 33 0 0 0
mesh type name: Attachments3
g teeth
0 0 0 0 0 10 0 34 0 0 0 11 0 33 0 0 0 11 0 35 0 0 0
mesh type name: Body
g Padded_body_01
0 0 0 0 0 10 0 36 0 0 0 11 0 35 0 0 0 11 0 37 0 0 0
mesh type name: Body
g Padded_body_02
0 0 0 0 0 10 0 38 0 0 0 11 0 37 0 0 0 11 0 39 0 0 0
mesh type name: Body
g Padded_body_03
0 0 0 0 0 10 0 40 0 0 0 11 0 39 0 0 0 11 0 41 0 0 0
mesh type name: primaryactive0
g long spear_40
0 0 0 0 0 10 0 42 0 0 0 11 0 41 0 0 0 11 0 43 0 0 0
mesh type name: primaryactive1
g long spear_41
0 0 0 0 0 10 0 44 0 0 0 11 0 43 0 0 0 11 0 45 0 0 0
mesh type name: shield0
g kite simple_64
0 0 0 0 0 10 0 46 0 0 0 11 0 45 0 0 0 11 0 47 0 0 0
mesh type name: shield0
g kite simple_65
0 0 0 0 0 10 0 48 0 0 0 11 0 47 0 0 0 11 0 49 0 0 0
mesh type name: shield0
g kite simple_66
0 0 0 0 0 10 0 50 0 0 0 11 0 49 0 0 0 11 0 51 0 0 0
mesh type name: shield0
g kite simple_67
0 0 0 0 0 10 0 52 0 0 0 11 0 51 0 0 0 6 0 1 0 53 0
0 0 7 0 2 0 0 0 44 15 0 0 0 0 2 0 0 0 0 0 18 0 1 0 54 0 0 0 4 0 0 0 0 0 0 0 0 0 17 0 1 0 55 0 0 0 18 0 54 0 0 0 18 0 56 0 0 0 1 0 0 0
number of vertices in vertex weights: 3884
0 0 0 0 17 0 57 0 0 0 18 0 56 0 0 0 0 0 1 0 0 0 0 0 23 0 1 0 58 0 0 0 0 0 0 0 0 0
number of vertices in vertex vectors: 3884
0 0 0 0 22 0 1 0 59 0 0 0 23 0 58 0 0 0 0 0 4 0 0 0 0 0 28 0 1 0 60 0 0 0 2 0 0 0 0 0
number of vertices in vertex bones: 3884
0 0 0 0 27 0 1 0 61 0 0 0 28 0 60 0 0 0 28 0 62 0 0 0 3 0 0 0
number of vertices in mystery block: 3884
0 0 0 0 27 0 63 0 0 0 28 0 62 0 0 0 28 0 64 0 0 0 10 0 0 0
number of vertices in mystery block: 3884
0 0 0 0 27 0 65 0 0 0 28 0 64 0 0 0 28 0 66 0 0 0 11 0 0 0
number of vertices in mystery block: 3884
0 0 0 0 27 0 67 0 0 0 28 0 66 0 0 0 0 0 0 0 0 0 0 0 0 0
0.470658034086 0.434560090303 0.114010438323 1.69914269447
0 0 0 0 26 0 0 0 0 0
Processing bone strings
11 bone_pelvis 0
11 bone_rthigh 1
14 bone_rlowerleg 2
10 bone_rfoot 3
8 bone_abs 4
10 bone_torso 5
9 bone_head 6
8 bone_jaw 7
12 bone_eyebrow 8
14 bone_rclavical 9
14 bone_rupperarm 10
11 bone_relbow 11
10 bone_rhand 12
14 bone_lclavical 13
14 bone_lupperarm 14
11 bone_lelbow 15
10 bone_lhand 16
11 bone_lthigh 17
14 bone_llowerleg 18
10 bone_lfoot 19
13 bone_weapon01 20
11 bone_weapon 20
13 bone_weapon02 21
13 bone_weapon03 22
13 bone_shield01 22
11 bone_shield 22
3 0 1 0 68 0 0 0 4 0 1 0 0 0 0 0 1 0 0 0 0 0 39 0 1 4 69 0 0 0
number of chars 13
characterlod0
17 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 4 0 0 0 1 0 0 0 3 0 0 0
101 185 63 0 4 0 0 0 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 9 0 0 0
0 0 0 64 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 8 0 0 0 2 0 0 0 0 0 0 0 128 63 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 128 63 0 0 0 0 0 0 0 0 2 0 0 0 0 0
128 63 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 128 63 0 0 0 0 0 0
0 0 2 0 0 0 0 0 128 63 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
128 63 0 0 0 0 0 0 0 0 2 0 0 0 0 0 128 63 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 128 63 0 0 0 0 0 0 0 0 2 0 0 0 0 0 128 63 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 128 63 0 0 0 0 0 0 0 0 2 0
0 0 0 0 128 63 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 128 63 0 0
0 0 0 0 0 0 2 0 0 0 0 0 128 63 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 128 63 0 0 0 0 0 0 0 0 2 0 0 0 0 0 128 63 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 128 63 0 0 0 0 0 0 0 0 38 0 1 0 70 0
0 0 39 0 69 0 0 0
0.470658034086 0.434560090303 0.114010438323 1.69914269447
tell says we are at 204563
bytecount says we are at 204563
Bytecount is now 204563
header/footer with a 1 0 0 0 instead of 0 0 0 0 starting the line. Very
strange. After the powderbag entry the arquebusiers have a 85 19 0 0
in the third group of 4 bytes, this is 4949 the count of vertices. The
levy_spearmen_ug1 have 44 15 0 0 which is 3884 or their number of vertices.
This is understandable. Finally each has a set of four floats before the bones
and at the very end of the file, the last 16 bytes. The numbers are the
same in both places but different between the units.
Oh, and the arquebusiers have one more triangle group than the levy_spearmen_ug1 so their sequence counts go up 2 higher.
These are the similarities and differences I can spot right now.
These are both infantry types, I'll try a cavalry unit at lunch to
see if there are more differences there.
I've pm'd you with my email address, dont think these forums allow attachments. The format they used to export was .gr2:
http://www.radgametools.com/granny/faq.html
Looking at the files calibans provided and ones that seem to be leftovers in the packfiles I'm guessing all models are exported seperatly as gr2s from max the attachment sets are compiled by another program and then the unit mesh is compiled via xmls like the one caliban provided us with. gr2's a licensed format hence the problems with giving us a model exporter.
@Casuir
I've e-mailed you the obj file. Thanks for the explanation
on gr2s, this is slowly making sense now.
Got it cheers, opens up in 3dexplorer ok but the vertex data is messed up:
https://img235.imageshack.us/img235/8724/objnl8.th.png
My guess would be python might be having trouble converting the floats? If you look in the file theres some odd values like: -8.65171934095e-010
Hard to tell if u.v. data is right but it looks like it might be ok, texture needs to be flipped vertically though.
Sent you another one. Did an if statement on any
vertex point being less than 1.0e-06. If so, made it
0.0. This got rid of all the small floats in scientific
notation. Didn't know what to do about the uv data,
I don't know a Python flip up down command to
reverse it.
Fraid its no better. Think I may have been hasty in blaming python, the original file looks fine when viewed as just vertexs, problem seems to be the faces. The first mesh to be extracted says it has 2 two sided polys and 1 one sided, think this may be of this part:
f 46/46 5/5 0/0
f 0/0 41/41 46/46
f 45/45 4/4 3/3
f 3/3 44/44 45/45
f 44/44 3/3 2/2
f 2/2 43/43 44/44
f 43/43 2/2 170/170
f 170/170 169/169 43/43
f 42/42 1/1 6/6
f 6/6 48/48 42/42
f 49/49 7/7 5/5
f 5/5 47/47 49/49
f 41/41 0/0 4/4
Seems the vertexs are numbered in the mesh file 0-4948 while in the obj they're 1-4949, adding 1 to each value in the mesh part should (hopefully) solve the problem. I think you could take out the if statement, doesnt seem to have any noticeable difference on placement but the files missing a vertex and face.
Ok, this shouldn't take too long.
https://img178.imageshack.us/img178/5018/obj2qm0.th.png
Nice work. :2thumbsup:
Dunno what you'd do about the texture co-ords, the texture wont fit even if you flip the vertical as the co-ords are given for the attachment and unit texture as one. Not really much trouble to flip the tex when you have to resize it anyways.
Very nice Casuir! A productive day all around.~:)
Pretty much correct. The models and variations are marked up in 3dsmax along with the material type (unit lod0, unit lod1, unit lod2) and exported out to .gr2 format. We then setup the unit xml files which contain things like the attachment sets, skeletons to be used and convert it via an external conversion proccess.Quote:
Originally Posted by Casuir
These images should give you an idea of how it looks in 3dsmax:
https://img151.imageshack.us/my.php?...3dsmax1zj0.jpg
https://img151.imageshack.us/my.php?...3dsmax2nm5.jpg
https://img523.imageshack.us/my.php?i...dsmax2asm0.jpg
https://img523.imageshack.us/my.php?i...ertypesth6.jpg
The Mystery Blocks
A reply to Grumpy's question about the mystery blocks:
I read his file decription again and it certainly seems it is the unused bool stream. Just before them there should be number 1 somewhere (number of these streams) followed by number of vertices (this number is the same for all streams) followed by bool values themselves. He should be able to just change that 1 to 0 and then remove count + bool values completely. But I'd have to see the file to be sure, I don't really remember.
I'll have a definate answer on this soon after a bit of investigation.
Thank you Caliban. Here is a snippet containing the header/footer
bytes (byte values in decimal) just before reading the first block within
the mystery block.
Code:0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0 27 0 1 0 63 0 0 0 28 0 62 0 0 0 28 0 64 0 0 0 3 0 0 0
number of vertices in mystery block: 4949
79 25 186 0
181 17 162 0
159 18 185 0
130 20 196 0
105 23 197 0
54 25 153 0
The zeros before the header/footer are the last of the vertex bones group.
I've marked in red the possible unit flag value. This looks like what your
source is describing.
@GOM and Casuir
I've got Milkshape 3D working on the arquebusier_lod0
in the obj format. It must have been either the 0-based
indexing or not passing the triangles as #/# #/# #/#
that killed me before. The file I sent Casuir reads just
fine.
Hi Guys
Things really seem to be rolling along now. Many thanks to Caliban for chasing up those details for us.
@KE
One thing I managed to find was the "1" in the belt header for the arquebusier. I've looked through a number of meshes and it seems to indicate with Attachment type groups that there is only one of that type and it is compulsory.
Also with the mystery group/s I think the four byte "3" just before the number of vertices may be more significant - remember there are three streams in the high lod files. The lower lod files have only one stream but still have a "3" in this spot - maybe same stream used three times?
The four float values repeated near the end of the files, looking at one of the replies from Caliban,
indicates that there are bounding sphere values but I haven't got it straight in my head about these values yet.Quote:
Meshes =
{
[MeshVariation],
NumVertices,
[float2 vertex streams],
[float3 vertex streams],
[byte4 vertex streams],
[bool vertex streams], (unused for characters)
BoundingSphere,
BoneMap
}
Currently I'm working on a program to convert Meshes to MS3D binary files so that the vertex weighting can be retained. One disadvantage of this is that Milkshape stores weights as integer percentages so I have to covert a Mesh weight value of .674352 to 67%.
There are a number of options at this point -
1. Go with a Milkshape plugin or utility
2. Go with a 3DS Max plugin or utility (I have no knowledge of Maxscript) :wall:
3. Go for a dedicated Mesh disassembler/assembler
Any thoughts from anybody?
Cheers, keep up the really great work guys!!
GrumpyOldMan
Well, I take the point of view that you are the lead on this, of course,
so I'm willing to do what I can to help whichever way you want to
procede. Personally, I'd like to see a scheme or utility which makes
mesh creation and inclusion into the game as widely available as practical,
in other words, so people like me who's wives would kill us if we told them
we were buying a $3500 3D graphics application to support our $50 game
habit could still play in the game. (Just a humorous aside there.)
Seriously, of course the target group are the 3dsmax users but if there
is no real technical obstacle to programs like Milkshape 3D (with the
next release supporting vertex weighting) perhaps the best would be
a standalone that goes to a file format that both can import and export.
(I'm not excluding any other 3D programs, I just don't know this area
enough to make any judgements.)
At the moment, it seems like we possess a diode: information can come
out of a .mesh file and can be reworked into any number of formats depending
on the target application. The difficult part, but seemingly quite doable
with information from CA, is reversing the diode to make the information go
back into the mesh file.
I don't know your programming preferences, C, C++, Python, etc? I can do
MatLab (don't laugh), Python, Java, Intel assembler (what's the point), and
C but very little C++. I haven't a clue at what's involved in a plug-in which
is why I lean towards a standalone. I see a user as being a great graphics
artist but not necessarily a computer savant who could open a DOS box
and run a conversion utility to go from a filename.mesh to filename.xxx and
then import into his application. And in reverse filename.xxx to filename.mesh
after he's made his mods. Anyway, just my two cents.:2cents:
Wow you guys are just amazing! Keep this fantastic work up!
On the other hand :( Caliban, what happened with the official tool? Is it going to turn out that it won't be released at all?
Unfortuantly there won't be an official tool anytime soon, my guess is that you guys are going to crack it before we do. I will be helping grumpy and the others out as much as I can in the meantime.Quote:
Originally Posted by SigniferOne
Really good work guys. You'll make it into the history books of Vercingetorix when you succeed :grin:
Thanks a lot for your help Caliban :bow:
Reading this has brought joy to my cold Friday morning.
are there any downloadable plug ins/scripts for either milkshape or 3Dmax yet?
@ KE and GOM
If possible, having something that would be available to many users would be great...
I have run into a dead end with 3dsmax... I can't even afford the student edition ... and with having five kids, my wife would kill me as well... which last i looked is around 600 or 700$, and I am not totally convinced that that would work with the models (I just revealed how much I know about this 3d animation stuff...)...:sweatdrop:
Anyway... my dream from the beginning was just being able to switch attachments on units... moving helmets around, weapons etc... everything else is there to make new units or change existing ones... textures, animations etc... CA has done great in opening a lot of this up to many modders and aspiring graphics/animation newbies...
I can understand if 3dsmax would be better, but something like MilkShape 3D would be awesome... something that would allow many of us rather than a few to have access to change stuff. (Just my 2 cents worth...)
GOM, KE, Casuir - All of you are doing a great service to the TW Modding community... your sharing of information, and working through this is not only exciting, but also educational.
Forgive me for interjecting this in between the technical work...
Thanks guys!!! :beam:
AT
Hi AT
I hear you on this one. I too would probably
only want to do customizations and tweaks
and maybe spend a month of weekends doing one
dream unit just to do it.
I'm hoping that Caliban can confirm that the mystery data
really is an unused boolean stream and can be removed
and simply set that 1 to a 0. If this is true then its only the
vertex weighting that's an issue (with Milkshape). Take a look here
http://www.chumba.ch/chumbalum-soft/...ad.php?t=18884
Mete says he's working on adding vertex weights for the 1.7.11 release.
All that's left then is the logic of the header/footers which is what
GrumpyOldMan is looking at now from his last post. His observation
about the floats being the bounding sphere makes sense, it looks
like it might be x,y,z and radius. The x,y,z being sort of the geometric
center of the form and the radius being a trigger for fight animations?
Don't know, just guessing.
Hope to do more this weekend. The real world has been
chewing up my time the last few days.~:)
Hi Guys
I'm looking more at the Milkshape option now after the comments. The utility I'm planning at the moment will give an option of extracting the whole figure with bones and vertex weightings, or just chopping the .mesh into component parts. The main difficulty with component parts is that, the way Milkshape works, if you merge component parts to a figure you lose the vertex assignments and weightings on the component part but I could spit out a text file with that info and it could be manually updated. Otherwise the other option is a purpose-written .mesh chopshop which retains all the info but will take longer to write.
It's my youngest boy's birthday this weekend so there's not going to be too much progress :juggle2: .
Cheers
GrumpyOldMan
Sounds really good! Thanks for the update and wish your
youngest a very happy birthday.:balloon2: