FBX support for CryENGINE3
Hi guys, Ruan from Crytek here; been working on this for just over a week now and I figure that an artist-centric forum is probably the best place to get feedback on this!
Because plugins are so last year, I've been developing a converter that takes an FBX file and spits out a nice CryENGINE-ready .cgf file. As well as removing the requirement to use plugins, this also means you can use your favourite 3D software rather than being forced into Max or Maya!
At present, it only supports static meshes, a fair bit more effort will be required to get rigs and animations etc working. The main caveat is that you can currently only use one material ID; everything else like UV mapping, smoothing groups etc work just fine.
Excuse the programmer art, but here's a test I created earlier using Max 2013 (for which a plugin isn't currently available):
If anyone has any suggestions for how this could added to your workflow in the best way, please just shout
Because plugins are so last year, I've been developing a converter that takes an FBX file and spits out a nice CryENGINE-ready .cgf file. As well as removing the requirement to use plugins, this also means you can use your favourite 3D software rather than being forced into Max or Maya!
At present, it only supports static meshes, a fair bit more effort will be required to get rigs and animations etc working. The main caveat is that you can currently only use one material ID; everything else like UV mapping, smoothing groups etc work just fine.
Excuse the programmer art, but here's a test I created earlier using Max 2013 (for which a plugin isn't currently available):
If anyone has any suggestions for how this could added to your workflow in the best way, please just shout
Replies
Is it going to be possible to export custom vertex normals into Cryengine soon in any way?
Some quick questions:
Will you make it support different materials some day? It's quite needed...
Does it support color verts?
great effort indeed, I hope it's going to be usable soon.
Custom vertex normals would be extremely useful despite vegetation shader partially alieviating the problem
of blocky shading (but only partially).
I'm not sure it's something that can be done with an exporter is it?
Meanwhile, looks like we're good to go for a basic release (much) later today!
Oh, and this is definitely my project mascot:
One idea I had was to stick a sort of source directory in the engine root which could be mirrored to Game/Objects. So if you placed blob.fbx into ArtSource/Library/Misc/, you'd end up with Game/Objects/Library/Misc/blob.cgf.
That could be an automatic process, if I made the tool watch the filesystem, so you could just drop your FBX files with the tool running and get your files instantly converted for the engine.
It the one DCC feature I want to be able to export the most.
Edit: Yup, the blend layer appears to work fine:
This. A million times! Even better - if you could have the FBX within the same directory and it compares a timestamp with the last time the tool did the scan
Can't wait to see this released!
Another thing I want to do in that sort of vein is investigate conversion of proper source files, similar to how Unity does it, i.e., taking a .max file and invoking Max to export to FBX which is then processed.
Anyhows, copypaste from CryDev for a very WIP test release:
This is not an official Crytek tool, please don't blame me if your PC spontaneously combusts, etc etc
Either way great tool so far!
The end result of this should handle multiple meshes, hierarchies etc just fine though, but right now I'm taking baby steps and ironing out issues along the way
Edit: Been doing some more testing/actually learning how to do things in Max and I'm pretty happy that the blend layer works just fine:
The default exporter already supports edited vertex normals
Amazing work btw ruan, I've been following the progress for the last few days on crydev, I'm eager to get my hands on a finalized build.
Keep it up!
Are you sure? Can you prove that?
I don't have access to 3ds max 2013>, when I was testing it on the trees with custom projected normals it didn't have any effect.
In other news, got rudimentary physics working, need to add support for proxies later
you applied 'Edit Normals' modifier to an object and e.g rotate the vertex normals randomly.
Edit: Hrm, this works without my change. Interesting.
It doesn't show anything.
Do something like this.
Create a cube, by default its normal look like this.
Select them ,rotate them as you wish.
r_ShowNormals in the editor's console
It does? I can't export to cryengine through the official tool right now as I am on max 2013. And google shows nothing about cryengine support this.
In that case, the normals are certainly carried over:
...but to what end I'm not sure.
Gotta add support for material IDs and then 0.2 should be ready
I'm not sure still though if the shading in CE3 makes a lot of use of vertex normals.
It's even visible on the 2nd screen, maybe you could try bending them some more, and rotating just as single normals not per vertex?
oh crytek.
Promised myself I'd work on the pipeline a bit today, and here we go, a first pass attempt (this is in no way/shape/form the final interface, just an idea of what I want it to do!):
I also figured out the mystical matrices (I seriously hate maths) required to bake transformations into vertex positions, so now custom pivots etc work:
as Autodesk products aren't accessible to me (non-student/don't have money to burn), I've always wished that SDKs would release stand-alone exporters instead of plug-ins.
it's great to see something like this
In the meantime, been playing around with the new pipeline tool (batch builds, woo!) and modularity:
Not accusing you of that:), but the thing is when you have the material ID's exported
most of the environment stuff will be possible so it's a bit of a milestone to me.
With the materials and collada maybe it's really worth talking to angjminer (CryBlend) cause he's got that worked out.
Actually in CryBlend material indices are determined in materials' names
as material properties are, which forces having a material.(but takes a bit of time to get used to)
Also I wonder how you'd make materials properties to be assigned to the materials.
I mean in the 3d app, if you plan on supporting this anyway (material creation).
Now if we ignore possible max compatibility issues, and assume that your max version is able to use the CryExporter, then can someone explain to me the pro's and con's of using this FBX exporter instead?
Im sorry im not trying to slander this project in any way, I just thought i'd probably get a more understandable answer from someone who has a firm grip on asset create pipelines and such.
No im not Canadian, I just say like to say sorry a lot.
No reason except Autodesk's excuse for an SDK >_> Although, in parallel, I'm developing a .NET wrapper for the format which should make life easier for anyone else looking to create an FBX pipeline in the future.
Everything seems to work rather fine.
Talking of Blender as far as I know it doesn't support mat id's at all.
I don't know how fbx stores materials, maybe the exporter assigns
the id's in some way but there's no control over it.
There should be an option to assign the id's and physicalization type in the UI
of the converter IMO.
PS: I'm writing all this since I'd just really like to use it right now, cause I'm making a new environment
and all I need is the id's and a possibilty to export a mesh with no
default phys or a custom proxy for the sake of speed.
Agreed that physicalisation options etc need exposing but I'm not sure how to best do this. I could use material names, but that feels clunky. I also can't depend on app-specific material params like our in-house plugins do.
Perhaps a checkbox for physicalisation, and then the app would first try to use the mesh's proxy (a child named "proxy"), then otherwise just physicalise the render geometry.
And the obligatory progress shot:
Yes.
Here are two cubes one with one material the second with two.
https://www.dropbox.com/s/47rr8069il37eqd/blender_fbx.zip?m
Not sure what you mean here. There's 5 types of physicalisation right?
So each material should perhaps have it's dropdown menu to choose the type it needs. (phys_None by default)
Also as I said the CryBlend material naming convention takes some time to get used to,then comes pretty natural, but if it can be done with the UI then whatever.
It goes like this
| libraryname__ID__materialname__phystype |
So for example
tree__1__canopy__physNone
tree__2__trunk__physNone
tree__3__proxy__physProxyNoDraw
And this works just fine with my FBX library:
So now this just needs mapping to Collada...
I'm familiar with the 'CryBlend' naming conventions because those are actually what we use internally for our Collada variant.
I think we might just make an artist out of you yet.
@Biofrost: The code's all in place and committed, so I've just gotta add a checkbox for physicalisation (no proxy support yet, that's coming next); I'll hopefully be releasing this tomorrow unless anything explodes in the meantime