Interest in (new) Exporter for Cinema 4D?

The place for artists, modellers, level designers et al to discuss their approaches for creating content for OGRE.

Would you _purchase_ a C4D .mesh Exporter?

I might pay ~$50 USD, if it included .skeleton file support
14
34%
I'd pay ~$25-$35 USD, for a good .mesh exporter
5
12%
Dang your need for food - plugins must be FREE!
22
54%
 
Total votes: 41

matches81
Greenskin
Posts: 116
Joined: Tue Jun 12, 2007 10:28 am

Post by matches81 »

Really nice work, seems like you're making good progress!
If you're willing to share, I'd be interested how you go about the joints <-> bones thing. Just curious.
User avatar
Spanki
Halfling
Posts: 76
Joined: Fri Jun 06, 2008 5:58 am
Contact:

Post by Spanki »

Keep in mind that the images I posted are after an 'Import', so there's not so much of a conversion - just a choice of creating Joint Objects instead of Bone Deformer Objects...

C4D Deformers:

The way deformers work in C4D is that they have to be the child of some mesh object (or Primitive Object that would produce a mesh) and they operate on (modify, in some way) the vertices of the parent mesh.

'Bone' Deformers:

The older 'Bone' objects in C4D are actually Deformers (each one is a deformer), so they are restricted to operating on the parent mesh - this is why you'd need separate chains of deformers for each submesh - along with separate animation tracks for each bone of each skeleton-worth of Bone defomers. A more or less nightmare of data to deal with and maintain.

'Joint' Objects:

With the newer Joint system, each 'Joint' Object is little more than a Null Object - it's primary purpose is to provide an axis of rotation and some visuals (along with some special IK controls and a few other features).

To complete this type of rigging, is a 'Weight Tag' on the mesh, which maintains a list of Joints and vertex weights for each of those joints along with a (singular) 'Skin' Deformer object as a child of the mesh. The Skin Deformer looks at the Weight tag on the mesh to find the list of joints/weights. This system allows for a single chain of Joints to be shared by multiple mesh objects (and therefore just one set of animation tracks - one for each joint).

Ogre3D Bones:

The only real requirement of an Ogre3D Bone is:

- provide an axis of rotation
- provide a means of weighting vertices of a mesh to the bone
- provide a target for animation rotation/translations

...along with the usual 'Parent' lookup and hierarchical linkage.

So, back to the quesiton at hand, if you had some way of tracking vertex weights (which I think you could use Vertex Map tags for), and some code (a plugin or possibly even an Expresso program) you could actually convert Ogre3D Bones into C4D Null Objects - so the Joint system was just the best choice.

As for the actual import process/implementation, I just designed a framework to store all the necessary info read in from the mesh and skeleton files and then generate the Joints/Skin/Weight tags after I had all the data.

As far as the Export implementation... for the first pass at least, I'll still only be supporting 'Joint' rigged figures. This really simplifies the interface, because the plugin can look for and use the Weight tag on the the (each) mesh to find the Joints/Weights needed.
User avatar
Spanki
Halfling
Posts: 76
Joined: Fri Jun 06, 2008 5:58 am
Contact:

Post by Spanki »

Slightly OT, but related... here's the "Black Knightress" character from DEXSOFT, imported with my new MilkShape 3D Importer in mid combat animation...

Image

...and here's the Object Manager view...

Image

...look familiar? :). I actually wrote the MS Importer before doing the Ogre Importer, so while the file formats are radically different, they produce the same character setup within Cinema4D. Once loaded, my Ogre3D Exporter (or my MilkShape Exporter, for that matter) won't know the difference (hint).
User avatar
Spanki
Halfling
Posts: 76
Joined: Fri Jun 06, 2008 5:58 am
Contact:

Re: Interest in (new) Exporter for Cinema 4D?

Post by Spanki »

Just a quick(?) update...

As it turns out, Exporting a 'Joint'-rigged figure (as opposed to a 'Bone'-rigged figure) is more tricky than I originally thought. It's not that it's 'difficult' to do - it's just a matter of trying to make the user-interface and export options make sense, while simultaneously trying to keep it as flexible as possible and imposing as few restrictions as possible - these goals often end up in conflict (when you also factor in the difficulty level of achieving any particular scheme, with whatever restrictions the plugin SDK has).

