Mesh/Cas/Engine - MaxScript version of GOAT tool

[kompadre]

Someone noticed difference in battle about this issue ? collision interpretation is true or in game the collision don't match with bounding sphere ?

In Milkshape we have MAIN COMMENT. It is only 4 lines long.

Example =
"-0.0157791990787
0.291247993708
0.222363993526
1.31368005276
/
"
KE wrotes in his tutorial - those numbers define some sphere...
Are You talking about that?

I've testing for some time different combination - and it seems that specular(on textures) slightly different

[johnwhile]

boh, i make some test now, i changed radius for both sphere and seam that don't change nothing... in the next release i will delete these spheres, the script will auto-calculte the best boundingsphere.
Yes, KE write the bounding sphere as comment, but in the mesh there are two identical bounding sphere...

[kompadre]

boh, i make some test now, i changed radius for both sphere and seam that don't change nothing... in the next release i will delete these spheres, the script will auto-calculte the best boundingsphere.
Yes, KE write the bounding sphere as comment, but in the mesh there are two identical bounding sphere...

That will be cool! More simplicity, more clearness - more comfort.
But your tools already VERY COOL and suitable!

Hmm... and I'm only now understand that you've already upgrade tools to r38.2 ....
I've only r38 - that's why it not working

[johnwhile]

uhm... stupid maxscript... you must delete the old script folder, restart 3dstudio and run the script (r39).

Now "mesh_" and "collision_boundingsphere" will not be created, when saving the script use the best bounding sphere algorithm as default value, is little slow than first what use 3dstudio's boudingbox, but mesh soldier are smaller than building, in fact in the other script you can change bounding method..... but this is not important.

Only for a future test : if you create "mesh_" and "collision_boundingsphere" the script use these as spheres.

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

i must testing but i will made a zoom factor to resolve some 3dstudio view issue for smallest mesh:

[johnwhile]

ok, "Unit conversion" tested when importing also animation. but remember : WHEN SAVING USE THE SAME VALUE IF YOU WANT SEE A GIANT SOLDIER.

[kompadre]

uhm... stupid maxscript... you must delete the old script folder, restart 3dstudio and run the script (r39).

Now "mesh_" and "collision_boundingsphere" will not be created, when saving the script use the best bounding sphere algorithm as default value, is little slow than first what use 3dstudio's boudingbox, but mesh soldier are smaller than building, in fact in the other script you can change bounding method..... but this is not important.

Only for a future test : if you create "mesh_" and "collision_boundingsphere" the script use these as spheres.

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

i must testing but i will made a zoom factor to resolve some 3dstudio view issue for smallest mesh:

YEAH!!!!

I didn't test for a long time (in the game), but it seem's that all works perfectly!
That means, - any model constructed almost ANYWHERE may converted (with your tools help) in the MEDIEVAL MESH format within TWO SECONDS!!

