Animating turorials for O2

[maddogx 13]

Does anyone know of any good tutorials for making unit animations (rtm files) with Oxygen?

I've been playing around with the built in functions but somehow it's taking me ages to do the most basic things and it seems very inefficient. I'm probably just overlooking some functionality.

I checked the Biki but no luck.

Alternatively, are there any good freeware programs that can get the job done quicker?

[Synide 0]

O2 isn't really very good with character anims... oh, sure it can be done, but as you've discovered it is labourous and the results are quite often not really what you'd hoped for...

Perhaps if you detailed a little about what you wanted to try and do... I or someone else might be able to suggest some options for you (or not)...

[maddogx 13]

O2 isn't really very good with character anims... oh, sure it can be done, but as you've discovered it is labourous and the results are quite often not really what you'd hoped for...

Perhaps if you detailed a little about what you wanted to try and do... I or someone else might be able to suggest some options for you (or not)...

My main aim is to create some new animations, such as get-in/-out anims for vehicles, character animations, etc.

Static animations (such as lying down) are pretty easy even with O2, but anything that requires several movement frames becomes very tedious.

It would be nice to have an animation tool that showed a simplified skeleton, where all the characters joints can be twisted and moved within natural limitations. As far as I can tell, O2 does not restrain the movement and twisting of body parts in any way and the parts do not affect each other when moved, which means you constantly have to watch out that the body looks like it's in a natural position.

This is the main problem that is hampering my efforts right now.

[blackjack-VS- 0]

MadDogX i've tryed some months ago to creat a "pack" with a custom bis soldier + skeleton, ready to animate in XSI ModTool, that is one of the best tools around for animating, and FREE.

So, thanks to Synide so far we got almost everything working. If my memory doesnt trick me he sucefully got almost done, to the point that it only misses an exporter in XSI that creates a new rtm file.

If i remember eight the process was:

- open a soldier.p3d file in o2, then open there any rtm animation and then save again the p3d with a new name.

-get synide awsome tool, then open the new p3d and run the tool. it will creat a lwo (lighwave format) 3d file and 1 mda file with the animation information.

- go to xsi mod tool and open the lwo and then import the mda file. At this stage we have a bis soldier with correct uv's + materials + named selections + perfect bis animation.

- now i've plan to make a skeleton in xsi mod tool, and attach it to the imported bis model in lwo format.

-After we should be able to use xsi mod tool to change animations, or create new ones. This takes some know how off course. But a couple of videos and you'll be able to animate properly.

-Now the only thing that is missing is a way to export this new custom animated in a rtm format, so that arma can read it properly.

Maybe Synide could make this work someday, but i'm pretty sure it will be time consuming, and needs some motivation. I'm not sure if any of us still have that needed motivation at this stage.

[maddogx 13]

@ May 05 2008,21:41)]MadDogX i've tryed some months ago to creat a "pack" with a custom bis soldier + skeleton, ready to animate in XSI ModTool, that is one of the best tools around for animating, and FREE.

So, thanks to Synide so far we got almost everything working. If my memory doesnt trick me he sucefully got almost done, to the point that it only misses an exporter in XSI that creates a new rtm file.

If i remember eight the process was:

- open a soldier.p3d file in o2, then open there any rtm animation and then save again the p3d with a new name.

-get synide awsome tool, then open the new p3d and run the tool. it will creat a lwo (lighwave format) 3d file and 1 mda file with the animation information.

- go to xsi mod tool and open the lwo and then import the mda file. At this stage we have a bis soldier with correct uv's + materials + named selections + perfect bis animation.

- now i've plan to make a skeleton in xsi mod tool, and attach it to the imported bis model in lwo format.

-After we should be able to use xsi mod tool to change animations, or create new ones. This takes some know how off course. But a couple of videos and you'll be able to animate properly.

-Now the only thing that is missing is a way to export this new custom animated in a rtm format, so that arma can read it properly.

