Curious if anyone has heard of plans for FBX support with AM? It would be interesting to see the two best (in my opinion) pieces of animation software interact. And the advantage for AM would be with FBX export they would support a format compatible with literally every software package from Strata 3D to Maya.

Brian

It would be nice. But a quote from Martin rings in my ears....."AM won't become an animation plugin for other packages."
Aside from that, if you modeled in polys and brought it into AM, you know the problems that brings with animating it.

Well I see it as not a plugin for other packages. But as a good format for file exchange between other packages. If AM had FBX export/import that would give access to being able to work with any package on the market.

Polygons and Splines just don't mix.

Cheers

I thought Hash's renderer tesselated the splines into polys at render time? I could be wrong, but I remember reading that somewhere. Plus if Hamapatch a piece of freeware can easily convert between poly and spline with very clean results, I would have to disagree with you. Plus AM actually does a decent job of converting the majority of the time. I think it would not be to much of a hassle to support FBX, especially since the export SDK is free. But I will not further this discussion as this forum is about reusable motion and we are going off topic.

Sounds like if Hamapatch can do spline-to-poly no-problemo than the question is can A:M .mdl's be imported into Hamapatch...and I have a feeling the answer is........................................no.

Hamapatch could import and export .mdls back in the 8.5 days, at least. I never personally tried it, because it's a PC only product.

Hamapatch is my exporter of choice. You won't find a better .obj exporter for AM. and now it supposedly supports 5 point patches.. the only thing it didnt support before.

It reads AM models easily and exports them as well. It also has a few nice modeling tools. one of wich is indespensible. A slicer. Cut your model in half easily. Not sure how well it will come back to AM, but from experience, shouldnt be too bad.

C

What Colin said.

Brian

Um. Actually that is incorrect. The FBX SDK is free.

http://www.alias.com/eng/products-services/fbx/index.shtml

No fee is required. Also the freeware Wings3d has fbx support. I don't see them as being able to afford fees.

Brian

At the risk of going hoarse from repeating myself:

There is no conversion format for Animation:Master, either models, materials, or animation. It is impossible.

How would the Hash splines be handled by FBX?
How would "relationships" be handled by FBX?
How would "SmartSkin" be handled by FBX?
How would FBX parse the A:M expression fields?
How would the overloading be done?
How would the automatic rescaling be done?
How does FBX interpolate A:M channels?
How would FBX handle A:M "distortion boxes"?
FBX doesn't know anything about A:M constraints.

These same things go for any other "lame" interchange format. What are you guys thinking? That somehow all animation operations can be converted to matrices?

If one of you is an animation programmer, I'd be happy to answer questions, but idle speculation is unproductive.

There is no conversion... It is impossible.

What we've tried in the past is "baking". This is where we take all of our stuff, apply it, then subdivide into polygons. Ain't much of a format exchange though.

Martin (or anyone)

Does A:M have a bvh exporter? If a bvh exporter exists then motion could be exported to fbx as well as there are many similarities in the data. Also, similar conversions have to happen with other programs. I would understand the issues with converting the model data. But the general motion should be able to be converted. I know bvh import exists, so the reversal should be fairly simple. I did email you Martin about looking into this, but got no response to that email. I'm sure you are a busy person and I appreciate your time you give myself and everyone.

Brian

You are right Martin

I had to take care about many other things (other than CG Graphics).
And I do not want to make some people dream about an application that finally could not work.
Furthermore, my main problem was / is to solve an integration pipeline problem (AM must send data to Lightwave, Cinema4D, Max, Maya and FlashMX ... huuugh nothing more !), not to write some amazing posts here or anywhere.

But here is what absoluletely works for now :
1. Conversion from MDL to Polygonal format (with several features).
2. Conversion of choregraphy file (supporting several features).
3. others...

But I don't think this is the right place here to explain all of that, especially at the current project state of developpement.
Time will soon come when I'll report and share theses elements with the AM Community.

Thanks for your interest to this crucial (or vital) point about the AM integration into a professionnal production pipeline.

Respectfully,
Alain

To be more descriptive.

How would the Hash splines be handled by FBX? Conversion is possible. The post says so. I understand the development time is intensive for such a conversion. I HAVE emailed you about any information possible to work on helping with a conversion.

How would "relationships" be handled by FBX? This data would not be needed.

How would "SmartSkin" be handled by FBX? Also not needed. Fan bones, and smart modeling can work around the creasing issues that Smartskin solves. Also, it might be possible to convert smart skin into morphs.

How would FBX parse the A:M expression fields? Possibly not needed.

How would the overloading be done? Not sure what you mean here.

How would the automatic rescaling be done? That could be accomplished via a global scaling percentage.

How does FBX interpolate A:M channels? This should transfer. Not sure without looking at it. Was waiting for the new SDK that is suppose to be posted this week.

How would FBX handle A:M "distortion boxes"? Wouldn't need to transfer.

FBX doesn't know anything about A:M constraints. Also wouldn't need to transfer

