Wednesday 8 February 2012

UDK vs CryEngine 3 SDK: Custom geometry

Today, I'll take a look at the pipeline for getting your own meshes into the editor. I will focus on "normal" meshes (i.e. those that are not rigged).

I won't spend any time explaining the actual process, the documentation (UDK, CryEngine) does that well enough. I'll be pointing out the restrictions and peculiarities that rule the way the artists should work. I will then go over geometry export, collision export, and material export.

Note that as I'm a Maya user these days, I may talk more about Maya than about Max.

Why should I care?
I want to know how quick it is to get a new model into the game, and how quick it is to update it.


In UDK

Note that I will only be talking about the FBX pipeline, as it is the one people are now meant to be using.

Rules
There almost aren't any. The only hard rule is that a single mesh cannot exceed 65535 vertices, which is probably way more than you should ever need for a static model. Apart from that, you can do whatever you like. You can organise the scene however you please, have several meshes, several materials on your meshes, etc. You don't even have to reset/freeze the transform, which leads to peculiarity #1:

Whatever transformation is applied on your mesh at the time of export will be considered identity. The most important thing to retain from that statement is: UDK doesn't care where you put the pivot of the object, it will always consider that the pivot is at the origin of the (max/maya) scene.

Also, UDK doesn't care about the scale of the scene. 1 unit in the scene = 1 Unreal Unit. Just be aware that, but as it's safe to scale objects, it's not a big problem if you get it wrong.

Another thing I have experienced is that UDK is sometimes struggling to import meshes that don't have any smoothing groups set. So remember to do that.

Exporting the geometry
In most (if not all) game engines, when you create your meshes, you have to export them in a format that can be read by the engine. This involves making an exporter that will come as a plug-in for the 3D modelling software. But when the new version of that 3D modelling software comes out, the plug-in becomes incompatible and needs to be recompiled.

Someone at Epic got bored of doing that and said "hey, why not do it the other way around a write an importer that would interpret the data from a standard format?" and they did just that. They chose the FBX format, which is now THE standard cross-application format for nearly all 3D applications. This means, that almost all applications can generate FBX files without a plugin.

The obvious downside to using a standard format is that you can't really carry across custom data (or at least it's not as easy to do so), but you can always design your pipeline around that.

So, in order to export a mesh for Unreal, there really isn't anything to do, except... exporting it. You don't have to set any options (apart from making sure you're using the correct version of the file format). When you import the FBX, you can specify whether meshes should be imported as separate assets or combined into one.

And that's about all there is to it, really. It's as straightforward as you can get.

Once imported into the engine, a tool called the Static Mesh Editor that gives you a lot of information about the mesh and allows you to edit some of the meshes properties (such as the material(s) used).

I know, this is terrible unwrapping.
In this tool, you can also generate the LOD meshes with a third party technology that does a quite impressive job.

Exporting collisions
Usually with Unreal, you create your collision meshes in the Static Mesh Editor. But for various reasons, you  may want to create custom collision meshes for your object. It's quite easy to do. Create the collision meshes, (making sure they're convex), name them according to a special naming convention, and export everything. The importer will recognize the collision mesh and set it up.

If necessary, it is possible to define several collisions meshes for a single render mesh. Note that they will be used all together to determine's the object collision.

Updating meshes
It's possible, it takes a couple of click, and it's updating all instances of the mesh without having to reload the editor. It's pretty damn good.

Exporting Materials
The usefulness of this feature is questionable as in Unreal, the material work is usually entirely done within the editor (except texture authoring, of course). But still, it's there.

So it is possible to export materials and textures assigned to the mesh. Nothing special to say here, except that there's seems to be some more restrictions on texture formats (Unreal is supposed to support PNG textures, but it didn't work through the FBX import. Also, it doesn't seem possible to update modfications to the material (but that's not really a problem).

In CryEngine 3 SDK

Rules
The first thing to note is that the Max and Maya exporters work a bit differently from each other, probably because of the way they each handles objects. Max doesn't have any scene requirements while Maya does. Basically, in Max you create objects and export them. In Maya, you create meshes, put them into a group that will define an object, and you will put these objects into groups that represent a file to export. That group will have custom attributes that will define what kind of export you're going to do (static geometry, character, animated object, etc.).