Maybe Synide could make this work someday, but i'm pretty sure it will be time consuming, and needs some motivation. I'm not sure if any of us still have that needed motivation at this stage.

That sounds absolutely fecking brilliant! I hope you guys get it done.

I haven't heard of XSI mod tool before but I'll check it out. Just in case you have a change of heart.

[Synide 0]

O2 isn't really very good with character anims... oh, sure it can be done, but as you've discovered it is labourous and the results are quite often not really what you'd hoped for...

Perhaps if you detailed a little about what you wanted to try and do... I or someone else might be able to suggest some options for you (or not)...

My main aim is to create some new animations, such as get-in/-out anims for vehicles, character animations, etc.

Static animations (such as lying down) are pretty easy even with O2, but anything that requires several movement frames becomes very tedious.

It would be nice to have an animation tool that showed a simplified skeleton, where all the characters joints can be twisted and moved within natural limitations. As far as I can tell, O2 does not restrain the movement and twisting of body parts in any way and the parts do not affect each other when moved, which means you constantly have to watch out that the body looks like it's in a natural position.

This is the main problem that is hampering my efforts right now.

Hmmm... well there are some issues...

Ok, so you want to create say a set of new anims for a standard BIS character.

So you need the BIS Characters mesh over in your favorite animation software.

Some of you have professional software such as Maya & Max.

Very good alternatives are Blender and XSI Mod Tool. (Both free)

One of the previous beta versions of O2PE has an export to 3Ds format. So, you manage to suck this 3DS into Maya/Max/Blender/XSI, but discover that the resulting mesh doesn't have the same number of verts and poly's and worse doesn't have all the 'named selections' and 'weight maps'.

So, you'd be faced with having to manually assign parts of this mesh in whatever tool to the 'named selections' - way too difficult. And, you be forced to 'paint' weight maps in whatever tool - they may even end up semi close to the original values from over in O2 if you spent long enough - again way too difficult.

So, lets say for arguments sake you manage to get a 'perfect' mesh over in whatever tool and with all it's appropriate allocated 'selections' and the very important weight maps.

Well, then you'd just make use of the 'whatever tools' animating features (probably skeletal based) and rig it etc.

Create your 'new' anim sets. Then you are at the stage where you want to get the anim back over to O2 and ArmA.

What are you're options? Hmmm... you could create a plugin or write a script in the respect Animation application to export an .rtm file out of the software directly - not a trivial task. Also, you have to keep in mind that during it's time over in your whizzy animation package the 'exported mesh' would have had to have been very studiously kept unmodified.

This is because if you modify your Character mesh too much from would it looks like over in O2/ArmA when you export the .rtm (using your whizzy plugin/script in Maya/Max/Blender/XSI), the anim. will probably have some ungainly, unsightly interpolations between your 'new' anims and the current sets of BIS anims for that character.

So, if you plan to supplement or integrate your new anims with existing BIS anims then you'd have to be very careful and concious of not altering the 'reference mesh' over in Maya/Max/Blender/XSI etc.

Another way of getting the anim from your whizzy animation software over to O2PE/ArmA is that some of these applications will allow you to export an MDD point cache file.

So, you've managed to get this .mdd out of XSI or Blender... you'd need to write your own application for integrating this mdd into a p3dm model. And, once that's done then you'd simply open the p3dm in O2PE and your animation would be there already and you could then use O2PE's export .rtm function to create the .rtm.

The problem with this process is that a .mdd point cache animation sequence is exactly that, it is an exact listing of x,y,z cordinates for each and every vertex over a period of time. So, once you create a .mdd it HAS to be applied to the exact same list of verts in whatever application your mesh happens to be in. Otherwise you can end up with unsightly artefacts etc.

So, those are some of the issues if you are planning to do some new animations sequences with EXISTING BIS characters and/or wanting the new anims to work with BIS existing anims for characters.

You should note that all of the BIS current character models are of a distinct, specific size. ie. their height is 1.8m and not sure of the 'standard' girth.

