Settlements: File Formats; Take 2

[SigniferOne]

KE here, last page:

https://forums.totalwar.org/vb/showt...t=83063&page=9

It seems turning animations have a problem importing/exporting.

But please don't worry about being lazy. If anyone deserves to be lazy it's you and the grumpy grandfather. I mean old man. My biggest concern is about you burning out mid-way, that's why my biggest interest is that you take your time, and that we periodically provide you with motivation and inspiration from the results of what your work helped us accomplish. For instance I've given you big accollades in my newly released animations pack (here).

[KnightErrant]

@SigniferOne
Thanks for the accolades! Congrats on the anims, looks
like people are really pleased with the improvements. Also,
thanks for the link, I undrstand now, I abandoned my original
lthread. Actually happy to have a problem with a definite
error message; this I can deal with. As regards burn-out,
I think this was true in July/August but not from modding for
the game; more just summer real world stuff. Working with
Bwian on the gmax/3dsmax import/export stuff really has me
going strong again.

(Wow, just missed it, Boston just took Game 2, go Sox!)

Haven't thought through this, but now that the importer/exporter
is looking better i.e. might just work, doing a importer/exporter
for .world files doesn't look too bad. The Python reader taught
me enough to find the mesh data for the settlements
meaning the structures for northern european villages, towns,
and large towns. This could be adapted to write out
a .ms3d-like binary file for a chosen structure. This could
then be pulled into 3dsmax since it has: verts, faces, uv coords,
lighting (my worry about Milkshape, it can't do this but
3dsmax can; have to learn this), animations (don't know what
Caliban meant about this, I can ask again at the right time, but I
assume this is maybe a particle system.)

This isn't the same as adding whole new structures, but maybe learning
how to change the existing structures might lead to good questions for
Caliban on how to do more with their world files. Right now, one problem
at a time.

[KnightErrant]

Update:

Sorry, not an update on settlements but we will be getting
back to them soon. Bwian did a test yesterday and we've
been able to do a .ms3d model into 3ds Max and back out
again to .ms3d. The model wasn't animated, just the regular
basepose. 2 more tests needed, (1) back and forth conversion
of a model with animations and (2) Bwian's custom models won't
convert. I suspect custom models don't have the null animation
frames the converters (GOM's and mine) put in and I've borked
the process by assuming something is defined that isn't. If this
is cleared up in a day or two, we'll put out an alpha. This will
also work for Gmax users, it's just that the export will be to the
listener. Gmax guys will have to cut and paste the ASCII output
to a .txt file and then run a Python utility to convert to the .ms3d
file format. (This is how I tested things.)

A murrain upon the Discreet guys who made the clipboard buffer
10 Kbytes in size . Not so bad for a lod3 but for a lod0 go get a
cup of coffee and cut/paste, cut/paste, .. cut/paste for 15 minutes
or so. I know, if its free you can't really complain.

[Bwian]

Got a new version in the mail from KE today, anbd it's a big step forward.

Imports an MS3D file neatly into Max, with all groups, rigging, UV and comments intact. This includes the messaed about with skeletons in the Dwarves etc. so it is now very tolerant of hacked about stuff!

It exports too, and the resulting object can be opened up safely in MS3D. There is a minor issue with rigging, where it turns all the vertices 'green' to indicate a zero value, rather than the red fully asisgned verts ( looks like a side effect of some work KE had to do to make it accept the slightly rougher models made with the tools we work with! )

You also need to re-assign the materials, but this is no problem at all since the UV mapping is perfectly OK and it only takes a click to have it back again.

Next step will be to get the animations to import/export as well, and we have a major new weapon in the arsenal.

Then, we can get the settlement files doing the same

hooray

[SigniferOne]

Excellent, it's going great!

[KnightErrant]

Yes, I think we are very close. Tested animated camels and elephants
last night. There was a oopsy on elephants not in the script but in
the Python converter from text to binary for Gmax users. (Elephant
bones have spaces in their names, I forgot this and wasn't parsing the
names correctly in the joints section for making the .ms3d file.) I think
we just have to sort out the anomaly Bwian is seeing with animated horses and
we are there. The only known deficiency is I can't handle animated
siege engines yet. Siege engines contain their own texture file paths
unlike other units and I store these paths in the joint comments.
Unfortunately, I also store the .cas header, hierarchy, and footer for
animations in the same place so there's a conflict there. I'm going to ignore
this for now and try to fix it up later.

There is also an issue about Gmax making a few extra bone assignments.
If Bwian doesn't see this as well it means its a Gmax "feature" that is fixed
in 3ds Max. (What happens is I do the usual primary and secondary bone
assignments on import. On export from Gmax a few random vertices end up
having three bone assignments, for some reason usually to one of the
weapon or shield bones. Oftentimes this is totally innocuous because
the weight on the third bone is zero but it is still worrisome that Gmax is
doing this. )

[KnightErrant]

I sometimes post good news/bad news sorts of things
but this is just a good news post. Yes, Bwian saw anomalous
bone assignments in a unit but I think this is solved.
I was looking through the Max Script documentation for
how to delete vertex assignments to correct the
anomalous assignments but saw this by serendity:

Edit: Apologies, serendity is usually spelled as serendipity.

skinOps.ReplaceVertexWeights <Skin> <vertex_integer> \

( <vertex_bone_integer> | <vertex_bone_array> ) \

( <weight_float> | <weight_array> )

Sets the influence of the specified bone(s) to the specified vertex. Any influence weights for the bone(s) that are not specified are erased. If the bones and weights are specified as arrays, the arrays must be of the same size.

This is literally a one-liner solution to the extraneous bone
assignments problem. If Bwian has the same results for 3ds Max
as I've had for Gmax this is a done deal. The crux is: any influence for the
bones not specified is erased and the original assignments i.e. those from
the .ms3d file, are enforced. Tried this out and it works for Bwian's custom
skeleton model where problems were noted before. Will post again once this
is confirmed.