Animation Pipeline

[Wijitmaker]

Very interesting... I feel like we got a lot of answers today, but now there are more questions.

Try tweaking the actor file to call out a .dae file instead of a .psa for the walk test. Could I see an animated gif of the walk? Maybe use: inf_pack_walk.dae

<animation file="biped/inf_pack_walk.dae" name="Walk" speed="120"/>

I have yet to see the .dae file that blender exports. I'd like to see it so I could do a comparison look. Could I get a copy from you?

In wonder if the prop orientation error has more to do with how I brought the prop points into blender rather than an error on blender's part. I'm convinced this can be fixed.

I'm more concerned about the mesh/animation cross talk between the old (max animations and meshes) with the theoretical new (blender meshes and animations).

[Stan`]

@stan FBX file:

Do you have a newer version?

The Autodesk ones were broken. Impossible to import. The other one had lost the root bone ... and two or three other bones missing too, the calves I think.

Seems to be a common problem for every 3DSMax exported .dae file I try to import.

Have updated the ForeArm --> Forearm in the /actor/biped.xml.

All other dude- files may be found there, e.g. the celts/dude.xml I currently use (still almost exactly what you said I should do).

Okay, yeah I can have a newer version in 3dsmax when exporting to fbx you have the choice between 2013,2012,2011,2009,2006 versions of it

I gave the oldest one I could to make sure WijitMaker would be able to import it fine. Also you must know that blender fbx importer is broken, and missing features. I think I linked a working one in the thread Fix our skeletons in the upcomming Blender version.

Very interesting... I feel like we got a lot of answers today, but now there are more questions.

Try tweaking the actor file to call out a .dae file instead of a .psa for the walk test. Could I see an animated gif of the walk? Maybe use: inf_pack_walk.dae

<animation file="biped/inf_pack_walk.dae" name="Walk" speed="120"/>

I have yet to see the .dae file that blender exports. I'd like to see it so I could do a comparison look. Could I get a copy from you?

In wonder if the prop orientation error has more to do with how I brought the prop points into blender rather than an error on blender's part. I'm convinced this can be fixed.

I'm more concerned about the mesh/animation cross talk between the old (max animations and meshes) with the theoretical new (blender meshes and animations).

Would you like a box object parented with a prop in Max and the same parented in blender ? Also did you have time for the rotary mill ?

Edited March 16, 2014 by stanislas69

[Radagast.]

sure, here you go: dude.dae

Thanks stan, that explains it , will look for this working FBX importer or FBX file then.

Try tweaking the actor file to call out a .dae file instead of a .psa for the walk test. Could I see an animated gif of the walk? Maybe use: inf_pack_walk.dae

<animation file="biped/inf_pack_walk.dae" name="Walk" speed="120"/>

Good idea. Will test it and create two gifs, one old walk (psa), one new, though I think I tried this yesterday and the result was equal.

Do you think the axes could be messed up? Though that the animation that is embedded in the same dude.dae does result in a fully working animation, without vertex distortion. So probably the vertex order could be messed up within a vertex group, just as you stated.

Have created a .dae Walk animation, the gif is bad. Didn't know this one could be used for step dance too if only played quick enough.

In wonder if the prop orientation error has more to do with how I brought the prop points into blender rather than an error on blender's part. I'm convinced this can be fixed.

Difficult to tell, as I had to replace your empties with mine. Then I realised the anomaly, as the location was different though I copied it over (CTRL+C when hovering a field) from your prop points to mine. (which resulted in all but one of the comparison images above -- the exception the one where I compared the bone local coords to the bone object coords that essentially are inherit the orientation/rotation from the armature as is beeing expected, still the bones' rotations seem to/could be overlooked by blender's COLLADA importer, perhaps the z-up is still y-up for the bones? Have to test again trying to parent my empties to your prop points.)

I'm more concerned about the mesh/animation cross talk between the old (max animations and meshes) with the theoretical new (blender meshes and animations).

Absolutely, to make it compatible is the goal. The topic's title: Animation pipeline must have confused me. So that now Enrique is angry.

[Radagast.]

This is what the in dude.dae embedded animation looks like. All working but the prop points, but that's unrelated (as I still did not synchronise your prop point and my prop rotation).

[Radagast.]

This image might clarify: The bone coordinate frame is y-up before exporting. The rest is z-up. So are the empties/prop points. (I'd love blender to make an object without vertices an empty and not introduce another object just for empty's sake ...)

Left is Pose Mode, to the right is edit mode, both show local coordinate axes.

Edit: If blender COLLADA export settings are set to "Export to OpenSim", then the animations get distorted in another direction, the bones look flipped then. So probably this indicates that indeed the PSA file seems to have lost the indices. It being a binary format, fixing the vertices manually is somewhat difficult.

Edited March 16, 2014 by Hephaestion

[Enrique]

Difficult to tell, as I had to replace your empties with mine. Then I realised the anomaly, as the location was different though I copied it over (CTRL+C when hovering a field) from your prop points to mine. (which resulted in all but one of the comparison images above -- the exception the one where I compared the bone local coords to the bone object coords that essentially are inherit the orientation/rotation from the armature as is beeing expected, still the bones' rotations seem to/could be overlooked by blender's COLLADA importer, perhaps the z-up is still y-up for the bones? Have to test again trying to parent my empties to your prop points.)

Absolutely, to make it compatible is the goal. The topic's title: Animation pipeline must have confused me. So that now Enrique is angry.

Lol, not angry at all, just clarifiying the goal that we were pursuing.

I arrived to the same conclusion. During my tests I concluded that the orientation of the bones (called "roll" in blender) is messed up during the export/import process. The weird thing is that manual tweak of the roll sometimes didn't make any changes when exported, and sometimes minimal changes were visible.

[Radagast.]

Lol, not angry at all, just clarifiying the goal that we were pursuing.

I arrived to the same conclusion. During my tests I concluded that the orientation of the bones (called "roll" in blender) is messed up during the export/import process. The weird thing is that manual tweak of the roll sometimes didn't make any changes when exported, and sometimes minimal changes were visible.

Thanks, leader. Indeed It feels the same here, sometimes changes are not visible at all. The most interesting thing is that when I change the orientation of bones, then it's visible with the animation that is embedded (i.e. if the <unit>.dae is used for both mesh and animation, then it works!! always, and changes reflect correctly.)

That's why I also believe now that

• the Vertex indices in the PSA files have once been created in another order (and we are not able to get the vertices in the same order into pyrogenesis!),

  OR

• the bone's rotations are not taken into account properly at COLLADA import of blender. (this is support by the observation that rotating the bone around x-axis in EDIT MODE results ingame in a rotation around the up-pointing axis, that is y-axis. but this could be because of the bone's pose rotation too.)

  OR BOTH

For the latter case I have to file a bug report (just like for the missing empties).

For the PSA bone/vertex weight distortion I have no idea. Perhaps it's really fixed if GaiaClary can have a look at the bone POSE local coordinates import.

Edited March 16, 2014 by Hephaestion

[Radagast.]

In this blenderartist topic I quote some exported .dae files.

Especially this Line 54 explains how we can get our COLLADA files to work even without only using blender empties (what I recommend for compatibility with other program's sake).

Remember this:

• If we remove all but the armature geometry node from the geometry list, then we are fine to go to pyrogenesis without multiple object error.
• If we loose empties on import of COLLADA .dae files, then go ahead and copy the empties' child nodes from with the armature hierarchy into the geometry list. And they will show up in blender.

The vertex weight, vertex ordering or bone pose coordinate frame axes anomaly (.dae importer not converts it?) still remain. Edited March 16, 2014 by Hephaestion

[Radagast.]

Catastrophy so far! Only WIP. Have to rework it and we still have to re-export the max files. Or, didn't Stan already do this? .max -> .dae

My report so far is partly completely wrong as we have not tested for the new .dae 3DSMax exporter, have we?

**System Information**

Ubuntu 12.04RTS, but facing the same on all platforms.

2 Cores.

**Blender Version**

Broken: head revision (2.70).

Worked: never really worked before. only recently we gathered new hope to get a blender pipeline up properly.

**Short description of error**

The Armature rotation seems to be the common blender Z-Up coordinate frame.

Unfortunately for bones our animations are messed up unless we force all wildfiregame artists to use blender only. Unfortunately this would render all our meshes, animations of 14 years of work useless.

Fixing this seems to be the last cornerstone in full compatibility between blender and 3DS Max COLLADA animation and mesh ... files.

Note: It's not clear if the most recent 3DSMax .dae exporter is working better with the blender .dae importer. I realised we have not reexported the old max posts.

**Exact steps for others to reproduce the error**

Load dude.blend.

{F81547}{F81548}

Select a bone of Armature, e.g. in pose mode.

CTRL+SPACE to show coordinate axes.

Switch axes to LOCAL FRAME.

Now switch between Edit and Pose Mode and observe the difference. Also attached as image.

{F81552}

It looks like this is still y-up though blender .dae import probably uses and interprets the unit and uppointing axis tag. Later it perhaps might even be exported as x-up but that could be wrong?

Another bone:

{F81560}

Here a broken animation. This happens when combining 3DS Max .dae with ours.

{F81556}

The distortion could also be related to vertex weight or vertex order, the latter being our fault rather than yours as 3DS Max might have exported objects in a different order than blender. We tried the OpenSim option too. It resulted in distortion again - instead of what the following image shows, the distortion then was towards the trader's donkey, so from left to right or right to left, can't find the corresponding OpenSim setting chosen image currently:

{F81564}

The following is the evidence that the animation works as expected with the mesh from the same blender-COLLADA-exported dude.dae file.

{F81549}

Tthe props are empties parented to the bones. They might give hints as to which axes are messed up. Changed almost everything, copying over 3DSMax imported prop-attachment-point-objects' rotation and location did not help (no empties, those could not be swapped easily, see my thread post with GitHub references to Lines).

http://blenderartists.org/forum/showthread.php?330494-Why-blender-treats-empties-separately-gt-Propping-problems-COLLADA-example-given&p=2599954#post2599954

For even more information, just look at this wild fire forum thread, are documenting our experiments, changes and results there:

http://www.wildfiregames.com/forum/index.php?showtopic=15552&page=20

We have many such threads around after 2 years of trying to get a blender pipeline to work with upkeeping compatibility to 3DS Max animations and meshes. We appreciate blender foundation's and its supporters' efforts that are always astounding. A mighty thanks for all improvements to COLLADA that already brought us so close to succeeding (finally it allows a blender only pipeline with scrapping all prior work, that's the last ressort).

Tell us if you need any support. We - modders & open source community - are happy to give back.

{F81558}

Prop point 90deg off wrong axis z-up vs y-up ?

{F81562}

The problem now is, that we have created once we were able to import all bones correctly. Unfortunately in the most recent importer bones are missing. Try to import this file:

3DS Max exported with old collada plugin: {F81567}

Native exporter, all dae old files:

Note that we export only the selected objects: one mesh and the armature (the mesh's parent).

Edited March 17, 2014 by Hephaestion

[Stan`]