Now, if you wanted to bring a totally 'new' sized and shaped character into ArmA. Say, a female character that is say 1.6m tall or a 14-yearold child-soldier character at 1.4m tall (for instance).

You possible could use some of the existing BIS animations with these new characters but you'd probably have to make duplicate copies of the the existing BIS ones and then go through a process of scaling the copied .rtm's. This would involve extracting, devolving the matrices transforms out of the rtm and then scaling them to appropriate proportions to match up with your new characters size and shape - not a trivial matter.

It would be less trivial and work to just create the entire gambit of anims for you newly shaped character.

So, lets say you've managed to create a newly sized and shaped character and all of the necessary basic anim sequences for it and not relying on utilizing any of the BIS anims 'cause they are for a different sized character.

Then you've got to get the mesh over to O2PE from Maya/Max/Blender/XSI... and once over in O2PE it should be either so close to what it looked like in the other modelling package or preferrably exactly the same in the number of verts. and poly's.

Then you either make use of your whizzy plugin/script from Maya/Max/Blender/XSI to directly create the rtm or have those packages create mdd's and then create an application to integrate these mdd's into a p3dm version of your new character model and then utilizing O2PE's export .rtm function.

Also, on top of that is... , lol...

If you and I create a newly shaped and sized female character and the margin of difference in the sizes and shapes are too different then probably you would get noticeable and crappy looking interpolations between your girls' anims and mine... meaning our respective sets of anims may not be interchangebale or useable by other modders.

So, if(when... ) the community starts pumping out new characters models of child-sized insurgents carrying belts of ammo over the shoulder and toting an AK there would more than likely need to be a general concensus on what 'size' they should be so as to facilitate re-use and seamless interpolation between your anim sets and mine...

those are just some of the issues...

As you read in Luis' post above I have been working on all this sort of stuff to facilitate a character development workflow primarily for myself and maybe for the community, however over the last couple of months I've been taking a sabaticle too deal with and organize some RL stuff.

I will probably get back to it at some stage soon'ish

Also, as mentioned above personally, I see the use of XSI Mod Tool and/or Blender as the tools of choice for the majority of the ArmA community to do there animation in for ArmA... XSI Mod Tool is very good... it's a cut down version of XSI SoftImage and has more complete features than most modders would ever need or utilize and has a substantial SDK and free. Blender is no slouch either, but personally I don't like it's UI. However, I would drop both these tools in a heart beat as recommended for game modding if(when) Modo has a more complete animation system.

So, to summarize... the workflow pipeline I see in the (hopefully) not too distant future for the majority of the ArmA community is...

O2 -> XSIMT/Blender -> Modify, tweak, create, animate -> O2.

or...

XSIMT/Blender -> Create new content, animate -> O2

or... for the percentage of you who have Maya/Max...

Maya/Max -> XSIMT/Blender -> O2

Still feel up too it... ?

[max power 21]

There is a BIS skeleton bound to the max biped ready to animate out there. It's not necessary to animate your character, only the skeleton in order to generate the necessary point transformations. You'll then have to weight a new character in o2, I suppose. But for the stock characters, it should be enough. I have not yet looked into the generation of rtm files but I hear that it's possible. Synide, have you heard of this thing?

[Synide 0]

There is a BIS skeleton bound to the max biped ready to animate out there.  It's not necessary to animate your character, only the skeleton in order to generate the necessary point transformations.   You'll then have to weight a new character in o2, I suppose.  But for the stock characters, it should be enough.  I have not yet looked into the generation of rtm files but I hear that it's possible.  Synide, have you heard of this thing?

I have heard of it... haven't seen it... from what was described too me and based on my own experiments of getting a BIS reference mesh into Max and the appropriate stuff back out of Max into O2 I'd imagine that someone has done a hell of a lot of manual labouring... Which in my mind does not provide for a good repeatable, reactive and iteractive workflow.

