Animation Pipeline

[Radagast.]

You fixed it? Finally the old 50+ animations saved?

[Stan`]

Hmmm... Actually WijitMaker asked me if it was worth it since, sooner or later they will have to be remade. I asked him to ask Enrique, I'm waiting for his reply.

[Radagast.]

Did anyone try the 3dsMax -> FBX --> Ultimate3D -> MS3D --> Milkshape -> SMD --> Blender route?

First off I found an easy way to get 3D Max animated FBX files into blender using a set of steps..

1.First Save your finished and animated model to FBX format out of 3DMax

2. Using Ultimate Unwrap3D open the FBX if you are not able to open the FBX file download the FBX plugin from the Ultimate Unwrap3D download page here http://www.unwrap3d.com/u3d/downloads.aspx and while one is downloading the FBX plugin also download the Milkshape3D "MS3D" plugin.

"I tried using the Ultimate Unwrap3D Half Life SMD plugin but there is a problem with the animation exporting and importing to blender"

3. In milkshape load the MS3D file you saved out of Ultimate Unwrap3D and check to make sure all animations play correctly. then go to export to Half Life SMD. when you select it will ask if you want to save a reference or sequence first select reference and save file, then go and export again and select sequnce to export animations for mesh.

Now the final step, go to this link https://developer.valvesoftware.com/...nder_SMD_Tools and download the SMD blender tools.

once installed make sure the plugin is activated then go to import options. first import the reference model and then while mesh is selected go and say import the sequence mesh now all the animations will be imported and applied. and in blender when you hit the play button all animations should work correctly. Your model is now ready to be saved to a .blend format for saving to unity3D.

http://forum.unity3d.com/threads/122986-Small-Tut-From-3D-Max-to-FBX-To-Milkskape-to-Blender-to-Unity-Steps!!

Else is there a chance we can fix the incorrect rotation, scale and facing(object-normal) issues with a python script?

Can anyone give feedback on what exactly fails currently with the newest COLLADA importer and what of the above mentioned broken imported properties need to be fixed in order to save the old animations from wreckage?

e.g. Is the facing object still a problem? I think it's mentioned somewhere that this is fixed for the newer COLLADA importer (> 2.66 < 2.69) ?

The rotation we should be able to fix with a script (blender offers Quaternion|Matrice.inverted() method).

The scale is difficult as it defines the influence on the vetices, does it?

Historic_bruno said the .dae-Format is human readable, so there is a chance we could figure the correct values and try to find a pattern which values and axis are swapped.

Once we have the pattern we could correct those problems with a python script/extension.

For the scale in special this means we had parse the .dae XML to extract the correct scale values (if anyone knows where these correct values are stored). Then we could insert those correct scale values for each bone via python. The bone names or at least IDs are kept up, i.e. are the same for .dae and blender-bones, are they?

[Stan`]

Nope I had forgotten about smd format tried md5 collada collada max and fbx. In blender used fbx default fbx plugin and collafa importer.

We were able to have skeleton and props. But animation was screwed if you look at the logs of irc you may be able to find images of progress.

Thing is like i said maybe better animate from scratch now.

Anyway what was wrong is that max uo axis is zwhile blender is y up.

So things go wrong by 90 degrees even though in the exportation you have the choice.

Now wijitmaker gave me pmd source code in c++ for 3dsmax maybe someone could make an blender import export plugin an fix it for there was some bugs.

This way we should be able to import models from the game and not be max dependant animore.

I may try ultimate 3d if that helps.

[Radagast.]

One question. Is it possible to add an option for selecting up axis on export/import of collada files? ...

This should be handled by the exporter. The Collada file has an asset section where axis orientation, scaling, etc are stored. The Blender importer reads these informations and applies the values to the imported models. There is no need to specify axis or scaling during import. However the importer has an option for allowing to force blender to use the same unit system as the import. By default it scales the import to the current blender units.

Then this is relevant here. If there is no such options written by the old COLLADA exporter of Max, then that's our problem.

We could change the blender importer to transform from y-up to z-up or we add these tags in each COLLADA file.

[Radagast.]

Probably you have already tried that: (conversation as of 15th ..16th March 2013)

The armature / bones structure used by the player model is just the standard 3dmax biped so if you can import that into blender you are good to go.

Hmm, ok this tool seems to load at least the rig fine and can convert it to a maybe usable format:

http://oasis.xentax.com/index.php?content=downloads

Obviously there is still something not fully functional in the Blender importer.