Want a 3Dsmax dae model ?

[Wijitmaker]

Sorry guys, I have to bail on this for a few weeks. I'm taking a trip - leaving this Friday and won't return until 4/7. I need to spend my free time in preparations. Keep fighting the good fight, I'll try to lend my assistance again when I return.

The next steps I would take is the following:

Create a simplified animation (maybe 2 bones bending a 4 sided cylinder) in max with some test prop points, then work to get that into blender. Try to export a .dae from max and blender again. Compare the contents of the .dae files with a smaller dataset.

I'd also be curious to better understand how pyrogenesis converts the .dae files into .psa and .pmd files - and what parts and pieces of the .dae it uses in the conversion.

I also thought it might be interesting to make a custom texture and paint it so that the vertexs in the scramble would be obvious in their before and after positions.

[Stan`]

Okay. Happy Holydays, I'll help Hephaestion as much as I can. I'll wait for the mill Not in A16 then.

[Radagast.]

Thanks, sounds reasonable. Happy Holidays to you.

Tried to find a solution with existing models but the error is consistent for 3DSMax .dae, while it is non-existent for blender models such like the celtic siege battering ram.

Sad with the rotary mill, but hey once we fix the 3DSMax <-> Blender <-> PSA incompability it will be much easier.

Once I have time to continue my efforts we will make it happen, step by step we will narrow down the problem, just using our 3DSMax master's proposed procedure!

Edited March 18, 2014 by Hephaestion

[Radagast.]

That 3DSMax and Maya allow the REST pose to be the NeutralMatrix for any bone seems to be the reason for the distortion/incompatibility:

https://developer.blender.org/T38660

You see the similarity?

http://community.secondlife.com/t5/Mesh/Problems-with-Blender-and-Fitted-mesh-blend/td-p/2487943

So we need to figure what the rest pose scale is for each bone in our 3DSMax rig and GaiaClary may add an option, import into OpenPyrogenesis in the blender COLLADA exporter:

restpose_scale_x (default = 1.0)restpose_scale_y (default = 1.0)restpose_scale_z (default = 1.0)restpose_rot_x (default = 0.0)restpose_rot_y (default = 0.0)restpose_rot_z (default = 0.0)restpose_loc_x (default = 0.0)restpose_loc_y (default = 0.0)restpose_loc_z (default = 0.0)

Anyone knows what REST-Pose our 3DSMax rigs have? This might save all our animations.

My guess is .17 as I saw this in the scale field when I looked at the dude.blend. So if we are lucky ...

https://developer.blender.org/T38660 I asked GaiaClary if it's difficult to add a field to enter the specific rig's scale on import. So that it can be exported correctly. (this workaround is needed due to maya and 3DsMax allowing crazy things to bones.)

Edited March 18, 2014 by Hephaestion

[Radagast.]

Are we getting closer? Don't know why but this time with OpenSim setting enabled in blender's COLLADA exporter it suddenly seems to work (i'm sure I tried this before and it didn't help). The rotation thing could be due to my prop points rotation because I messed a lot with it ...

Edited March 18, 2014 by Hephaestion

[Stan`]