Anyway, it's a balancing act... as mentioned earlier, I'm adding a new Tag to allow you to specify how the Timeline gets split into separate Animation (clips). Here's a look at the current implementation of that dialog (subject to change)...

Image

...(this list was auto-created by the Import plugin, after importing Jaiqua). You can either enter values for the Start and End frames, or you can scrub the timeline to the desired frame and click one of the little orange buttons to record the current value. While the interface itself may change, I now have a means of at least getting the data, so I've moved on to the next step...

The next step is determining:

* which elements within the document to export as Ogre 'bones'
* which of those objects each vertex is skinned to and by what weighting
* which of those objects have animation keyframes and...
* how to handle the ones that don't

Bone Determination:

Just to back up / review a little bit - earlier, I talked about the difference between two primary types of rigging in Cinema 4D:

1. Using 'Bone' deformers
2. Using 'Joint' objects (+Skin deformer+Weight Tag)

...with a Bone-rigged figure, finding the bones is easy - they have to be under the (each) mesh... but as noted, that also makes them much less efficient/desirable than a Joint-rigged figure (each mesh in the scene needs it's own skeleton (this might not be 100% true)). Anyway, with a Joint-rigged figure, it's easy enough to look at the Weight Tag to get a list of Joint objects, but that list (typically) only includes the joints actually used by (having weight values for) that particular mesh - it won't necessarily list the entire skeletal hierarchy.

Also, as mentioned earlier, there may also be other non-Joint objects in the scene that should also be written out as an Ogre bone (ie. the rig might include and/or be parented by one or more Null objects that are also keyframed). In short, the plugin needs more info from the user.

My current plan is to add a new type of Object - a Skeleton Root Object - the idea is that that acts like a root/parent Null Object (and is also written out as a bone itself) and whatever you want exported as an Ogre bone gets placed under one of those...

Image

...note the dog-bone icon above on the "jaiqua_SkelRoot". I'm not sure why Jaiqua has so many non-animated, root-level bones before you get to the Spineroot, but you could probably do without some of those - the new Skeleton Root object will be written out as the root bone and can act as a handle to the figure inside Ogre. You may or may not want/need any additional root-level bones.

Ok, so that covers the "which elements within the document to export as Ogre 'bones'" - anything under that Skeleton Root object. The "which of those objects each vertex is skinned to and by what weighting" is covered by the Weight Tags on each mesh. The last two items above (related to determining keyframes) require a little more thought/discussion...

Keyframe Determination:

This issue has to do with 'how' you (the user) rigs and animate your figures. If you're importing some BVH data or some other similar source, then you'll likely have keyframe data for each bone (I may be using bone/joint terms interchangably here and below). But if you're animating the figure by hand, you might have set up an IK system, with constraints and controllers and IK goals, etc. If that's the case, then the bones themselves will probably not have any actual keyframes set (you might be keyframing the controllers, instead). In order for the plugin to account/allow for this, there are 3 options:

1. I could just write out EVERY frame for EVERY bone (terribly inefficient)
2. I could specify that you'd have to create keyframes for the bones - you could use your controllers to move the bones around, but you'd need to (for example) also create keyframes for every bone affected by that controller, as appropriate (if you move a toe controller and that moves the foot/shin/thigh, you'd need to create keyframes on the toe/foot/shin/thigh).
3. Bone Proxies...

...that last item may or may not make it into the first release, but here's the idea... through some interface/dialog you'd be able to define keyframe 'proxie' objects. These would have a more or less 1-to-1 relationship to your controllers. So you might define a 'Left Toe' proxie, which would list the bones that were influenced by that controller (depending on your IK chain setup, that might just be the toe and foot or might go further up the leg). The plugin would then also look for keyframes for the proxie objects and when it found them, create keyframes for all bones within that proxie list.

With this type of setup, the controllers are not written to the file (I've seen some files (not sure which exporter wrote them) that had useless 'controller' and/or 'IK' objects written out as bones), but thier influence/use is still accounted for.

Wrapping Up:

Sorry, I didn't mean to write a novel here :), so I'll try to tie this back into my initial comments and wrap this up...

As I mentioned at the top of this post, trying to provide functionality/flexibility without imposing too many restrictions is a juggling act. As a case in point, my original dialog options (for exporting static meshes) must now be re-evaluated in light of some new layout restrictions imposed by the skeleton/animation Exporting implementation (mostly related to exporting the entire scene vs. the selected object and the Export Children / As Submeshes vs. As separate files type options). Some of that may need to change in order for new/additional options to make sense.

I'm just trying to find the middle ground between:

"Export the entire scene, broken up into separate files, some with animations, some without, some with sekeletons, some without, some with just a skeleton, some with just a mesh, but include any children as submeshes instead of separate files, but not if they also have skeletons and while you're at it, you'll have to figure out all of that using whatever random scene structure I came up with"

and

"Export the selected mesh."

:)

Happy Holidays!

Keith
User avatar
Praetor
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 3335
Joined: Tue Jun 21, 2005 8:26 pm
Location: Rochester, New York, US
x 3
Contact:

Re: Interest in (new) Exporter for Cinema 4D?

Post by Praetor »

This is excellent. I can't believe you're tackling joint-rigs. That was a major stumbling block on one project I was consulting for last year. Looking over your progress in this in this topic, I can promise you I will be buying a few of your licenses for this. Really excellent work.
Game Development, Engine Development, Porting
http://www.darkwindmedia.com
User avatar
Spanki
Halfling
Posts: 76
Joined: Fri Jun 06, 2008 5:58 am
Contact:

Re: Interest in (new) Exporter for Cinema 4D?

Post by Spanki »

Praetor wrote:This is excellent. I can't believe you're tackling joint-rigs. That was a major stumbling block on one project I was consulting for last year. Looking over your progress in this in this topic, I can promise you I will be buying a few of your licenses for this. Really excellent work.
Thanks - I appreciate the encouragement. I've had some false-starts along the way, but it's slowly coming together now :).
User avatar
Spanki
Halfling
Posts: 76
Joined: Fri Jun 06, 2008 5:58 am
Contact:

Re: Interest in (new) Exporter for Cinema 4D?

Post by Spanki »

Status update (just to clarify - the plugin has not yet been released - this is just pre-release information)...

Whew... after a lot of reworking and several false-starts, I finally got all the vertexboneassignment (bone assignment and weighting of mesh vertices) working a few days ago and tonight I finally have the skeletal animation export working (yay!).

I still need to add some code to (generate as needed and) export SubMesh names, and some general cleanup, but this brings me to my first-release level milestone. There's still plenty of room for future updates and additional features, but the first release provides a lot of functionality and will let me judge interest before spending a lot of additional time on it (ie. sales will have a direct impact on any future updates).

The feature-set planned for first release includes:

* Can Export .mesh.xml files...
- exports .mesh.xml file, converts to binary .mesh using external converter.
- correctly re-orients the mesh/axis for use in Ogre3D engine.
- exports submeshes
- properly sets the use32bitindexes flag.
- optionally exports as sharedgeometry
- properly sets up the usesharedvertices flag.
- properly exports UV coordinates.
- properly exports Normals (based on Phong Tag settings including phong-edge-breaks)
- properly splits the mesh as needed at material boundries (based on Texture Tag 'Selection' restrictions).
- can scale the mesh up or down on export.
- if a .skeleton file is also being exported for a rigged figure, then vertex bone assignment are also set up (processed down to the 4 most influential bones/joints weighting each vertex and normalized to 1.0 total weight for those 4) - note that this is based on Weight Tag values, which is used for Joint-rigged figures.
- allows the creation of unlimited number of Export option 'Presets'.
- etc.

* Can Export .skeleton.xml files...
- exports .skeleton.xml file, converts to binary .skeleton using external converter.
- properly re-orients the bones for use in Ogre
- scales the skeleton/bones up or down using same value as used for mesh.
- root bone (top of bone hierachy) is specified (drag-n-dropped) by user in new Figure Export Tag
- Exports skeletal animations - the C4D Timeline is split into separate animation clips based on user-defined settings in the new Animation Clip Tag (the tag to use for Export is also drag-n-dropped as a link in the Figure Export Tag, so you could have multiple tags set up and pick which one to use for a given export).
- always exports First and Last animation frames for each joint/bone of each animation (just once, not twice, like some exporters - or is the converter doing that?), but otherwise (currently) just exports keyframes where the joints/bones actually have keyframes set.

* Can Import .skeleton.xml files...
- re-orients the rigging for use in C4D
- creates C4D "Joint" rig based on the Ogre bone heirarchy, including a "Skin" deformer and a "Weight" tag on each mesh (that properly lists only the Joints that affect that mesh, along with the per-vertex weighting information) - C4D Joints are more flexible and easier to work with than the older C4D "Bone" deformers.
- optionally Imports and sets up all skeletal animations (C4D R10 doesn't support animation 'clips' or multiple timelines, so the animations are simply concatenated, end-to-end).
- a new Animation Clip Tag is auto-created and filled in with the animation clip settings for you
- a new Figure Export Tag is auto-created and filled in with the appropriate settings for exporting.

* Can Import .mesh.xml files...
- (currently) only supports non-shared-geometry files.
- (currently) creates a separate C4D poly mesh object for each ogre SubMesh (using the SubMesh names, if they exist)
- correctly re-orients the mesh(es)
- optionally scaling them up or down (the same scaling is applied to the skeleton)
- optionally importing UV coordinates (in case you had some reason not to)
- optionally importing Normals
- optionally swapping the Y & Z axis (experimental - for those goofy 3DS Max oriented meshes)
- imports the vertex bone assignments (and weights) and 'skins' the mesh to the rig created above.
- optionally creates named (but blank) Materials for you, as well as creating Texture Tags on the resulting meshes, that use those materials (I'm not actually (yet?) filling in color/bitmap file info in the Materials, but at least they are created, named and applied to the appropriate meshes for you)
- individual options to create R10 or later "Layers" for each type of element created (Mesh, UVW Tags, Normal Tags, Joints, Skin Deformers, Weight Tags, Texture Tags, Polygon Selection Tags, Phong Tags, etc).

etc.

...so, there are a few basic features missing (like mesh 'morph animation' export, material file creation, etc.) and several features that I already have some plans for improvement in a potential future release (like the bone-proxie system I spoke of above), but it should be at a decent 'functional' level for the first release.

BTW, remember that 'Root Bone' object thing I spoke of in a previous post? In the end, I replaced that with the new "Figure Export Tag" (tag instead of an object)...

Image

...note that the tag must be placed on the root-level null object to be exported. In the tag's properties, you drag a link of the object that specifies the "root bone" of the skeleton. You have the option of exporting that (as an Ogre bone), or not, but the plugin primarily uses it to find the hierachy of bone/joint objects to export... it will export any object underneath that one in the Object Manager (though you also have the option of exporting any objects 'hidden' in the editor or not, so you could hide anything in that branch that you don't want exported as a bone (EDIT: I'm not sure I've actually hooked up that feature yet :) )).

In the image above, I show two different figures that were Imported with my plugin... note that the "skeleton" figure on the left has an odd bone setup... the "skeleton_SkelRoot" null object was created by my plugin, but otherwise, there were several branches, all at the root level. If you compare that to the "ninja" figure on the right, it already had a "Joint1" bone at the root (it was the only bone in the file without a parent). So, also note that for the skeleton figure (an actual skeleton mesh as well - sorry for the naming confusion), the "skeleton_SelRoot" object is set up as the "Skeleton Root Bone", but for the ninja, the first actual joint "Joint1" is set as the "Skeleton Root Bone".

Basically, when importing, my plugin always creates that "xxx_SkelRoot" null object, but if the figure already has a single root-level bone, it sets up the Figure Export Tag using that instead (if you really want to add another root-level bone to the top of the tree when exporting, you can change the link after importing, but you should also change it's name, to avoid confusion if it gets re-imported again).

The other link set in the Figure Export Tag is to one of the new Animation Clip Tags (in this image, it's also on the root-level null object, but it could be anywhere).

So, the current "restrictions" imposed by the plugin (for exoprting a rigged figure) are:

1. There must be a figure root-level object. It's possible that this could be the mesh object itself, but that may cause unforeseen issues, so I'd like to keep it as a separate object, for now, at least. The mesh object(s) should be linked under that root-level object (I'm using a Null object, but it could be something else). The mesh/skeleton filenames are also derived from the name of this root-level object.

2. There must be a Figure Export Tag on that root-level object and the links in it's properties should be filled in appropriately.

3. The joints (and/or anything you want written out as an Ogre Bone) must also all be linked under some parent object. That heirarchy can be anywhere in the scene (since the link to the parent goes in the Figure Export Tag), but I've just been putting it under the figure's root-level object. If you had multiple figures in the scene that shared the same skeletal structure, it might make more sense to just have it at the root level.

4. Currently, only "Joint" rigged figures are supported... more specifically, the plugin can export almost any object as an Ogre Bone (as part of the skeletal hierarchy, so it can still affect other bones in the skeleton), but it gets the vertex weighting information from the Weight Tag used by the Joint+Skin Deformer system - if there's some way of weighting other objects in the Weight Tag, then it can handle that as well.

5. The plugin also currently requires an Animation Clip Tag, if you want skeletal animation exported. You can just create a single clip of all frames, but there has to be at least one clip. The Animation Clip Tag to be used for export must be linked in the Figure Export Tag.

6. Not specific to rigged figures, but... if you use more than one material on a polygonal mesh object, then the plugin needs to split that Mesh up into SubMeshes. It therefore also needs to 'generate' names for those SubMeshes. I still actually need to go back and fix the code for that, but the point is - if you're going to need SubMesh names exported and care how they get named, then you're better off splitting the mesh yourself ahead of time so you can name them how you want to (SubMesh names come from the polygonal mesh object names - you can see a preview of what you might get if you don't name them yourself from my Import screen shots above, where there were no SubMesh names in the file).

Anyway... sorry for another novel - I just go psyched about getting the vertex weighting and skeletal animation export working finally :). I hope to tie up some loose ends and have the first release available within the next week or so.

Cheers,

Keith
matches81
Greenskin
Posts: 116
Joined: Tue Jun 12, 2007 10:28 am

Re: Interest in (new) Exporter for Cinema 4D?

Post by matches81 »

I don't know exactly how you do it currently, but for submesh naming I'd go with <original mesh name>_<selection Tag name>_<incrementing number for uniqueness>. That way, even after an import the artist could identify the parts more easily, I guess.

"(currently) creates a separate C4D poly mesh object for each ogre SubMesh (using the SubMesh names, if they exist)": You're probably planning on doing this anyway, but I think creating polygon selection tags for each submesh should be quite possible. That way, export -> import -> export should at least give similar results for the second export, if not identical, which is always a nice feature.
User avatar
Spanki
Halfling
Posts: 76
Joined: Fri Jun 06, 2008 5:58 am
Contact:

Re: Interest in (new) Exporter for Cinema 4D?

Post by Spanki »

matches81 wrote:I don't know exactly how you do it currently, but for submesh naming I'd go with <original mesh name>_<selection Tag name>_<incrementing number for uniqueness>. That way, even after an import the artist could identify the parts more easily, I guess.

"(currently) creates a separate C4D poly mesh object for each ogre SubMesh (using the SubMesh names, if they exist)": You're probably planning on doing this anyway, but I think creating polygon selection tags for each submesh should be quite possible. That way, export -> import -> export should at least give similar results for the second export, if not identical, which is always a nice feature.
Yeah, that's basically the plan, but more specifically:

<originating mesh name>.<material name>.<submesh number>

...the material name is effectively the selection tag name, but a more reliably unique means of identifying it (I can't count on the user giving the selection tags unique names). As it turns out, the <submesh number> part of it is fairly useless, because mesh name + material name should already make a unique identifier and there would never be more than one submesh of the same originating mesh, using the same material. Of course I am kinda counting on the user not using the same name for more than one polyonal mesh object being exported, but/so I may add some unique name generation code and just run everything through that.

On the Import side of things, the plugin currently creates separate polygonal mesh objects for each submesh and each of those has a selection tag on it (with all polys of that mesh selected), named after the material used on that submesh. A future option will allow you to create a single mesh object (all submeshes glommed together into a single C4D poly mesh object) and in that case, it would have multiple selection tags - one for each material/submesh.

BTW, on a separate topic - and something I just verified today - the Animation Clip Tag will let you specify the End Frame being a lower value than the Start Frame... in which case, a forward-playing animation will be exported from a reverse-sequenced C4D animation. For example, the "Ninja" figure has a "BackFlip" animation... in the particular test case, that clip ran from frame 88 -> 118. I was able to add a new clip set to 118 -> 88 (play that sequence backwards) and generate a "FrontFlip" animation in the exported file - pretty neat :).
matches81
Greenskin
Posts: 116
Joined: Tue Jun 12, 2007 10:28 am

Re: Interest in (new) Exporter for Cinema 4D?

Post by matches81 »

For the unique naming thing in Ogre I implemented a NameManager class in my exporter plugin, which basically took care of creating a unique version of a given name and "group" (mesh, material, all the other Ogre-related things that have to have unique names). Pretty simple to implement and worked really well for me. To make names unique I simply appended a number to the string and incremented that number for the name/group combination.
User avatar
Spanki
Halfling
Posts: 76
Joined: Fri Jun 06, 2008 5:58 am
Contact:

Re: Interest in (new) Exporter for Cinema 4D?

Post by Spanki »

Status update:

Sorry for the delay, but some holiday affairs took some time :).

After tidying up a few loose ends (serialized submesh names are now being exported, along with a few other enhancements), fixing a last-minute bug or two, and enabling the License/DEMO key code, the plugin is basically ready for a v1.0 release (yay).

The only things left to do now is get a start on some documentation (boo - I might just do a quick-reference for now), do the PC 32bit compile (PC 64bit is already working) and Mac 32bit Universlal Binary compile and set up the product web page, support forum and finally download link. It will be published as with a "Free Trial Period" demo mode (probably 30-days) and will be activatable with a purchased license. Final pricing is not yet determined, but I'll likely also have a special/discount/introductory pricing for early adopters.

I hope to have it available later this week some time, so if you're interested, keep an eye on this thread.

Cheers,

Keith
User avatar
Spanki
Halfling
Posts: 76
Joined: Fri Jun 06, 2008 5:58 am
Contact:

Re: Interest in (new) Exporter for Cinema 4D?

Post by Spanki »

Status update:

I had hoped to have released the plug-in by now, but I've been working on the User Manual for the past several days (something I'm not crazy about doing and am not particularly skilled at in the first place). I think I'm finally nearing completion on that now (37 page and counting, .pdf file ), so once I finish that, I can get the web page set up and "ship-it!" :D .

...maybe another day or three... thanks for your patience.
User avatar
Spanki
Halfling
Posts: 76
Joined: Fri Jun 06, 2008 5:58 am
Contact:

Re: Interest in (new) Exporter for Cinema 4D?

Post by Spanki »

For anyone looking to kill some time, here is a rough draft of the manual:

IOgre_UserManual.pdf

(anyone know how to keep OpenOffice Writer from compressing the heck out of the imbedded .jpgs?)
User avatar
Spanki
Halfling
Posts: 76
Joined: Fri Jun 06, 2008 5:58 am
Contact:

Re: Interest in (new) Exporter for Cinema 4D?

Post by Spanki »

The plugin is now available - see the announcement in the Showcase forum.

Cheers,

Keith
leeyn

Re: Interest in (new) Exporter for Cinema 4D?

Post by leeyn »

it uses kind of an odd skeletal structure - notice that there is no bone between the knee and the ankle....
User avatar
Spanki
Halfling
Posts: 76
Joined: Fri Jun 06, 2008 5:58 am
Contact:

Re: Interest in (new) Exporter for Cinema 4D?

Post by Spanki »

leeyn wrote:it uses kind of an odd skeletal structure - notice that there is no bone between the knee and the ankle....

Which figure are you looking at? You can design any type of skeletal structure you want to, with however many bones you want.
Post Reply