THE Ultimate Animation of Crew Thread

[DivingDuck]

Hans,

first you should identify the source of your problem.

Export the 3d model via S3D and ...

1. re-import it without altering anything. Does it work ingame?
2. import the *.obj into your 3d proggy. Export without any changes! Does it work ingame still?

DD

[Hans Witteman]

Originally Posted by DivingDuck

Hans,

first you should identify the source of your problem.

Export the 3d model via S3D and ...

1. re-import it without altering anything. Does it work ingame?
2. import the *.obj into your 3d proggy. Export without any changes! Does it work ingame still?

DD

Hi mate,

Yes if i import the model and re export it without touching anything it is working fine.

But when i try to modify even very slightly like what i just attempt a few minutes ago, i just try to move one UVW layout chunk the hand more precisely and i just move it 1 unit left and here again the result :




I am very close to stop any further attempt at modifying those base character mesh it seem that no one can figured this one out so i will put the emphasis on my typIIA interior instead of waisting countless hours to fix ubi horrible mesh layout and shape.

Even in SH5 the character look bad they should seriously consider hiring an artist specialized in human anatomy.

Best regards Hans

[DivingDuck]

Did you alter any mesh or the texture coords? It looks as if you´re messing with the mesh, but you´re saying it´s the UVW mapping coords.

[Hans Witteman]

Originally Posted by DivingDuck

Did you alter any mesh or the texture coords? It looks as if you´re messing with the mesh, but you´re saying it´s the UVW mapping coords.

Hi DD,

Yes i just moved one UV layout part the hand, didn't touch anything else and i disabled optimize textures coordinates in S3D editor to make sure the amount of vertices remain the same and as you see without any success.

Since the beginning if someone would have been able to modify those base mesh i think we would have seen it in at least one mod.

I think the only way to solved that would be to write our own collada import/export script but i am no where near a programmer to do that.

All hope is not lost but it seem we will be stuck with those character for awhile.

Also what could work is hexing back the new vertices coordinates that are move on the mesh to fool the game engine that nothing has change?

Edit: Hexing back vertices position would not work either because of animation.
Best regards Hans

Animations have been one of the last things to crack for years now.

That's why no one has modded the Crew Animations yet.
There are still unknowns that need to be solved.

The MeshAnimationData2 is interesting.

Why two 0 frames?
Frame 0 with a timing of 0 seconds could be a transitional frame for
the second Frame 0 with a timing greater then 0
Or it could be something else!

Remember, if we screw up just one thing we get a mess!

SH4 rowers texture fix threw me for a loop for about a day.
S3D nor the other Tools I use could import a simple UV fix without the messed up mesh thing.

I finally fixed the problem by Hexing the texture maps section!
There are things that S3D and other Tools can not fix.
And before the Hexing gets explained?
We need solid proof it works everytime.
That means a lot of work is still needed to fully understand certain files.
It is all time intensive, brain numbing, boreing, non-profit work!

But before I move along I want to see the Crew Animations finally open to Modders.

It is my last Goal with SH3.

[Hans Witteman]

Originally Posted by privateer

Animations have been one of the last things to crack for years now.

That's why no one has modded the Crew Animations yet.
There are still unknowns that need to be solved.

The MeshAnimationData2 is interesting.

Why two 0 frames?
Frame 0 with a timing of 0 seconds could be a transitional frame for
the second Frame 0 with a timing greater then 0
Or it could be something else!

Remember, if we screw up just one thing we get a mess!

SH4 rowers texture fix threw me for a loop for about a day.
S3D nor the other Tools I use could import a simple UV fix without the messed up mesh thing.

I finally fixed the problem by Hexing the texture maps section!
There are things that S3D and other Tools can not fix.
And before the Hexing gets explained?
We need solid proof it works everytime.
That means a lot of work is still needed to fully understand certain files.
It is all time intensive, brain numbing, boreing, non-profit work!

But before I move along I want to see the Crew Animations finally open to Modders.

It is my last Goal with SH3.

The 0 frame could be linear float or maybe the morpher controller i am only speculating here but i refer to how we work in 3d and animation.

Yes i know how hard it could get some time and all this for free because the most passionate people work a lot of time for nothing except to make other happy with their work.