*cross fingers

Can i help you ?

[Radagast.]

If you could export an as new as possible COLLADA .dae file then this would be awesome, best one with animation included as we need some bones.

Perhaps your ox-wagon?

Other than that we can only hope that blender helps us out. I didn't know GaiaClary had already fixed it for Maya recently ... so if we are kind enough perhaps we get the option for specifying our own 3DSMax exported REST POSE scale, too.

[Stan`]

So here are four files.

Smd version of the cart

Dae - Zup

Dae - Yup

Dae - Baked Animation

Cart.7z

[Radagast.]

Sorry I forgot, it'd be very useful, if we could create a cube (no rush) with

• one vertex (out of 8) having full weight,
• 1 (out of 7 remaining) having half weight?
• The remaining 6 vertices then were available for influencing with 3 bones (or if we only have 1 vertex influenced by one bone then we could use 6 bones. (each bone should have a different transformation assigned, so 3 being translated/moved each along a different axis in the first pose (at frame 50?), the next 3 being each rotated around another axis (1 -90deg off around X, the 2nd -90deg around Y, the 3rd -90deg around Z)?)

Or any other combination you think that may easy to find more details?

The reason for the negative sign in the rotation is that I believe there's more that can go wrong then.

Perhaps we should even keep the bones influence tied to exclusively one vertex. Is this possible? A huge cube and tiny bones?

I also thought it might be interesting to make a custom texture and paint it so that the vertexs in the scramble would be obvious in their before and after positions.

So here are four files.

Hey thank you. Did you get your ox-cart into the engine already?

Oh, I just forgot, don't you also think we need the 1-frame-animated cube in two versions? Once with one or all bones scaled ? (rest pose scale?)

What do you think?

[Stan`]