No more boring comments...
Assigning vertex in milka... (- that's HELL TORTURE, by the way.. )


THAT GREAT!


P.s. My model has 20 - bones sceleton (w/o additional weapon/shield bones) - is this ok?

[johnwhile]

for additional bone i don't know exactly how work, but in case of editing animation you must put the correct skelexport file (you can extract it by cas files)
For normal modding "use only assignement", it work without skeleton, is a crude *.mesh <-> 3dstudio conversion.

Yes, the power of maxscript and c++ plugin into 3dstudio is the best and simple solution for editing 3d objects.

I made a simple auto-skin , it can also smooth the bone's joint assignements. But i'm not a algorithm-creator, so the result isn't very perfect, as lod generator.

[Tellos Athenaios]

So I now have a working version of the PACK tool which builds for Windows (under MINGW) as well. I just need to polish off a couple of things (release script) and I think I'll call it a release. Hope to do that later tonight.

[johnwhile]

fantastic news, don't made it too complicated , just a simple executable because you must test if lzo.dll get a correct decomplession and "suddivision" array is used for it.
And if you want send me the source code because i'm learning c++ about 3dstudio plugin, i already made a simple dll extension but isn't a simple language.

[kompadre]

Hm-m... Something strange is going on.

It seems to be that when my, (converted with M2tw meshcas) model on a field - game sooner or later crushes...
Sometimes game crushes just after loading screen, sometimes just after unit placement begins, sometimes when battle begins or even later.

I notice that crushes connect somehow with camera movement/rotation/scaling. Especially fast camera movement lead to crush.

W/o that model - all ok.

I thought that may be crushes occurs because of heavyweight model (3000 - 4200 triangles). I've made a mesh w/o body - only head/sword/legs/... - and it still crushes...


May be better to make full 26-bones sceleton? I'll try that.
and, by the way, I can send my model to you if you have time.

As I said crushes somehow related with camera movement. Usually - that is last lines in system.log.txt ::

22:49:28.745 [system.io] [info] exists: missing mods/Third_Age/data/cameras
22:49:28.746 [system.io] [trace] file open,,data/cameras/Battlefield_Pan_Right.cam,,not found
22:49:28.746 [system.io] [trace] pack open,packs/data_0.pack,data/cameras/Battlefield_Pan_Right.cam,14345
22:49:28.746 [system.io] [info] open: found data/cameras/Battlefield_Pan_Right.cam (from: packs/data_0.pack)
22:49:28.749 [system.io] [trace] pack close,,data/cameras/battlefield_pan_right.cam,,,-14345
22:49:30.827 [game.script.trigger] [trace] Trigger <1689_G5Script2_Trigger> fired

I've test models on TATW 2.1 mod.
Convert with M2TW.scripts.r39.1 on MAX 2011 (64bit) / win7 (64bit)
Kingdoms(Gold Eng. version) 1.5


P.s. May be that strange bounding spheres involved?

[Tellos Athenaios]

fantastic news, don't made it too complicated , just a simple executable

'Tis a fairly simple tool --link is in my signature--, I quite deliberately kept things simple for the first release. In future more advanced features might be useful, such as verifying that all bits and pieces add up to the right totals and support for a patch format so that mods could release patches to packs and use the pack program to patch existing packs.

because you must test if lzo.dll get a correct decomplession

I used localized.pack to test. By the way, although LZO can be linked dynamically, the binaries from the binary release of the PACK tool were built to link LZO statically (for simplicity), so the lzo.dll file is not actually used. The version of LZO I compiled with MINGW from LZO source is used instead.

and "suddivision" array is used for it.

It is, in my code I refer to it as “chunks”. Each item refers to the size of a chunk of payload in the pack, a number of chunks make up the total payload for a file and so on.

And if you want send me the source code because i'm learning c++ about 3dstudio plugin, i already made a simple dll extension but isn't a simple language.

Well PACK is written in plain C, and C++ is a lot more complex than C and a lot of things people normally do in C is, apparently, frowned upon in the context of C++.

[bobbin]

boh, i make some test now, i changed radius for both sphere and seam that don't change nothing... in the next release i will delete these spheres, the script will auto-calculte the best boundingsphere.
Yes, KE write the bounding sphere as comment, but in the mesh there are two identical bounding sphere...

Will we still be able to edit the Mesh_boundingSphere? It is useful as editing it allows you to stop units disappearing when the camera is close to them. The Collision_boundingSphere can go though, it doesn't seem to have any noticeable effect on anything.

[johnwhile]

Will we still be able to edit the Mesh_boundingSphere? It is useful as editing it allows you to stop units disappearing when the camera is close to them. The Collision_boundingSphere can go though, it doesn't seem to have any noticeable effect on anything.

In this version i simple hide these spheres:

1) if you omitted the "mesh_boundingsphere" and "collision_boundingsphere" the script ask nothing and autocalculte the best sphere.

2) if you build a SphereGizmo or Geosphere o Sphere and rename them in "mesh_boundingsphere" and "collision_boundingsphere", the script don't compute the best spheres and use their dimension, use it example for test.

[kompadre]

It seems to be that my problem solved.
I installed additional 6 bones and sceleton became full 26 bones.
And... one more thing - I assigned your material "Characterlod0" to all parts of model.
I've tested about 5-6 times (with battles, with many units) - all ok!