FBX is a possibility. And I do not think its fair to call the format lame. Its a flexible medium that can be viewed in quicktime and exchanged between virtually every production software. But as you have said you are not interested. I will no longer pursue it. Thank you for your time.

Brian

For Alain and anyone who is interested in it:
Regarding Smartskin.....Could you not dispense with it (and possibly some of the other things) and then "fix it up" in the "other" application when you get the model and animation info in there? And vice versa. But then my "other" app knowledge isn't great, so that might not be possible.
But half way there is better than none of the way sort of thing.

Its not about telling anyone what to do. Its attitudes like: "You may as well go use something else, because you just don't "get it"."

That make it difficult to convince people to use A:M. I finally have convinced a friend to use A:M for his direct to DVD film. Not sure its a good idea now. I'm hardly whining. I've offered to help. But any offer has been met with hostility. I'm hardly a newb with the software I've used it since 97, and have comrades that have used it since the early days.

Smartskin isn't necessary for export, its something that can be solved via other means. Its useful, but as KenH said, not necessary. It seems a lot of people in the A:M community have a bad attitude whenever anyone suggestions anything and get openly hostile.

Brian

Brian;

What are you trying to do here? Calm down. Take a deep breath. Don't be so insistent.

The first thing you can do in your quest for compatibility is make an animation that does not include the things you say you don't need, then use the export functions that already exist: BVH and poly out. See if it works out for you.

The people here will be glad to answer your questions while you're making your animation. See Zach's "Reusable Motion" topic for a discussion of BVH. (Will wrote a tutorial on it). See the "Game Development" topic on poly export. The Moderators of the other topics would be glad to help in their areas of expertise.

I don't want to stop you. There are compatibility things A:M does and I'd like to see them explored further. You could be that guy!

Sincerely,
Martin Hash

This whole thing reminds me of something in LightWave that is a pain in the butt. Hash exports 3ds to the standard 4 point poly configuration that everyone uses now. That is nice.

For some stupid reason LW only imports 3 point polys in 3ds format. Same for export. 3 point polys are worse than 3 point patches. So when it comes to conversions, I blame Lightwave. It is too much work to go through a model in AM and remove that spline from every patch to make it 4 point. So I will continue to use the 'prop' feature ... and love it.

... now if I could just find a way to get my Hash mdls into LightWave... I guess I would have to make a bunch of 3 point patches? Yikes. Video compositing is my answer!

Jesshmusic I posted this in another thread very recently.

Go Here http://www.geocities.jp/masashi_wolf_watan...o6Am10Intro.htm

it works well for for 1 poly per patch export. 5 points and hooks need cleaned up. Even these could be taken care of almost automatically in some of the newer packages (modo C4DR9 xsi) because they all have sub-division N-gon support.



As for FBX support. There was a thread about it sometime last year where someone was looking into it but stopped because to even look at the SDK would have cost >$1000 . Now it's free, There are some fairly extensive samples.


Here are the features from the sdk overview. :

FBX SDK Features
The FBX SDK lets you access, create, or modify the
following elements of a scene in the .fbx file format:
• Mesh, nurb, and patch
• Texture mapping over a mesh, nurb, or patch
• Material mapping over a mesh, nurb, or patch
• Normals and color of vertex, mapping over a mesh,
nurb, or patch
• Link constraints on the control points of a mesh,
nurb, or patch
• Shape constraints on the control points of a mesh,
nurb, or patch
• Multiple cameras and a camera switcher
• Multiple lights and gobos
• Markers
• Skeleton segments (root, limb, and limb node)
• Multiple takes of animation
• Global camera, light, and time settings
• Bind pose for a list of nodes (bones, mesh, nurbs,
patches)
• Rest pose for a list of nodes (bones, mesh, nurbs,
patches)
In addition, the FBX SDK provides tools to:
• Process animation data
• Triangulate meshes, nurbs, and patches
The FBX SDK reads .fbx files produced by FiLMBOX
version 2.5 and later. It writes .fbx files compatible
with FiLMBOX (version 3.0 and later) and
MotionBuilder (up to version 6.x). The features
supported by the FBX SDK are only a subset of the
information generated by FiLMBOX and
MotionBuilder. Among the unsupported features are
FiLMBOX and MotionBuilder tool settings, animation
layers, timewarps, and constraints.


while there may not be an analog for each of AM's parameters there are quite a few.

As for complex model import into AM. I have been thinking about this for quite a while. I think there may be ways of doing this through edge loop selection.

I'll post more later. I really hope that this can come back to being a productiove discussion.



Thanks

The dissension I observe in this discussion comes from the fact that we are dealing from 2 very different point of views.

User point of view is focussed on very specific needs. For instance Brian believe that porting smartskins is not necessary. Then in the next post, William considers that essential.

As a company who manufactures the software, planing to program an exporter to FBX would mean that all users needs must be taken into consideration. So even if Brian thinks exporting smartskins in not important, if another user thinks it is, then it is.

