FBX support for CryENGINE3

Ruan

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

Computron

Awesome this should hold up for me until, I assume, the next SDK will have an updated exporter for Max 2013?

Is it going to be possible to export custom vertex normals into Cryengine soon in any way?

Ruan

Yes, the next release should have the 2013 plugins. Being neither an artist nor part of the tools team, I'm not entirely sure on custom vertex normals. In what instances would you use them?

bugo

I HAVE BEEN WAITING FOR THAT! Thanks Ruan.

Some quick questions:

Will you make it support different materials some day? It's quite needed...
Does it support color verts?

Ruan

Glad people find this useful Yeah, multi-material support is high on the todo list, I just want to get a working version released first so I can see which DCC apps play nicely with it. It doesn't support vertex colours right now but that's probably trivial enough for me to add tomorrow before (at least hopefully, fingers crossed) the first release.

|MM|

@Ruan
great effort indeed, I hope it's going to be usable soon.

I'm not entirely sure on custom vertex normals. In what instances would you use them?

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?

Ruan

Ah I see. I'm not sure whether the current normal system is due to the plugins or the engine itself, but I'll see whether that's viable.

Meanwhile, looks like we're good to go for a basic release (much) later today!



Oh, and this is definitely my project mascot:

e-freak

awesome work dude one question from your converter - how do you decide where the FBX should compile to in your build? (like Objects/Library/Architecture/Interior/bla)

Ruan

When you hit export, you get a save dialog This is just a test run really, I'm investigating proper ways of making the process more efficient.

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.

Computron

Custom vertex normals can be really usefull for getting really smooth shaded low poly models and clean normals bakes as well.

It the one DCC feature I want to be able to export the most.

cptSwing

Looks great man!

Ruan

Tentatively saying that vertex colours are in:




Edit: Yup, the blend layer appears to work fine:

e-freak

Ruan wrote: »

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.

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

biofrost

This would be great! My next project I was planning on using CryEngine3 but had been avoiding it because I heard it was a bit messy getting models from Maya to Cry3.

Can't wait to see this released!

Ruan

e-freak wrote: »

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

That was my first thought actually, but I think separating them is possibly easier for using version control. Rather than forcing designers/coders to check out source (ish) files too, you can instead just make the ArtSource directory a separate Git/Perforce/whatever repository and have artists commit their source files there.

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:

You can download the v0.1 release candidate here: https://github.com/downloads/returnString/ManagedFBX/CEFBX-0.1rc.zip

