A Unity ID allows you to buy and/or subscribe to Unity products and services, shop in the Asset Store and participate
in the Unity community.
Calling all New Unity users! Join the Halloween Mods Showcase Challenge until October 31.
Discussion in 'External Tools' started by helmers, Sep 3, 2010.
Make sure you keyframe a Tpose on the first frame. This is usually the issue there.
Not "wrong". Just not a smooth pipeline like previous with R10.x and U2.6. Export to FBX still works fine. The other method was just way quicker, allowed edits to show up in Unity immediately upon save of the C4D file. I did have an issue with the +Z axis pointing in the -Z consistently..It didn't mess with my animations, but coupling an Unity Editor IK system to a rig where all the angles are reversed was too tricky for me to script..
So this will be fixed by Unity till end of the year? (Plugin)
No promisses (it mostly depends on when is the next release), but that would be a reasonable expectation.
Next release of what? Unity? I think this is a bug of U3, so this would be no new release, it would be a bugfix (to get working with R12).
I believe he meant a point update like 3.1..hopefully..but I hate to get addicted to hopium being a realist.
heh..he said pro-misses..heh
So it is true that I would get a much better workflow with Maya instead C4D in future?
No. Cinema 4D is an excellent tool and is the best for single person development. Maya as well has issues. In fact a perusal of the boards shows alot more folks with Max and Maya issues than C4D. The only issue is the straight pipeline from C4D->Unity3. FBX export works just fine.. Perhaps Paulius can get his mitts on Melange (c4d toolkit for their file format) and together with the FBX SDK write a proper importer for U3 and R12. Most issues I have seen with C4D import are caused from not keyframing on the first frame a skinned meshes rig, or not assigning a texture in the Color channel and no material comes through (luminance or diffusion etc don't come across IME). Once in Unity you will have to select the meshes texture and apply it to the material created on import. Other than that it is a sweet combo. As well character rigging is more advanced in C4D in that many things needing Mel scripting in Maya have tags in C4D. There are alot of coverts showing up on their CGTalk forum who say this..so Maya people..don't throw things at me
That is correct.
There is no such thing as bugfix - we can't release just a single bugfix (I wish we could). Once any bugfix is done the software has to go through full release procedure (full testing, packaging and so on), so the releasing a bugfix is much more work than making it, that's why we're bundling a bunch of them into "releases" (be it minor or major).
Thank you both for your information and help
I too think the FBX exporter (at least the FBX 6 version) is not so bad at all.
Of course you have to keep some rules in mind and only a fraction of the possiblities in Cinema4D are actually transported to Unity.
I don't know about the other packages, but I bet there is no real fire-and-forget solution anywhere.
Every tool - which is not specifically designed for game content - has different data structures and ways to handle stuff than Unity does. For example C4D stores UVs per polygon, not per vertex. Or joints have to use certain parameters to look similar in Unity. And how would one map the different material channels in C4D into a corresponding shader?
What worked for me (FBX 6 Export with C4D 10.1):
Textures and Material Color / Joints / Animation Keys / Polygon Selections(when a texture is applied only to a part of a mesh, important for map building) / one UV set
What works with workaround:
Normals - There is a plugin (called Riptide or so) to create a Normals Tag for a mesh. The FBX 6 exporter will then export those normals to Unity. However the newer FBX exporter fails to do so (Maxon confirmed thats a bug) :-(
Second UV set - With Beast integration it is not anymore a such important feature. Anyway, there is a workaround posted somewhere in this forum. Furthermore FBX 2010 will export 2 UV sets, however it doesn't export Normals nor Polygon Selections.
So with FBX 6.0 the second UV set is the only thing buggering me ( the normals workaround is simple and efficient ), which thanks to Beast is not a big problem either.
SOOO, there is still one problem remaining where you Unity guys could help out :
Could you please elaborate on how your plugin works exactly and maybe make it open source, so one could build his own pipeline?
I want to achieve that I could drop a C4D file in Unity which is then exported with the FBX 6.0 exporter. Furthermore I would want it to work with Cinema4D R10, because I dont want to spend another 400 Euro for an upgrade. I am not asking about a ready-to-use plugin, but the technical details so I could build a C4D plugin by myself and maybe add some preprocessing(I have already made some C4D plugins)...
EDIT: The plugin is called AddNormals and can be found here: http://skinprops.com/download.php?list.12
One more question: Which options I've to choose, if I export it manually as a FBX-file (in the export-option-window) for best results?
Mark options: Export Animation, Export Textures and Materials, Save Normals
Unmark option: Embed Textures
I have created a wish for making the asset pipeline open source, would be fine if some of you could vote there:
@BigBug: Would it be bad for Unity to export the textures into the FBX?
Has anyone tried character imports to Unity using the C4D Collada exporter? I avoid it for static scenes because it renames all objects with an ID making it impossible to work with for scenes with large numbers of objects, however if a low object character animation it might be worth a try.
I'm also on the Maxon beta and have been trying to get animated characters out of Cinema via FBX recently too.
Unfortunately, I can not get consistent results. I've tried 10.5,11,11.5 and 12 and I get the same bug in all of them.
Basically, some files will work fine, whereas others (using the exact same rig) export with weird pops in the rotations for a frame or two scattered randomly through the file. I've reported it and it's a confirmed bug with C4Ds' FBX importer/exporter.
So far the only workaround I've found is to load the damaged file into the demo of Maya 2011 and fix the bad keyframes in that and then resave as FBX for Unity. I've not gotten time yet to check the results in Unity yet, but it seems that it should work. Funny thing is that if I bring the fixed FBX file back into Cinema the bad frames appear again (in the same place) so there's clearly something up with the way Cinema reads/writes FBX when it comes to animation.
..so if someone can come up with a way of importing .c4d files directly to Unity and skipping the FBX stage it may be the best way forward. Wish I could say that I'm hopeful that Maxon will fix FBX soon but to be honest I afraid I'm not optimistic.
- BTW - here's a post I found on the C4D Cafe after some searching, it shows that people have been having problems with this for a while (the post is almost a year old) :
@Horganowski: How often will this be? And in which cases? Only for characters?
Has anybody filed bug reports with Maxon via their website regarding these issues? I haven't upgraded myself yet, but if they have no reports they will not investigate/fix these problems. Make sure to stay away from issues involving UT's plugin though.
Hi Brian. FBX manual export works fine with R12. You just have to set a Tpose or keyframe some kind of pose on frame 0. Only keyframe the rig and not the character mesh. Do not have a copy of the rig anywhere else in your Assets folder as it seems it will blow up the original. When you have imported the rig you will have to go through the Animation hierarchy, right click the Rotation Curves and switch all the joints to Quaternion Interpolation from its default of Euler Angles to get rid of errant flips. All characters should be exported at 0,0,0. It avoids Instantiation issues down the dev road.
That being said the pipeline between C4D and Unity3 is broken. It opens an instance of C4D R12, bounces it in the dock for a good twenty seconds plus and then the console tells me it was unable to import the C4D file and to export it manually and as well leaves an Icon for each in the Dock which can only be gotten rid of with a Force Quit. Another issue I have that screws with some of my autorigging scripting is that the joints come in with the -Z axis pointing to the child joint instead of the Z+ axis. Anybody have an answer on why this occurs or better yet how to beat it during export/import. It makes it difficult to write an IK system with all the joints 180 degrees out of alignment..Especially as 180 is one of those magic gimbal lockage type of angles in combo with other axis manipulation.
So..it isn't exactly Maxons export that is effed and it isn't the Unity import of FBX that is hosed..it is the bridge between the C4D->FBX->Unity3 that is hosed. I used to be able to save a C4D file (R10.5 and Unity 2.6) direct to my assets folder and within seconds it would be available to use with no ugly icons spewed all across the dock (one is great..a dozen is ugly). I long for those days again
Have you noticed this: http://forum.unity3d.com/threads/64134-Cinema-4D-R12-plugin-patch-(early-beta-version)
Sorry to resurrect this, more for Fluffy really, is the phong breaks not exporting with FBX still getting fixed in C4D?
Hi Anadin, the bug has been reported and is being looked at by the devs.
Unfortunately, it seems there is no more support for our phong tag (or something equivalent) in the new FBX SDK, so I'm not sure what they can do or if they can find a workaround.
I'll keep bumping the issue from time to time on my side, just to make sure it's still being followed.
wow, that's a shame, we ,might have to go back to collada - ho hum. Thanks for the update!
Hi guys, while not a fix coming from Maxon, Cactus Dan has finally released his FBX plugin, which actually works very well with unity.
It works exclusively with his rigging tools for now, but these are so good that any self-respecting animator/rigger should already have them, as they are a reference for anyone working with C4D.
Anyway, here it is: http://forums.cgsociety.org/showthread.php?f=47&t=968410
Thanks for the Heads Up!
A real CD boost for the C4D -> U3D pipeline there.
Please report in this thread any issues you find with Cactus Dan's plugin, as I'm also beta testing for him, I'll pass that along.
Anybody who owns Dan's tools knows how fast he updates them, so make sure you bring any problem to light and he'll try to solve it as fast as possible.
If you have specific scenes or objects that are problematic, please send those to Dan or myself at sf(at)fluffy4d.com.
Please retract that statement - I blindly purchased Dan's plug-in after directly asking in email and at the CGTalk forum if it would "seamlessly export animated textured models into Unity and was told "YES IT SHOULD..."
I get the plugin installed and quickly map a texture to a sphere (a simple planet), export out the FBX, back in Unity, I got my Sphere mesh, but NO TEXTURES, didn't even bother to try any animations yet...
I should have picked up on the "should" cause apparently it wasn't tested.
No refund either. :-|
I'm hoping he can get it to work cause it will enable me to finally get some use out of my C4D package and his character tools.
I've raised my dissatisfaction before with how Unity doesn't seem to work with all the popular 3D apps (Softimage, Lightwave, C4D and now even Modo and 3.3 is supposed to work with Modo!)
I wouldn't mind having to rework a model after import once in a while, but not every time - double / triple rework is not what I'm looking to do!
Writing games by yourself is hard enough as it is without having to fight file format issues and getting your models in every step of the way...
You'll get your fix quickly. Dan has already pushed a fix to support phong breaks in Unity, just a few days after releasing the plugin.
He'll sort the texture problem out, as it was working in previous versions (check Brian's video on the CGTalk forum, his model has textures applied).
I talked to Dan, and apparently you didn't even bother to post the work around he gave you until he finds a definite fix. So here it is, for anyone having the same issue: http://www.cactus3d.com/UnityPreloadTextures.mov
U3D already has C4D import/export plugins, in case you haven't noticed!
Unwrap 3D import/export plugins for Cinema 4D 10/10.5/11/11.5/12 (32/64 bit):
"Lights, geometry, materials, textures, UV coordinates, multiple UVsets,
vertex weights, bones and skeletal-joint animation can be imported and exported."
Best of all, it's free to use if you happen to be a U3D user.
Unwrap 3D, indeed!
It is solid, and works like a charm as a go-between when you are dealing with otherwise incompatible fileformats in the pipeline. I am using the plugin you mention, and it... simply works.
Where animation is concerned I have very little experience with Unwrap 3D. My impression is that CD has more features and functionality in this regard, but please correct me if I am mistaken!
There will be a fix for the Unity texture map issue soon. I've already coded it and will be compiling all versions and sending them off to the beta testers today.
The fix is that I've added an option to turn off embedded textures, which will then physically copy the texture map files to a .fbm folder in the Assets folder of the Unity project as the .fbx file is saved there:
This seems to be a better solution than relying on embedded textures to be properly saved and extracted in the .fbx file.
I didn't post the work around because when I discovered this thread here, I was at work in the afternoon.
I didn't see Dan's post back to me UNTIL last night, after posting on CGTalk, where I mentioned I had just saw a new email from him and went on to read it.
I'm not trying to disparage Dan or his plug-in, I'd like to see this working for myself, as well as him and everyone else here who is trying to use C4D with Unity...
By following Dan's suggestion and creating a "Planet01.fbm" folder and placing my jpg color and bump images, YES, the sphere came in with the >color texture only< which leads to a question I was going to post today.
How should I specify the bump in C4D?
Unity prefers normal maps and will convert a gray scale image to a normal map for you.
In C4D I can specify a bump channel (which I was doing in my case) OR I can externally convert my gray to a normal and setup C4D's normal channel for the object (which I didn't get the chance to try yet) which is a bit inconvenient until I pin down a good tool to convert a gray to a normal.
I was going to email Dan, but I'll ask here as well - how should the bumps be setup for his plug-in to carry them across correctly?
The new update is now available, here is Dan's announcement:
Let me know if you have any more problems.
I'll have to chime in here too. Took c4dr12 for a spin, from r10. No phong data to unity. Unity brings up errors every time I save a model from c4d. Simply won't import updates I do in c4d and have to manually save as FBX.
Are we really going to have to rely on 3rd party plugins to fix something that wasn't broken? r10 + unity 2 was a dream come true, now it's busted. $1000 for your troubles please.
Also isometric rendering in c4d r12 is still busted. I filled many complains to maxon about this (in the end extremely detailed with diagrams), a known issue for 3 releases?!. They don't have any interest in the real time game dev community and I'm sticking with r10 + unity until fixed. I think the time we waited for DAE implementation was evidence enough of this. (which actually turned out to be dodgy at best)
I find it incredible that people are not more vocal about this. Dropping a few thousand dollars for your new versions of unity + c4d for your development pipeline update that breaks the pipeline that worked so well a few revisions ago, it's simply not on.
Will recommend my company invest in Maya next as it's more focused to game dev, from all accounts unity3 and maya are good in bed. As much as that pains me, but how are we expected to keep c4d + unity pipeline? As most of you know our options on the mac are somewhat limited!
I guess the reason people are not more vocal about this is simply that very few people use C4D for game development right now. I'd agree that a lot of this has to fall on Maxon as they simply are not proactive when it comes to working with game Devs from what I've seen. It really baffles me but I get the impression they are just not bothered with the potential market that games would provide.
I worked on a project recently where we had to drop C4D and switch to Maya as we couldn't wait for Maxon to fix things.
Having said that the CDFBX plugin is now a very viable (and very reasonably priced) solution. I've been working on a review of it for the C4DCafe which should be online in the next day or two. In that you'll see a video where I demonstrate how it works just great with getting animation data out of Cinema into Unity with materials intact. It also supports phong breaks properly too.
I wasn't aware of the isometric rendering bug as it's not something I've tried to do here, in a simple test it seems to work ok though, what is buggy with it?
I hear your frustration
You are actually served best with Maya. After all, they are the ones responsible for the FBX format. Maxon is slow to respond to the ever growing game market and they are a small company so your best bet is to go/switch to Maya in the long run. I have been a long time C4D user myself but have grown tired and weary of their attitude towards the game market/artists/developers.
Why doesn't Unity either support SMD, or develop a relationship with FragMOTION, so that we can have a decent rigging suite that doesn't involve having to buy software costing $1000 or more? Rigging / animation is its own specific job; I'd rather use an application that was built
for it than a giant all-in-one suite, frankly.
Not understanding at all why Unity picked out FBX in the first place, when, for games at least, there are so many good formats that have wider support and FBX is such massive overkill for the typical use case.
Moreover, for all of the Indies without much cash, we're stuck with Blender's workflow to FBX, which sucks.
If the big boys aren't giving Unity respect, then go the small guys who are 100% about game assets- Milkshape and FragMOTION. I really think that would be better for everybody, and certainly for those of us with tight budgets.
Because FBX is the only standardized, cross application, cross platform format.
There is no alternative to it, the only thing close to it is collada and collada unhappily has the problem of ubiquity on what feature you use to achieve a mesh which makes it very application dependent on if it works in the end.
There is no replacement for that, no matter how you turn it, as obj has major limits in the texturing and animation end and X and 3DS are totally useless by any standard that exceeds DirectX5 (3DS) or DirectX 7 (X - as its features are not even enough to serve as DX9 targeted format with lacks in multitexturing and alike)
the only alternative would be an own format and offering exporters, but then it would for granted end on 3ds max, maya and blender crap and thats just so much worse than now. now you at least only need to export to a widely supported standard with FBX
Why not SMD or even MD5? We don't need (nor does Unity support) all of the features of FBX (although vertex color support someday might be nice).
As for FBX being a "widely supported standard"... try finding free or cheap tools that can read / write it. Basically, FBX is mainly yet-another economic barrier to entry for Unity users, just not one that is probably as obvious to the developers.
It is widely supported by many 3d applications for many years no matter how you want to look at it. FBX is pretty reliable as exchange format but as with every format, it does has flaws. On top of that you have to remember that companies have to update their 3D Packages when Autodesk releases a fix/update and some companies don't seem to like the fact. Lastly, there are quite a few low priced apps out there that will open/read FBX files so I don't quite understand your point there.
You won't change UT's mind about the format so why not simply accept the fact that you will have to use FBX or otherwise be left out. Unity can't please everybody and has to draw a line somewhere. FBX was a wise decision. Sure it's not the perfect file format but it does a good job. Companies like Maxon are slow to adapt to new versions of FBX as they only have 1 (maybe 2) update cycles per year and limited resources. Not sure how this is handled in Blender or other 3D apps.
There are many that support it, given they have any interest in being used by professionals. Only tools targeted at niche users don't support it.
Why not SMD: look into what the format supports and the answer will answer itself. Aside of that, using a format supported by 2 tools is useless.
Why not MD5: Cause using a format thats not supported by any tool is a bullshit idea?
You can turn and bend it no matter how you want, but if you look how many tools support FBX or Collada (collada to fbx is trivial, obj to fbx is possible too and obj is supported by nearly everything), you will realize that there are a handfull that will not work.
On the other hand, if you look for any format you so far mentioned, you can be happy if you even find a handfull tools that support it at all.
Also I fail to see the prob.
You mention fragmotion but at the same time, as user of free and cheap windows tools, its clear that you either own Ultimate Unwrap 3D as final step in your pipelin as nobody using low cost tools would even try to go without it, its a crucial and undebatable corner piece in the art pipeline on low cost windows, anyone finding excuses for not owning it really deserves all problems he has as only a noob would omit the by far best format conversion tool for what ever lame excuse
I really think that this is a self-limiting decision. FBX isn't supported by Milkshape, for example. It isn't supported by FragMOTION (which is, if you've never used it, one of the best pure rigging / animation suites there is, on the PC).
SMD, on the other hand, is supported by both of them, by Blender, and by a number of other third-party tools. It's more effectively universal than FBX is, and there are a lot more art assets in that format and more teaching resources for newbies than for FBX. And it's just as powerful, in all of the ways that really matter, other than vertex color support.
IDK, I guess this looks like a non-problem if you already have the expensive tools. Moreover, since the FBX format isn't set in stone, it's a moving target and may at any moment make your application irrelevant. This seems like a most unwise position for Unity to put end-users in; if anything should be stable and easy in terms of entry costs and problems, it's the art workflow. OGRE is by comparison easier to deal with, even if in many respects it's inferior to Unity.
[EDIT]I *did* forget to mention Ultimate Unwrap 3D. Sorry, you are right about it being a support application that's useful, although IIRC it didn't handle animations very well, the last time I tested it. That's one of the crucial problems, really; it's no good to be merely able to import FBX as static art, then it's no better than OBJ. Animation support is the key factor here.[/EDIT]
You make it sound like FBX is some shifting sand format that gets completely rewritten every release and will ruin software companies that support it each time it changes.
The bottom line is Autodesk rules the market and FBX is owned by Autodesk. Supporting FBX means you support some 80% of the actual market. The industry market, people who invest money to make money. Just because unity has a free version does not mean it's a tool for anyone with a good idea. It still requires time effort and investment to make something decent. If you don't have the money but have the will Unity supports other formats as well even native formats like .blend.
Besides I remember a time when proprietary formats that only supported a single package ruled the game art industry so your complaints about easy art pipelines is utterly laughable. Unity couldn't have made it easier.
Considering that in this very thread, we can read about people having problems precisely because of this issue, well, I guess people can figure that out ;-)
So, we're supposed to be enthusiastic that the would-be monopolists of this arena have Unity's sole attention? What happened to the concept of competition being good at keeping everybody honest and keeping prices down?
That's a bad joke. There's exactly one format Unity supports that has animation support, and that's FBX.
This is only half true. Again, OGRE's support for multiple file formats is better than Unity's is. I'm not arguing that OGRE's a better engine; it's not. But they got that part right.
I don't know why people are so hostile about SMD; it's a perfectly good format for the vast majority of real-world use cases, it's supported by all of the big boys' toys as well as the stuff for the little guy.
hehe I recall a time, called now, where most engines (real ones, the ones that are used in games played by million of people) have proprietary formats and a proprietary pipeline which supports max and maya and on a very good day blender (exception)
And ogre supports exactly one format, thats its own.
anything else gets converted, better or worse. Last time I tried it you wanted to use a tool that could export to it or UU3D actually just for your nerves sake.
SMD: for being a good format supported by many I don't recall that many tools supporting it actually. I talk here about real support from the tools maker or the format maintaining company, not a home dev and alike with a third party export tool that might or might not work. Its well possible its supported by what you use, but that does not mean its supported broadly, even less when linux and mac are taken into consideration too.
For a support to work out as widely supported it has to be supported natively by Max, Maya, XSI, C4D and a handfull of others as thats what the industry works iwth, not blender and alike nor "laughable" stuff like fragmotion (as much as I love and use it ) and other $50 things that work for exactly 1 task but not the whole production.
also that does not change the fact that FBX and Collada are the agreed industry standards and those are agreed to by the industry as whole, not a handfull of users, and they replaced OBJ which was the previous industry standard. If Obj weren't that crap for various relevant usages in games and unity, I'm sure it would be the main format, but unhappily it just has limits that kill it from the list of potential formats.
And as mentioned, unity also supports collada as such. A tool that supports neither fully is not meant to be really used for modelling for other applications, its target is to work for itself or as modding tools for given engines, but thats it, as Collada (dae) as FBX are the two defacto standards in the modelling industry and support for neither means no support for the industry.
but we should get back on topic
This is true, for the engines that want thousands of dollars for a license.
The issue here is that Unity's business model is predicated on getting as many newbies and people wanting to stay on the cheap as possible, and gradually convert them; if they hit a wall in terms of developing content, they probably get frustrated and drop out.
I don't think it's in Unity's interests to have barriers to entry. I can see that if you're a Pro user, you don't care much, because you've already paid your dues, so to speak, but my feeling is that the kids coming in are the future, and they need to get on board as inexpensively as possible.
Thats why Unity supports Collada and FBX.
One of the two is supported natively by any tool that is meant to be used with anything else and not just within itself for rendering and outputting images. You won't find tools meant to be used as part of a tool chain that do not support either of the two.
Any tool creator telling you something different must have been in cryogenic sleep for the past 5 years as he / she is not even remotely in "now" anymore with his thinking and standards.
Collada was designed as tool exchange format and is an open standard.
FBX was designed for specific tools and got adopted cause it has active Autodesk support and autodesk just is the defining center point for the whole industry as nobody prevents them from monopolizing the most used tools.
Maybe autodesk's cinema 4d 2013 and Zbrush 2013 comes out by the end of next year
This is getting a little off topic.
C4D couldn't be arsed to add normals / phong support to FBX for what, 3 no 4 versions now? I recently had to use Collada for hard edges in a project (complete with garbled model names), quite saddening when C4D r10 has such a smooth pipeline to Unity. In it's self this is ironic, considering the Collada output is non standard when dealing with other engines like papervision (yes ok going back a bit. On that project we ended up using the "Mental Mother in Law" AKA: blender, and won an award from the Collada foundation!)
For anyone who puts time into their models, this is frustrating. Sorry for venting on the internet.
In regards to the isometric problem, sorry to be misleading. This is a problem with their sketch toon output / save to .ai output. simply doesn't work as advertised. It was for a big client where we needed to print out a huge rendering in isometrics of some architectural work, output from C4D was most terribly broken. (had to ask a buddy to render this in Max)
The only thing wrong with FBX as far as I can see is C4D's lack of phong support, and Maxons cock-up in regards to complete disregard for the Unity pipeline in r12. (which does leave room for heroes like Dan to come in but thats another story)
It's a one sided relationship. I may sneak off with Maya as suggested. (although, I'll always be thinking of C4D)