Yes, I realize you don't need to animate the character... but what you do need, to be perdantically perfect, is the correct vertices allocated to the appropriate selections or envelopes or whatever terminology Max uses in Max... and preferably you need the mesh in Max to exactly replicate that which is in O2. Also, I need the weightings to be perfect, you or others may not, but I do...

I could create some new rtm's based on a similar mesh proxy in Max/Maya/XSI tomorrow... but I'd always feel they could be much more accurate...

Why you ask... here's an extreme example...

Take the standard BISoldier.p3d model right now from BIS... and scale the model in O2 by a factor of Ten (10)... save the model, place a config around it and call it something helpful in the dropdown list of soldier units in the Mission editor and load it up in ArmA (the game)... you'll notice right away that the giant sized soldiers rtm's are not really working very well... so, this graphically (and obsurdly) highlights that ArmA's rtm system is size/proprtionally/volumetrically specific.

Ok, so the Max model you refer to and it's accompanying rigged skeleton are not vastly different from the BIS ones so, in your case they or you will probably be getting away with it...

Here's a subtle example, lets say that this mesh in Max you refer has the left-hand a little bigger and/or the weightings are not quite the same as the O2 version... and you do a new reload animation in Max and you happen to stop the left-hand moving at just this particular position in Max because that's where it looks like it should be stopping based on the mesh you have the skeleton mapped too... then you create your rtm... fire it up in O2 and discover that the rtm when applied to the BIS p3dm doesn't quite move or stop or grip where you anticipated...

What do you do? You either, exagerate the movement a little more in Max, past the point where you would logically stop based on what you are seeing in the mesh deformation and then recreate the rtm... or you'd cajole the mesh in O2 using it's basic manipulation tools...

In my mind, this is along with many, many other little niggly things you gotta do, slowly but surely leads to workflow creep and ineffeciencies...

Would it not be better to have a workflow whereby, you think, hey I'm gonna tweak or create a totally new anim for character X, and so you export the mesh to Max/Maya/XSI totally safe in the knowledge that the mesh you are looking at in Max is proportionally exactly the same as the one in O2 and has the same 32 verts allocated to the left eyebrow with exactly the same weightings per vert.

Then all you have to do, is scale you skeletal rig to the mesh... do you're anim. and produce you rtm...

Ofcourse, I maybe talking out a hole in my arse... somebody else out there may have already imported a perfectly formed and perfectly weighted reference model into Max, good for them... I'll still work on my whole workflow for myself...

I suspect however, that the mesh in Max is not exactly the same as it is in O2 and that the weightings have been manually done on the evelopes, if they're even using evelopes or weightings at all...

And, while the resulting rtm is adequate for most...

I've been working on a female and a child-soldier that ARE of distinctly different proportions to the current BIS characters and therefore will be entirely incompatible with the current stock of rtm's...

At one point it was my intention to have Max as my weapon of choice for the aninmation etc. as it's sdk object model structure, eveloping etc. seemed to fit.

However, I personally came across a few issues that I decided that for me too overcome them while achieveable I didn't want to expend the time and effort to learn yet another sdk/object model/api to get what I wanted.

At the point I left the Max initiative alone I'd achieved the following...

I could transfer a mesh and it's allocation of verts. and polys from O2 to Max with UV's in perfect order. However, I had yet to allocate evelopes in Max representing the appropriate weightings as per O2 so as to facilitate the production of new anim sets in Max.

I had re-written TeaCups MaxScript to import an existing rtm in good order and export an rtm.

But without the weightings all nicely allocated I was faced with the prospect of either doing it by hand... Which I  don't like, 'cause it invariably ends up error prone... or delving more into the programming sdk/api side of the Max object model to overcome it...

Also, while I admire FBX's ability's it didn't have the necessary access to coding resources and intimate documentation I desired.

So, at this point I started evaluating alternatives... Using OBJ format as the import/export mechanism with O2 imo is fraut with flaws as I discovered after awhile... the techinicality's I won't bother with here...