You can export to valve smd from Noesis (http://oasis.xentax.com/files/noesisv4081.zip) and that will import the rig correctly in blender but the animations win not work properly in torque.

Why not if I reexport to collada and keep the original animation .dae files?

It didn't work for me when i tried and i doubt that the animations will work.

Yes, there seem to [be] issues with that too, in fact if I use noesis to just re-export the .dae the new file seems to crash blender

Btw, the skeleton in that Torque3D file seems to be ok if I open it with Blender 2.63a, so there is some sort of regression with the new collada import stuff too.

You are right the model and armature are imported correctly in Blender 2.63a and the animation from torque are played correctly too.

=> Have to check with 4 versions:

• one before NGons were introduced (<2.63 is fine),
• 2.63a,
• 2.66,
• 2.69 (daily build)

I have read through this topic and it made me feel sick how this is hampering the art department - and how much effort already went into this. So now we need to really fix it!

• We have a last chance with the SMD Milkshape Max->Blender method. Probably we have to try with both the blender FBX importer of that time (2012) and the current one.
• As a last ressort I will hack that COLLADA importer for us (e.g. fix the y-up to z-up problem via an option to force transfer from y-up to z-up on import).

  The messed up scale of bones I am much more worried about as it's difficult to fix automatically unless we find a pattern (difference .dae to within blender)?

• Any artist can tell me if it's only a visual problem or if the messed scale affects the DEFORM?Perhaps this can be fixed by forcing the blender COLLADA importer to use the units from the .dae file? (there must be an option)

Edit: v2.69 gets an animation rotation bugfix that at least occurred for animations exported to .dae from blender <2.69. So it's not directly our problem, but good to be aware of!

Edit: Saw that GaiaClary is still active in development. I'm pretty sure if we file a bug report now with the new system our problems will be solved. Just see here as an example of 4th of february where they fixed a COLLADA issue: https://developer.blender.org/T38482.

(Ton, chief of blender has declared COLLADA and with it compatibility to other 3D software a priority somewhen. I think it will get fixed if anybody knowledged enough may put together the relevant data.)

Edit:

Dec 2013: FBX Importer fails to import binary FBX (animation) out of 3DS MAX <- perhaps this opens the 3DSMax -> FBX -> Blender direct way?

Edited March 13, 2014 by Hephaestion

[Stan`]

I'll try to explain things as much as I can.

About Axis and scale : In Max there is an option when exporting to collada to choose axis as shown below.

IIRC Enrique reported that exporting with z-up fixed half of the skeleton. There is also an options for units. It has to be Inches. And you have to make sure you check blender option import units as shown below.

Collada has a tag in the files for that, don't exactly know what changing it does. In blender the skeleton gets face down, but nothing seems to have been rotated.

As I told you Blender Custom FBX imports stuff but only props pass by. You can see all the models we made on this thread. Some are missing because I exported it like 300 times.

http://www.wildfiregames.com/forum/index.php?showtopic=17630

About SMD's : I'll be busy in the upcoming week but if you give me something really precise to do I may be able to have time for you. Maybe there is a plugin for max.

About Max Collada (OpenCollada) : Until collada Max is fixed I'll have to use an older to use it which is version 1.3.0 that we don't want. So we're stuck with Max Exportations. I'm not able to compile the plugin on the internet.

About Bone scale : I haven't seen any problems so far see thread for reference.

About animations : there is something that can be an issue if you plan to import the dude model and the armature at the same time, because in max they were using the Physique Modifier because it's a lot more easier to use than the skin modifier, but It will break export.

Hope I answered everything.

Regards, Stan

[Radagast.]

Thanks for answering.

Could anyone propose a .dae file that I could send the main COLLADA dev of blender to check why it is screwed up? Also a video of how it should look like correctly would be cool.

For COLLADA the leaf bones length will never be imported correctly. That's because the system is different, blender uses bones with start and end while COLLADA stores each 'bone' as a point/node. So the length of the last bone may never be derived properly. (after Gaia Clary, the one and only that fixed all those COLLADA issues during the last year!)

Collada has a tag in the files for that, don't exactly know what changing it does. In blender the skeleton gets face down, but nothing seems to have been rotated.

IIRC Enrique reported that exporting with z-up fixed half of the skeleton.

The right tag is what the exporter in 3DSMax has set. And that's fine if it's z-up as you and Enrique pointed out.

The first tag is the scale factor to get SI units from the derived one. e.g. in your example:

<unit meter="0.025400" name="centimeter"></unit>

1 inch = 2.54 cm = .0254 m

That's why there is the factor. I think it's for the case that the importing tools isn't aware of how to achieve SI units. So this is the conversion factor applied to each dimension in the COLLADA file prior to any calculation. (As each calculation needs SI units.)

[sanderd17]

The first tag is the scale factor to get SI units from the derived one. e.g. in your example:

<unit meter="0.025400" name="centimeter"></unit>

1 inch = 2.54 cm = .0254 m

That's why there is the factor. I think it's for the case that the importing tools isn't aware of how to achieve SI units. So this is the conversion factor applied to each dimension in the COLLADA file prior to any calculation. (As each calculation needs SI units.)

AFAIK, the game just doesn't read this tag. It just assumes everything is in meters. The only thing you have to watch out for is that the tag used in the exported file is the same as in the imported file (I think by default, most programs use meters to export, so if you import a collada file with a different unit of measurement, your 3D program will scale it to meters on export).

[Stan`]

Thanks for answering.

Could anyone propose a .dae file that I could send the main COLLADA dev of blender to check why it is screwed up? Also a video of how it should look like correctly would be cool.

For COLLADA the leaf bones length will never be imported correctly. That's because the system is different, blender uses bones with start and end while COLLADA stores each 'bone' as a point/node. So the length of the last bone may never be derived properly. (after Gaia Clary, the one and only that fixed all those COLLADA issues during the last year!)

The right tag is what the exporter in 3DSMax has set. And that's fine if it's z-up as you and Enrique pointed out.

The first tag is the scale factor to get SI units from the derived one. e.g. in your example:

<unit meter="0.025400" name="centimeter"></unit>

1 inch = 2.54 cm = .0254 m

That's why there is the factor. I think it's for the case that the importing tools isn't aware of how to achieve SI units. So this is the conversion factor applied to each dimension in the COLLADA file prior to any calculation. (As each calculation needs SI units.)

Ask Enrique for the last Dae he had.

AFAIK, the game just doesn't read this tag. It just assumes everything is in meters. The only thing you have to watch out for is that the tag used in the exported file is the same as in the imported file (I think by default, most programs use meters to export, so if you import a collada file with a different unit of measurement, your 3D program will scale it to meters on export).

Well I need to export it in inches.

[Radagast.]

Thanks, I will wait, there is no rush.

You need it in inches ... to make it work? In blender, 3DSMax or in the game engine?

The tag as it is currently takes your units as inches and transfers them to meters. If the tag is ignored by pyrogenesis, this means you have it in the engine as inches (because the scale conversion from inch to meter is ignored like you quoted).

[Stan`]

Well If I export in meters or centimeters size won't be good in the game at all...

Yeah but for some reason that importation detail matters.

[Radagast.]

Ah okay, I think the factor is not multiplied but instead divided by in the import process of COLLADA.

Thus the parameter specifies which scale the .dae content has in relation to SI units (meters)!

So to get meter, the COLLADA content has to be divided by that number .0254 before each calculation (that requires SI units).

I wonder what the centimeters is for, it looks optional as it can be derived from meter="0.0254". And really strange that is does not read inches. But well as it's just a name it seems not too important. And centimeters is in the same magnitude.

But anyway if it is ignored by our engine the scale of your objects in blender simply mean that what you get is what you export.

It could be problematic only if you force blender to use this unit tag to scale the COLLADA objects according to this parameter.

On export the object is stored and its unit it put into this unit tag.

So if pyrogenesis ignores it, it probably treats it as meters. So the pyrogenesis essentially does not use meter but .0254 as this is the scale you had to use in blender.

Can this be confirmed by anyone?

Or does pyrogenesis assume all models are in inches and applies a hardcoded scalefactor? Hence the need to export in blender with those units? Or the blender units are different.

However. If you state it works when modelling in inches (1unit = 1inch = 2.54cm) then it's fine.

Re: collada Unit

COLLADA stores the unit of distance measure of the real world values in the document or asset.

It means that all the real world values of distance and position in the asset (document in this case) are in centimeters. For example, a vertex position of (1,2,3) means (1cm,2cm,3cm).

If your application works in centimeters (like Maya) then you're fine.

Otherwise you may have to apply the appropriate scale to bring the values into proportion with other objects that are modeled with a different measure of distance. For example, if your viewer is using meters (and you care, i.e. some tools are unit-less) then you would scale that vertex position to (.01m,.02m,0.3m) with the <unit> information.

Examples of real world values affects by the unit of distance include:

• position[/*2rtx1zhu]
• translate[/*2rtx1zhu]
• scale[/*2rtx1zhu]
• matrix[/*2rtx1zhu]
• lookat[/*2rtx1zhu]
• znear and zfar (of cameras)[/*2rtx1zhu]
• gravity[/*2rtx1zhu]
• animation data of any of the above[/*2rtx1zhu]

[Stan`]

Actually max does *** with that tag blender writes units okay but can't import skeletons the good way.

I've been trying an smd exporter for Max, best one you can find on the internet. Blender imports it correctly but screw everything when exporting to collada.

Moreover props are converted to bones which is not good...

Tried with the OX cart too rigging is lost and moreover scale too.

Edited March 13, 2014 by stanislas69

[Radagast.]

I've been trying an smd exporter for Max, best one you can find on the internet. Blender imports it correctly but screw everything when exporting to COLLADA.

At least this is a hope. I think we never got the rig playing correctly in blender before ...

props are converted to bones which is not good...

They should be empties, each parented to a bone, now the empties are gone, right? (important for the planned bug report, essentially I think the removal of empties can be fixed very quickly by Gaia, could you attach your files please)

Edit:

Tried with the OX cart too rigging is lost and moreover scale too.

You also used the SMD export-import way here?

Do you mean the trader's cart? Have grepped the complete repo, no ox_cart found.

Edited March 13, 2014 by Hephaestion

[Stan`]

That's right. Do you want the blend files ?

Ox cart is WIP, I used it to learn how to make animations, and should be used for one of the civs when I'ts done <--- When I find a way to get it in game

Edited March 13, 2014 by stanislas69

[Radagast.]

I feel tempted to try it myself. The problem is I have three heavy programs launched since 4 days. If I now start blender ... okay convinced, I will try it.

Shouldn't we better place it in our 0AD CoM repository? We could open a repository like 'generic' where all files go we don't know where to put in. May also be called default or common.

I will also create a repository for my AI works now .. or wait, better after my thesis. Ha, why not use generic repository for the HybridAI too? (have tried to keep up the directory structure of 0AD in the generic repository)

[Stan`]

What kind of files do you want to put there ? What Is great in 0ad is that people coming on this thread will be able to understand what we went through and how we hopefuly fixed it. If we start moving to other places or PMing people will loose the story.

[Radagast.]

Of course. I only mean the files going there, not the conversation.

It's easy to keep the files there up to date (even with revisioning system). Whereas one will not that easily go back to old posts only to update the attachment.

Edit:

What kind of files do you want to put there ?

• Files that are or might be common to all mod packs (e.g. my HybridAI, a flower that was there in roman and viking times, a whale, ..).
• Files that we don't know where to put in (that might have a target, might be special and fit in a separate mod-pack repository but this not yet exists. Hence this file first goes into generic. Later it may be moved.).
• Any ideas for further usage? any common, generic, default things.

Supporting files (like .blend) could also into a separate development repository for saving bandwidth for the mod downloads. It would essentially be a share repository for artists, devs, ...

Shall we call it share or development?

Edited March 13, 2014 by Hephaestion

[Stan`]

Yeah sure. We need to fix this for 0.a.d sake...

[sanderd17]

Yeah sure. We need to fix this for 0.a.d sake...

Right, we have an art repo, but it's not public due to copyrighted material in it. There were plans to make a new, public repo, and maybe even move old stuff from the private repo to the public one. But I guess we need to get this started again.

[Stan`]

Actually I meant fixing the skeleton until better stuff is done.

But that's a good idea aswell. Though can't you ask people to give their work under the new license ? Since they are no longer here ?

[feneur]

Actually I meant fixing the skeleton until better stuff is done.

But that's a good idea aswell. Though can't you ask people to give their work under the new license ? Since they are no longer here ?

Well, there are e.g. reference images etc which we don't have the rights to show publicly.

[Stan`]

I didn't knew references could be copyrighted, I mean If you want to copy something in an historical point of view you can no ?

[sanderd17]

I didn't knew references could be copyrighted, I mean If you want to copy something in an historical point of view you can no ?

References that aren't historical (I.e. impressions by other artists) are always copyrighted. So they can be used as inspiration, but can't be distributed publicly (there's no problem with sharing it with a select circle of friends though, most countries have such an exception in their copyright law).