Important Info for Users
Run CryEngine.RC.Frontend.exe to start the application.
This application uses version 4 of the .NET Framework. Please ensure your version is up-to-date.
This application is untested in a release environment, so I can't guarantee it won't crash (but it hasn't in my debugging sessions!).
At present, your model should be at the root of the scene hierarchy (i.e., not be the child of any other object). The application doesn't currently merge nodes.

Features
UV maps: http://i.imgur.com/IPt85.jpg
Smoothing groups: http://i.imgur.com/PZZHM.jpg
Vertex colours: http://i.imgur.com/oD8LN.jpg & http://i.imgur.com/mDGUM.jpg

Limitations
Only handles a single mesh
The mesh must be at the root of the scene hierarchy
No multi-material support right now

This is not an official Crytek tool, please don't blame me if your PC spontaneously combusts, etc etc

biofrost

Awesome thank you so much. I managed to get one of my models in but with the other I kept getting an error saying. no model in FBX scene. Not sure why this is happening with some models but not others.

Either way great tool so far!

Ruan

The model isn't parented to anything, is it? At the minute the converter only scans the top level of the scene and just grabs the first mesh it finds, so things like meshes composed of several objects won't work.

cptSwing

^ Does that count for layers as well (in max?) - and you sir, are a star. Out with the plugins, all hail FBX!

Ruan

cptSwing wrote: »

^ Does that count for layers as well (in max?) - and you sir, are a star. Out with the plugins, all hail FBX!

I'm not actually sure, I just traverse an entire scene in FBX, not sure how that maps to a Max scene. Provided it's in the normal scene graph, I suspect it should still work...

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 (read: I've never worked with mesh programming before)

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:

choco

|MM| wrote: »

@Ruan
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?

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!

|MM|

@

The default exporter already supports edited vertex normals

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.

Ruan

I've got a local change that I think might work if the engine does in fact support custom vertex normals; does anyone have a sample .max/.fbx file that uses custom normals to hand?

In other news, got rudimentary physics working, need to add support for proxies later

|MM|

I'll try to provide something in a minute, but maybe it would be better if
you applied 'Edit Normals' modifier to an object and e.g rotate the vertex normals randomly.

Ruan

Well, clicking a button (I think it was unify?) with the Edit Normals modifier and this local change certainly did something...



Edit: Hrm, this works without my change. Interesting.

|MM|

What it did is average the normals as if applied to one smothing group.
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

Computron

Unify just puts everything into one smoothing groups. The vertex normals are still calculated by the engine. You want explicit vertex normals.

choco wrote: »

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!

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.

Ruan

Ah I see, still getting the hang of this 3D lark!

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

|MM|

Both are great news to me.
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?

Popeye9

Been using this on a couple meshes and so far has worked great. Looking forward to the updates

Olli.

So it exports the normals but doesnt use them?

oh crytek.

Computron

shading looks the same though.... wierd.

seith

biofrost wrote: »

I heard it was a bit messy getting models from Maya to Cry3.

It's actually quite simple if you use MayaCE3 (http://seithcg.com/wordpress/?page_id=973)... :poly121:

Ruan

I'll vouch for Seith's work seeing as he gave me some pointers developing this

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:

|MM|

Waiting for exporting material indices and we can get this baby started.

Paradan

just wanted to say thanks for making this.

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

Ruan

|MM| wrote: »

Waiting for exporting material indices and we can get this baby started.

Haven't abandoned this feature, I swear! :P Had some issues with extracting material IDs until I realised that Max doesn't export indices until your scene actually has a material instance... much rage when I figured that out. Now I just have to work out how material indices are represented in Collada and it'll be ready.

In the meantime, been playing around with the new pipeline tool (batch builds, woo!) and modularity:

|MM|

Haven't abandoned this feature

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).

Olli.

Im really sorry, but I still fail to see the gain you get from using this, as opposed to the official Max exporter.

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.

Ruan

If you have a supported Max version and you're happy with the import process, then by all means stick with it. I do hope to provide some extra value later on down the line with the new art manager tool (automatic conversion of source files inc. Max and PSD files

seith

Ruan wrote: »

... for the love of god just agree on things for once; surely, between some highly intelligent people, we could agree on which way is up?!

Of course, it's Y. Err... No wait it's Z...!! :poly124:

cptSwing

I like the more open support of FBX.. works just fine in UDK, no reason not use it for Cry.

Ruan

seith wrote: »

Of course, it's Y.

Burn the Maya user!

cptSwing wrote: »

I like the more open support of FBX.. works just fine in UDK, no reason not use it for Cry.

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.

|MM|

Ok, I've tested the converter with 3ds Max and Blender on a simple mesh.
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.

Ruan

No material IDs? Do you create multi-materials by assigning materials directly to polygons then? If you have any sample Blender-created FBX files I could take a look at, that'd be great (between work and projects like this, I can't invest too much time in learning extra software)

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:

|MM|

Ruan wrote: »

No material IDs? Do you create multi-materials by assigning materials directly to polygons then?

Yes.


Here are two cubes one with one material the second with two.

https://www.dropbox.com/s/47rr8069il37eqd/blender_fbx.zip?m

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.

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

Ruan

Thanks! Fortunately, material IDs for Blender objects with more than one material appear to export just fine:



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. However, in my quest for usability (futile, I know), manual material naming feels clunky and not overwhelmingly artist-friendly. I'll have to look into the best way to achieve this a bit more...

Ruan

Apologies for the bump, but I made a breakthrough and got material IDs working!

Olli.

those are some nice walls you got there!

I think we might just make an artist out of you yet.

biofrost

Awesome progress! Any idea of when the next release is?

Ruan

lololli. I hope not, I spend enough time in Visual Studio, I don't need more reasons to not leave my cave.

@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

cptSwing

awesome