I came to the LWO (Lightwave format)... And, discovered that it supports pretty much all the necessary capabilities that O2 p3dm files can handle and is a very well documented file format...

It's cousin file format LXO from Luxology is pregressively becoming (for me anyway) the most elegant and feature rich modelling file format I have come across... I already loved Modo's UI and workflow for modelling and it became a great bonus for me to create a nice little couple of programs to facilitate O2-Modo 2-way... although I've only publicly released a p3dm2lxo converter I have a well used lxo2p3dm that in my latest version can now inject a mdd into the resultant p3dm.

Sadly, while LWO/LXO and Modo have been great for me... Modo's animation system is lacking at this time... Luckily, there a great many commercial & free animation programs out there that can bring in LWO format.

Softimage XSI is a well renowned modelling and animation tool... it has a cut down free version XSI Mod Tool with a most impresive SDK. If I didn't prefer Modo I'd settle on XSI Mod Tool as the complete replacement for O2.

From my investigations I've concluded that it would be possible to completely do away with the dependence on using O2PE to create well-formed P3DM's for use in ArmA.

With enough labouring and coding one could concieveably create all the appropriate O2 specific info. in XSI Mod Tool.

And, have it capable of reading/writing p3dm's, rvmat's and rtm's directly...

The benefit's would be that XSI Mod Tool has orders of magnitude of modelling capability over O2 in form, function and useability. Added to that it has a pretty comprehensive rigging a skeletal animation system. The vast tutorial and documentation relating to Softimage XSI is directly relevant in it's smaller sibling.

Currently, there are some problems with importing and exporting LWO format with XSI Mod Tool and the Point Oven LWO plugin.

That's what Luis' is trying to give me the guilts on (only joking matey) finishing off.

I have partially started a LWO Import/Export plugin for XSI Mod Tool in an effort to overcome Point Oven's failings in this area but at this time it's on hold for Real Life...

While partially started, I can already see that really, where ArmA is concerned one wouldn't need the LWO intermediate step in there... With XSIMT, if one is going to the extent of creating a plugin to read/write LWO's better, then it's quite doable to just read/write P3DM's directly.

I wish I had a commercial licence for Modo as the latest version comes with a new SDK. (SDK is just covering file import/export at this time)

I know I've rambled on about inconsequential stuff that only has slight relevance to what you were talking about... but, hey, there's some more background info. for you...

To get back to what you were talking about... To be honest I haven't seen the inner workings of a rigged Max BIS reference character... but based on my own work... unless they/he/she has done a workflow along lines I've talked about, or if I haven't described it very clearly, then along the lines of the workflow I have currently mapped out in my tiny brain then it will have flaws. And, for me sort of 'pretty-good' , isn't good enough...

If I could get a bit more technical... for instance... if you are using this mesh and rigged BIS reference character over in Max... and let's say it's for the us_soldier_sniper.p3d, and lets say you have this mesh in Max, unless it's poly makeup and vert count and allocations of verts to envelopes and weight maps in Max is exactly the same as it looks in O2 the rtm you create from it and then utilize with the existing p3dm will probably have subtle interpolations issues...

I should point out, that this maybe entirely acceptable to some modders, but for me, I know that it can be perfect, and so, unfortunately, I can't fully immerse myself in modelling and animating until I know that I can have flawless workflow to/from my modelling animating programs to ArmA... unfortunate side-effect of being anally retentive, I'm afraid...

Here's another example... the 'King' character in ArmA is rather large/fat right?... Well, there are a whole swag of specific rtm's just for him... for use in his cutscences for instance...

If you go through the standard BIS rtm's for all characters and ran them over this 'fat' character, occassionaly you will come across and anim. where he'll move his arm, or something similar through his own body mass... this is because that particularly anim. would have been created with respect to the standard BIS soldier model proportions and the transforms in the rtm are expecting to move/scale & rotate a 'selection' verts. that are not similar enough in 3dspace to the king's arm... get what i mean?