Hi Hephaestion.

I ´ m not sure to understand what you want with the cube. IIRC vertex weights depend on the bone they are attached to. So let´s say if i make 12 bones î ´d have to set weight for each vertice and each bone. Is that what you want ?

No I didn ´t manage to implement it in the game. I don ´t know how to make skeletons Xmĺ ´s moreover I think there is some issues with max dae official because what happens with the mill is really weird. I wanted Wijitmaker to make a step by step import of the mill so i could learn and make a video.

Moreover we ´ll need a prop point for the cart to add boxes and stuff on it. Would also be nice to have an event only adding the props when it´s carrying something.

[Radagast.]

vertex weights depend on the bone they are attached to. So let´s say if i make 12 bones î ´d have to set weight for each vertice and each bone. Is that what you want ?

ah, you see, my knowledge is too small.

I think the bone-vertex weight that feels the most natural way to you will do. I just had no real idea if there was extra vertex weight or if it was the weights from the bone only. Always thought the bone weight were the region of influence .. and if I consider it, this may well be the same like the vertex weight. Essentially the vertex weight then is the way how influence range works!?

Then you can go for as few bones as you think are useful. I'm not an expert, if you think 8 vertices and 4 bones cover all cases already then it's fine. I just wanted to see the different effects of

• rotating a bone by -90degree around X,Y,Z .
  