If only we could have a game programmer as passionate as we are here this annoyance would be a thing of the past.

Anyway for the moment i am happy at how the crew look in mod and lot of uniforms help to accept the old mesh body.

I don't think i can make them to look better except for the head that i can easily replace with custom head i made, the only thing is that they won't talk but they rarely open the mouth and when they do i prefer to look elsewhere.

Best regards Hans

[TheDarkWraith]

@Hans: can you send me the work you've been working on for the crew? I have an idea
And if you can also detail what you did to cause the messed up crew that would be helpful also

I'm thinking the MeshAnimationData2 is based from a pose from an idle position or maybe even other positions based on different factors.
The idle position is not the same as the base mesh so animations would be distorted if based off of them as would any other cases.
The first 0 frame of 0 timing could be a placer to grab the needed base information for all following frames.

[Hans Witteman]

Originally Posted by privateer

I'm thinking the MeshAnimationData2 is based from a pose from an idle position or maybe even other positions based on different factors.
The idle position is not the same as the base mesh so animations would be distorted if based off of them as would any other cases.
The first 0 frame of 0 timing could be a placer to grab the needed base information for all following frames.

Hi mate,

Ok i think we are getting closer now let's me explain when we build a character rig the biped system used for animation have 2 states one is the default position of the character in cross shape pose, this pose is then move to the position where the animation will took place and when on position we pass in freeform animation mode.

Maybe the first 0 is the neutral pose and the second the start of free form animation mode?

Also when i start to animate a character i have to set the first keyframe manually to define base position for each limbs.

We still think about that and comment on idea that come spawn in my mind.

Best regards Hans

[Hans Witteman]

Originally Posted by TheDarkWraith

@Hans: can you send me the work you've been working on for the crew? I have an idea
And if you can also detail what you did to cause the messed up crew that would be helpful also

Hi mate,

The minute i am done with some urgent request from the team i will upload it to you.

And the only thing i did was moving the hand UVW layout it is the flattened version of the hand you see in 3d software UVW unwrap window.

Best regards Hans

If we follow the StateMachine animation calls?
We may find the base for each Data2
That is IF that's what is going on.

[Hans Witteman]

Originally Posted by privateer

If we follow the StateMachine animation calls?
We may find the base for each Data2
That is IF that's what is going on.

Hi mate,

Could it be possible to use a decompiler to see the code executed when character animation occur with this i could probably identified what method was used for the rig and this could help you out maybe?

Best regards Hans

[urfisch]

hey hans.

the "splattered-mesh-effect" is nothing new. its produced by the game, when changing a mesh. seems as if the coordinates are mixed up. privateer stated once the new mesh can not consist of more vertices than the former model. otherwise the game mixes them up.

its just, what i experienced years ago, when trying to change the decals on the crew. it was simply impossible. even just changing the position of a vertice caused this effect.

[DivingDuck]

Moin Hans,

did a few tests with S3D myself this morning. While exporting the 3d model and importing it straight back a lot of texture coordinates data got changed. Working with a crew body mesh the amount of texture coordinates got reduced while other objects from CR.dat (use a non modded version!) ended up with a remarkably higher amount of texture coords than before.

So, the question is, will the tex coords be screwed on export via S3D or on import via S3D.

I´ll have a look at that in hex asap.

Regards,
DD

[Hans Witteman]

Originally Posted by DivingDuck

Moin Hans,

did a few tests with S3D myself this morning. While exporting the 3d model and importing it straight back a lot of texture coordinates data got changed. Working with a crew body mesh the amount of texture coordinates got reduced while other objects from CR.dat (use a non modded version!) ended up with a remarkably higher amount of texture coords than before.

So, the question is, will the tex coords be screwed on export via S3D or on import via S3D.

I´ll have a look at that in hex asap.

Regards,
DD

Hi DD,

Yes texture coordinates even with slight modification they tend to change a lot for some obscure reason in the UVW algorithm.

I guess you already aware of that but take in consideration that S3D editor have a built in feature that optimized the vertices from UVW layout and you have to de activated on import process in import window to make sure the UVW vertices count won't be alter.

Best regards Hans