And one more time thank you for the best, realy best, fantastic tools!!
I didn't test all the features, but if among all other things, automatic lod generator works good enough - that... that,,, i dont have words... ! That's seems to be almost imposible! Because even power 3d packages/programs - has difficulties with automatic lod generations...

[johnwhile]

Hm-m... Something strange is going on.

It seems to be that when my, (converted with M2tw meshcas) model on a field - game sooner or later crushes...
Sometimes game crushes just after loading screen, sometimes just after unit placement begins, sometimes when battle begins or even later.

I notice that crushes connect somehow with camera movement/rotation/scaling. Especially fast camera movement lead to crush.

W/o that model - all ok.

I thought that may be crushes occurs because of heavyweight model (3000 - 4200 triangles). I've made a mesh w/o body - only head/sword/legs/... - and it still crushes...


May be better to make full 26-bones sceleton? I'll try that.
and, by the way, I can send my model to you if you have time.

As I said crushes somehow related with camera movement. Usually - that is last lines in system.log.txt ::



I've test models on TATW 2.1 mod.
Convert with M2TW.scripts.r39.1 on MAX 2011 (64bit) / win7 (64bit)
Kingdoms(Gold Eng. version) 1.5


P.s. May be that strange bounding spheres involved?

Uhm, this is a big issue, this happen when file is corrupted, send me the mesh file, is possible some wrong skeleton's bones

About Lod generator: It work because MultiRes is the best poly reduction in the internet, autodesk is a professional program, the only problem was finding a "stop value" for each lod, i have used the sum of face's area and i found with excel a similar andament for a lot of standard model #191.

About Auto Skin assignments : I try to find in internet some methods but you must pay for everything... in max the Physic Modifier don't work... So i made a simple methods that consist finding the nearest vertex of each bones.

[johnwhile]

It seems to be that my problem solved.
I installed additional 6 bones and sceleton became full 26 bones.
And... one more thing - I assigned your material "Characterlod0" to all parts of model.
I've tested about 5-6 times (with battles, with many units) - all ok!

And one more time thank you for the best, realy best, fantastic tools!!
I didn't test all the features, but if among all other things, automatic lod generator works good enough - that... that,,, i dont have words... ! That's seems to be almost imposible! Because even power 3d packages/programs - has difficulties with automatic lod generations...

About your screenshot.
Into mesh file each bone have a number, i write it as "BoneId" and write it in each bones comment. Seam that this number is used to mach "bone name" with "animation cas bones". For standard skeleton these number mach with skelexport's list (bone_pelvis = 1 , bone_RThigh = 2 ecc...) but for mesh with secondary skeleton there are some difference, same number are used for each secondary exist skeletons
example in 01_KE's_solution.skelexport
...
bone_weapon01 = 20
bone_weapon = 20
...

The warning message tell you what the script don't find a boneid comment in each bone and try to assign the default value, is possible that there are some bug during correction and this make a crash in battle when unit are moving.

[kompadre]

johnwhile
Thank you for help!
But I've a million dollar question (joking).
Can I assign vertex to 3 bones (or even 4) and then correctly converts model in to the game-mesh?

All old-school tools like GOAT and Mesh2ms3dbeta0.18 can't afford that.
If I, for examle, assign vertex to
1. abs(40%)
2. torso(40%)
3. Rupperhand(20%)
and after that, converts with old tools (GOAT/Mesh2ms3dbeta0.18)
in the game-mesh I have:
1. abs (40%)
2. torso = 100% - abs = (60%)
3. Rupperhand = 0%

I.e., ONLY TWO BONES ASSIGMENT.
Is this game-engine limits? Or old tools just work slightly wrong?
And one more time - how about Mesh/Cas/Engine?

[johnwhile]

2 bone per vertex is a file's format limit, is possible 3 but in all mesh file i have found only 2. In old RomeTW cas model and also in some Med2 Cas model there are only one assigments, in this case there are a true limit (assignments was necessary anlso for vertex position respect their bones)

If you use 010 Editor you can see the location of these informations:

1. Bones Information:
   address struct STRUCTURE_CLASS > struct VERTEXSECTION_CLASS > struct QUADS_CLASS vertexData2[0] > struct X4BYTE >
   vertex[0] array contain 4 unsigned byte [x,y,z,w] ; x and w are always 0 , z is the first bone id , y is the second bone id. A third and fourth bone's id can exist in x or w but i think no.
2. Weight information:
   address struct STRUCTURE_CLASS > struct VERTEXSECTION_CLASS > struct X2FLOAT_CLASS uvvertexData[1] > struct POINT2
   vertex[0] array contain 2 float [u,v] ; u is the weight of first bone, v the second weight , but is always v = 1.0 - u because the sum must be always 1.0 (100%). A hypothetical third weight can exist if it will be calculated as:
   thirdWeigth = 1.0 - u - v.

example for i-th vertex with :
1. abs(40%) boneid = 4
2. torso(40%) boneid = 5
3. Rupperhand(20%) boneid = 10

can be
struct X4BYTE vertex[i] = x:10 , y:5 , z:4 , w:0
struct POINT2 vertex[i] = u:0.4 , v:0.4 (thirdWeigth = 1.0-0.4-0.4 = 0.2)

but these experiment i think will crash (don't tested)



When saving, the script get from Skin modifier the two bigger weigth of each vertex : abs(40%) torso(30%) , and normalize the range A = 40%/(40%+30%) = 57% ; B = 30%/(40%+30%) = 42%. This method resolve the ZeroWeigth issue of old KE's script. Can also check if there aren't assignements and put all to bone_pelvis

[kompadre]

Hmm...
It's all clear now. Game-engine limits.
Thank you for investigating that question.

[kompadre]

I've detected some strange behavior concerned normals.
It seems to be that the different normals options should use when converting with your tool(M2TW MeshCas) and with old mesh2ms3d_beta18....

It's sounds unbelievable, but I've made some tests and think this is true.

1.) For Old mesh2ms3d_beta18 you should use (invert x ; invert y) when working with photoshop plugin (Nvidia Normal Map Filter) and ( Flip Green (x) ; Flip Red (y) ) when constructing some normals in 3dsMax).

2.) For Your tool(M2TW MeshCas) you should use (invert y) when working with photoshop plugin (Nvidia Normal Map Filter) and ( Flip Red (y) ) when constructing some normals in 3dsMax).

How I test.
I've got normals-test texture (part of it you can see in post-attachment picture = grid.jpg), old unit (converted with mesh2ms3d_beta18), new unit (converted with M2TW MeshCas r39.1). I converted normals-test texture to normals with photoshop plugin (Nvidia Normal Map Filter /v 8.20 beta for 64 bit photoshop/) using different options (see previous 1.) 2.) ).
Then I made two test .texture-sheets for game unit. Color (_diff) for both of them, the same - simple greycolor without anything else. Normals (_norm) are different.

First _norm - obtained from normals-test texture with Nvidia Normal Map Filter options (invert x ; invert y)
Second _norm - obtained from normals-test texture with Nvidia Normal Map Filter options (invert y).

After that, I've tested both units (old and new) on the game engine with this test-texture sheets instead of units original main-textures (i didn't involve attachments-textures).

And what Have I had?

Old unit (converted with mesh2ms3d_beta18) "said" that the correct normal-options is the (invert x ; invert y) for the photoshop plugin and ( Flip Green (x) ; Flip Red (y) ) - for the 3dsMax.
(See the post-attachment pictures = InvXY_Old.jpg and InvY_Old.jpg)

New unit (converted with M2TW MeshCas r39.1) "said" that the correct normal-options is the (invert y) for the photoshop plugin and ( Flip Red (y) ) - for the 3dsMax.
(See the post-attachment pictures = InvY_New.jpg and InvXY_New.jpg)

How i determine correct normals from picture? Units skin must be like glazed tile, like... tiles with grooves, but important that the tiles must be extruded and grooves - hollowed. When we have something different or even vice-versa - this means wrong normals (see post-attachment pictures).