• moving a bone by any unit, perhaps 1? (so that it's easily visible).
  

The skeleton xml I could perhaps do for you .. *adding to the list ... wait .. just looking for the end ... ah, there it is on page 753*

It's essentially just the .dae that you export. Though if there is no other mint skeleton around we first have to dig into the engine or use another similar building's skeleton as reference (only for the formal criteria).

hm .. tutorial you say? ... okay convinced I better leave it the masters.

Moreover we ´ll need a prop point for the cart to add boxes and stuff on it. Would also be nice to have an event only adding the props when it´s carrying something.

Wow, you already plan for our carrying and supplying units. cool. In blender a prop point is quite straight forward:

• place an empty (center of world?),
  
• parent it to the bone you want the prop point to move with.
  
• adapt rotation and refine the position relative to the bone it's attached to.
  

So far as what I know.

[Stan`]

Hephaestion Are you still here ? I tried stuff today. I didn't succeed in importing anything in the game, BUT I tried the milkshape stuff. So small stuff

Blender can import

-Ms3d

-SMD

-FBX

Ms3d can export

-Ms3d

-SMD (give interesting results see below)

-OBJ (Doesn't support armatures

-Collada, (Exports blank)

Everything is here and there is animation that was transfered.

Interesting.7z

Exporting two hand animation via sequence smd gave me an animated model missing the props.

Animation Exported.7z

Edited March 24, 2014 by stanislas69

[Radagast.]

Exporting two hand animation via sequence smd gave me an animated model missing the props.

Animated model in blender or ingame?

A blenderartist shared this link: http://usa.autodesk.com/adsk/servlet/pc/item?siteID=123112&id=20481519

Guess you already tested. Am loosing the overview. The prop points are no problem, we can import them later. It's mainly about the animation.

I doubt it will play right in pyrogenesis until either Gaia helps us out or we build a custom blender.

[Stan`]

Nothing works in the game...

But transfering bone animatin into blender was a first time. Thing is you have to clean the armature. Maybe a bone to prop converter would be nice. Even more if it could keep the animation.

[Radagast.]

Oh.

A bone to prop converter is doable. Should the orientation be inherited from the bone pose? I always though for each bone first another bone had to be added an to this bone the prop point be added to. Then the extra-bone could be animated, so the prop point would follow.

This means a prop points orientation has no effect currently. Only the position. Is that correct?