The bottom line is that, in the end, all the software features should be exported. You start to see the monumental task. Deciding to export only the easy ones will not work. The exporter would be considered incomplete. Doing them all means that the very hard ones would need to be exported too.

So because of the ressources required to do such an exporter and because the Hash mission is not to manufacture a FBX exporter but rather to manufacture a piece of software that one artist can use to tell a story, it is clear that ressource assignment priorities will not go to an FBX exporter.

However, the SDK should contain all that is required to program such an exporter. I suggest if you are really interested in such an exporter, either program it or hire a programmer to do that plugin with the SDK. The advantage you will have is that you only need to satisfy your own requirements. Then you will see by yourself what amount of work and ressources is involved.

That seems like a cop out to me.

There isn't one fbx exporter that is "all inclusive" for any of the programs that have it. Yet somehow it is still a very useful tool. Any multi-dimensional job looks humungous and arduous when taken as a whole. With basic functionality in place smartskin export wouldn't look quite so impossible.

I'm so inspired by all these 'can do' attitudes, I wonder why someone hasn't tried this before

Yeah sorry about that.

I was out walking the dog and had decided to edit my reply, thinking it was too harsh, reactionary, and misdirected.

But since you replied I don't want to change what you are quoting. (I have seen some forum software that reference their quotes and so change when the original post changes)Mine might as well be the example for going too far. However if you would rather me change it I won't object.
hope that doesnt' sound argumentative. I just dont' want tthe comment changed globally then have people wonder why I was warned in undue fashion. Just let me know

So, sorry about that Yves.

Thanks for the link, but that brings up the other problem a good portion of us run into. I am a Mac user, so I have to be even more creative than the PC users of AM.

I think there are solutions to everything. Here is one that not many will like, but I guarantee if you know both software packages you work on everyone can do. Render the model in various views and use those renders at rotoscopes. I can tell you that for me this will be hard because of my different skill sets in each package. In LightWave I can model mechanical objects great (I wear out the bevel function), in AM I can do the organics better (although I am starting to learn to model mechanically). I make some things in one, and some things in the other. I can import the LW stuff as props pretty stress free, although I can't figure out how to maintain my hard edges when I import.

Someday a Mac programming guru will buy Hash and be stoked to make tons of plug-ins.

I almost closed this thread, but that's probably overkill--instead I'll just give a friendly Moderator Nudge and suggest that the folks interested in FBX import/export also start a thread on the SDK forum and pick the programmers' brains there.

It would be interesting if someone put up a poll asking how much people would pay for an FBX plugin. It might encourage/discourage people who would be interested in making one.

Considering the FBX plugins for Lightwave and maya are free, I don't think we need a poll. I did figure out that I can export a 3ds object in Hash, use the FBX converter to convert it to FBX and then import it into Lightwave and that works very well. Even though we have the 3 point polys, I guess I will just have to deal with it.

Jess,

The FBX converter will import obj, which can use quads. Just export obj then use that to goto LW

Thanks for the tip! I shall try that as soon as I am home.

Glad to see that there is talk of supporting FBX. As I have found the format useful in some of my work. The workaround discussed about obj, is a good tip.

-N86

Interestingly enough when you do a search for FBX this thread does not come up. I would pay today for a clean FBX export from A:M.


Edit- One thing I noticed on this thread. Specifically about the SmartSkin Export Argument. Or call it the Limited Export Argument. People are not seeing the others position.

People are not necessarily saying smart skin is not needed, they are saying it's not needed in the exporter.

HERE'S the main question. Once someone has animated in A:M with smartskin, expressions etc. The animation can be BAKED to the model, is that correct? Thus the model LOSES all of it's smartskinning, expressions....right? So after the action is baked you are left with mesh vertices and bone position data is that correct?

In that case the FBX does not have to calculate smartskin, expressions etc after the BAKE.

Also, if I know A:M can only export bones animation, mesh, and textures. I will ONLY animate using bones inside A:M.

So rather than using smartskin, or an expression to bulge a bicep. I would have to figure out how to do it in A:M with a bone.

So again shouldn't the question be can a BAKED animation from A:M be exported as an FBX?

Edit again- a static .3ds to FBX is fine, and already works, I'm just talking about getting an A:M character into a game engine.

Hash won't do it, but for $10K you can probably get a plug-in author to give it a try, especially if you don't care about any of the A:M specific features. Post a "Help Wanted," and see who comes out of the woodwork.

$10K aint too bad. decisions, decisions.

There's more than one way to skin a cat.

Solution found that works, don't need $10k. Without AMXTex the solution would not be possible. But you can go from A:M to FBX just a couple steps, and the cost of another App. Only problem thus far is flipped normals in the final FBX.

$10k is a little obscene for something like this. I'd think the skillful Hash programmers could easily create a FBX exporter/importer in a few weeks. Its just a matter of priority. Which is understandable. Time is money and if its not needed then why do it.