And, on top of all the drivel above, I still haven't covered my investigations and tinkerings with using Maya or Blender as the animations package... haven't really talked about Blender, 'cause I personally don't like it - s'just me...

[blackjack-VS- 0]

Jeeez Synide it wasn't my intention at all to trigger you like that!! But now after reading it all carefully, thank god that i mentioned your name. This was a really nice reading (for me at least), and it's the confirmation that you really know what ur talking about.

From your detailed explanations, i realized that it's totally possible to a xsimt only workflow, relating all the aspects involved (p3d,rtm.mtl), which is a great revelation. Not that i did anything for arma so far, and i guess i'll never will, but knowing this is a good premonition for the next game at least.

I know real life isn't compatible with the desired/needed free time for all of this, but it's great to hear your 2cents on this subject.

Just 1 detail...we didn't helped our buddie here with any animating tutorial for o2.... I hope we didn't scared him!!

[Synide 0]

Yes, I know... brain explosion...

@MadDogX... short answer is, not really any tuts out specifically catering for character anims. for ArmA.

For effective workflow you'll need to either build you're own rigged char. over in another program or acquire someone else's rigged char over in Max/Maya/Blender/XSIMT etc.

There's the russian rtm Maxscript (which you'll have to modify) to export an rtm outta max, or TeaCup's Maya version.

Animation tuts for those packages are widespread...

That's all you've probably got available atm... cheers.

[max power 21]

The model doesn't have to me weighted exactly as they are in arma. It only has to be weighted so that the deformations are good. ArmA's character deformations are pretty good, so it would be good to use them as a guide.

The mesh in max is an arma skeleton that is bound to a max biped. The biped has been set up to fit the arma skeleton. What is left is to record the point transformations of the arma skeleton in a format that arma can use, etc.

I don't know if you can export the rtm files and if you can I don't know how you would edit them. The keyframes of mocap are usually fairly nonsensical from an animator's standpoint. They don't animate from pose to pose with breakdowns, but take snapshots every portion of a second, say, 1/24th, and interpolate between them. Cleaning up mocap keys would not be worth it for most people.

XSI has some very good animation and rigging tools. Max seems better to animate with because of character studio. I am, however, getting a free xsi license for a year because one of my instructors at school is a (was the first) certified xsi instructor. I am interested in your research regarding softimage's tools. A fellow student explored using ModTool to generate meshes for his reel but found the interface very strange compared to the commercial XSI. I suppose it, like anything else, takes some getting used to. Hard to justify under extreme deadline pressure!

Regarding obj format, I am interested in the flaws you speak of. If you do not wish to go into it here, I would be interested to hear it in another thread or a PM if you find yourself feeling chatty in an idle moment.

I feel guilty for not liking blender. Its interface stabs me int he soul but its community is so open. They share all kinds of really useful information and assets!

Here is the thread about the arma skeleton / character studio files.

http://www.flashpoint1985.com/cgi-bin....72;st=0

[Synide 0]

True, for influencing an existing ArmA p3dm mlod with a newly created rtm from Max or some other tool, yip you can get away with not having your mesh in Max weighted for most of the larger transforms, but I'd definitely recommend having the verts in Max weighted as closely as possible to those in O2 for smaller more subtle facial movements...

And, as stated, because I'm a perdantic perfectionist if I was using Max to create new ArmA character anims. I'd personally want the mesh to exactly duplicate that in O2 and have all the appropriate 'named selections', and weightings, why? Because I want to see what the mesh deforms like in Max exactly as it would over in O2 before I export my rtm, mainly to reduce the number of iterations one invariably has to go through to get these things working...

Exporting an rtm out of MAX is pretty straightforward...

Unfortunately I have never seen any mocap data in the raw so I dunno how easy it is to write a converter to go straight from 1 of the mocap formats to rtm. As I've never delved into the mocap area I wouldn't know if there were IFF or ISO standards that they adhere too for the file format or anything...

I'd imagine the mocap data is probably some sort of point cache format but whatever it is, it probably wouldn't be that esoteric and may even be widely documented... dunno.