This means you can export several files at the same time from the same Maya scene. While it may be a very questionable practice in general, this can be useful if you have to export both a rigged and static version of an object, you'll have only one file to maintain for the two versions. The advantage compared to the Max pipeline or even Unreal, is that the group-based structure makes it very easy to take meshes in and out of export without having to adjust settings.

There's a last rule, which I find quite annoying: you HAVE to assign a material to the object in order to be able to export it. Though you don't have to actually export the material... Explanations:

The exporter complains if there isn't a material group in the scene. What's a material group? As the name suggests, just a group of materials (though materials are called shaders in the CryExporter's language). There's a tool to create material groups. Now, if any of the meshes you're trying to export is assigned a material that isn't in one of the material groups, the export will fail miserably (funny when the purpose-built export validator doesn't complain about that).

Exporting the geometry
Once you've followed all the above rules, exporting the geometry is quite simple. The export is actually a two step but simple process. First it will export the geometry as a Collada file, which then gets converted into a CryEngine specific format. This is fine and all, but the exporter is leaving the intermediate files behind, and I find this messy (though this is a way of getting a backup of the geometry, should you ever manage to lose the original scene).

The fastest way to get this geometry in the world is to use a brush (CryEngine's term for static meshes).


To get information about your meshes, you need to use the asset browser.


It will give you a certain amount of information, but there's no property you can modify from there. The meshes are apparently meant to be used "as exported" (though it is possible to override the material on a per instance basis).

Regarding LODs, they must be hand-made in the modelling package.

Exporting collisions
In the CryEngine world, collision meshes are called Physics Proxies. There doesn't seem to be any actual restrictions on the collision mesh's shape (not even naming rules). Like normal meshes, you need to assign a material (present in the exported material group) to the collision mesh. You know, the thing that is usually not rendered. And paradoxically, it's even more important for collision because... it's the material who holds the physicalisation settings. Yep. Really strange. However, past the surprise of the unusualness of that pipeline, the process is fairly quick.

Updating meshes
This, dear reader, is brilliant. To update a mesh, all you have to do is re-export it. If the editor is running, it will pick up the modification and reload all instances of the mesh without having you click on any button. There's a semi-exception to the rule, though. Physics proxies are live updated only if you touch an instance of the mesh. And that will only update that instance. Quick solution is to re-open the level.

Exporting materials
Unlike in Unreal, here most of the material work seems to be done in the modelling package. The material pipeline deserves its own article, so I'll just talk about their relation to meshes.

As we've seen before, you have to give your meshes a material that is in a material group. However, that material group doesn't need to be exported. In that case, the mesh will have a red "Placeholder" texture. Since you had to create the material groups to exports the geometry, half the job is done to export the materials. To do so, just click the "Generate Material Files". This will generate a .mtl file, which will automatically replace the placeholder materials for all the relevant objects.

Conclusion

I quite like the scene setup in the CryEngine for Maya, it makes it easy to experiment with stuff, and iterate. The whole material malarkey is weird, but doesn't slow the process down. However, Unreal is offering much more customisation of the data, as well as automated collision and LOD generation (especially since they integrated Simplygon tech), which is a big deal.

I'd say I prefer CryEngine's workflow, but Unreal is making many things easier as it relies less on artists. Though on the grounds of "getting (updated) geometry in game quickly", they're both equivalent.

4 comments:

  1. Awesome series... keep it up! :)

    ReplyDelete
  2. i love this series & looking forward for more, am a Unity user now & love CryEngine but never tried to work in a big scale with UDK as it is always heavy on my PC (8G RAM ) , i have only one question , which one is the best for you, UDK or CRY ? just to know your point of view

    ReplyDelete
    Replies
    1. Well I don't really know yet, finding out is the whole point of this series. My general feeling (at the time of writing) is that CryEngine has more user-friendly tools but Unreal has a more flexible tech.

      Delete
    2. Yea, that's pretty close to what i can see, CryEngine Just need to be completely available to release your apps for free for a limit (like Unity & UDK ) & it will be completely in hands and conquer the indie market , it is easy, so friendly and strong enough

      Delete