And, although I realize that capturing mocap is way more efficient I don't have access to that sort of gear so have consequentially never appraised the vagaries or virtues of the tech.

Don't really like Max, don't realy like Maya, like you, I feel I should like Blender, but don't, never used XSI, have found my tinkerings in Mod Tool difficult 'cause the UI is a bit hard, but not as hard as I found Blender.

Blackjack[VS] is a keen XSI'er, so he's probably got some useability tips... I'm in love with Modo.... and I'd use that only if it covered off the anim. stuff... but it doesn't so until it does, my workflow will probably include XSI Mod Tool for the character animating.

I'll have a squizzy at that thread... must admit I've been a bit lax the last couple of months on what other people are doing in ArmA...

Edit:

Yeah, had a look at that thread... remember breezing over it last month in a rush... while interesting, doesn't really suit my needs, and the mesh in ArmA_Skeleton.max looks like it's based on something I fired over to bdfy a while back, but just as easily may not be... as I'm no longer interested in using Max as an animation tool I stopped progressing my import/export of mesh and/or rtm. stuff... at the time I was using the DeParma rtm script (modified) to facilitate this... and my own MaxScript that loaded a 'Universal BI txt' file produced from the previous beta version of O2PE that had the exporting capability to bring in the mesh perfectly formed and allocated the selections... Then, I'd written another MaxScript to write out a similar 'Univeral BI txt' file for importing a whatever mesh in Max over to O2 to bypass using OBJ or 3DS format over to O2... 'cause those both have issues...

At this point I was trying to decide whether I was going to use SkinClusters rigged to a skeleton or whether I just stuck with mesh objects rigged to a skeleton... and was investigating/tinkering with this when I decided I just didn't want to delve into the Max API Object Model anymore...

The troubles I found when looking at skin Clusters was that I wasn't sure if I could then reverse out the appropriate scale, rotate & translate matrices after creating a new anim sequence...

And, I realized that it probably could all be done quite easily if you knew the Max Object Model well and MaxScript or the API quite well, but I wasn't willing to get to know these quite well as it requires too much time...

After all that mucking around and time spent, I discovered that I could reproduce the same effects above in half the time using LWO, Modo, MDD, and XSI Mod Tool...

See here's a tidbit for you... When O2 loads an RTM file against the model you've got currently open it turns it into a 'Point Cache' in memory and when you save the p3dm at this time the 'Point Cache' gets saved in the p3dm as an '#Animation#' chunk.

So, what does this mean? Well, there are 2 ways you can make an RTM file...

1. You can create the rtm yourself using either a tool you develop or a script in another animation package.

2. You can create an mdd point cache file of the new anim from your animation package... many Anim. Apps can already do this... Blender, XSI, XSI ModTool, Modo, Lightwave, not sure about Maya, don't think Max can...

And, using another tool one can inject the mdd point cache file into a p3dm. Open it in O2 and the animation is there waiting for you... at this point you can use O2's ability to save out the rtm...

There's one problem with mdd files... they are vertex specific... I won't drivel on anymore about them...

Hmm,

OBJ file format... The main problem is ArmA, O2 and most modern 3D Applications Max, Maya, Modo, whatever can support discontinuous uv sets, however the OBJ file format doesn't... The only way you can overcome this using OBJ is to duplicate verts.

What does this mean... well say you have a O2 Model that has 1000 faces with 3000 verts and 500 of those verts UV's are discontinuous. To convert this p3dm out to OBJ and still keep the appropriate UV mappings you'd have to create 3500 verts in the OBJ file version, 500 of these would have the same x,y,z coordinates as there duplicates, but have different UV's from the original point.

That's one reason why I dumped using the OBJ file format as the medium to move stuff to and from O2... And, why I created 2 tools to go straight from LWO to P3DM and vice-versa.

Also, OBJ doesn't support weight maps, well not the sort I need...

[dachevs 1]

try:

AnimationTool