Supported model formats

The following 3D and 2D model formats are supported by Castle Game Engine. You can load and display them using TCastleScene in a viewport. You can also open them in view3dscene.

1. Best formats (recommended and with great support)

1.1. glTF 2.0

An efficient, modern format for animated 3D and 2D models.

glTF is supported by a lot of tools, in particular Blender has a full-featured exporter to glTF built-in. We are dedicated to perfect glTF support, with all the features and efficiency.

Details about glTF support in Castle Game Engine.

1.2. Spine JSON

Spine is a powerful program for 2D game skeletal animations.

We have a big support for Spine JSON features, and our friendly game studio Cat-astrophe Games is using Spine for all 2D games.

1.3. X3D and VRML

X3D and VRML is a flexible and powerful format for 3D models and a basis of our scene graph.

The following extensions are recognized:

• X3D in classic and XML encoding: .x3d, .x3dz, .x3d.gz, .x3dv, .x3dvz, .x3dv.gz

• VRML 1.0 and 2.0: .wrl, .wrz and .wrl.gz.

We have a great support for X3D and VRML, and handle rendering, animation, interaction, scripts, shaders and more features of these formats. An entire section of this website, Scene Graph (X3D), documents all the features we support (from the X3D and VRML standard, and many of our own extensions).

Note that X3D has a lot of features, and most exporters do not allow to configure everything possible in X3D. But you can use Inline node to include one file (X3D, glTF or any other that CGE can handle) within another X3D file, and you can simply write some X3D content by hand. That's good for adding scripts to 3D data, and generally adding stuff that is uncomfortable (or impossible) to design in your 3D modeller. See e.g. the terrain_multi_texture.x3dv example (X3D file from fps_game example).

1.4. Sprite sheets

You can load animations as sprite sheets, defined using various formats:

1. Castle Game Engine format (extension .castle-sprite-sheet), created by sprite sheet editor inside the CGE editor.

2. Starling (XML) format (traditionally with .xml extension, in CGE we require you rename them to .starling-xml).

3. Cocos2d format (traditionally with .plist extension, in CGE we advise (but do not require yet) to use .cocos2d-plist).

See the sprite sheets documentation.

2. Other formats (supported but not recommended)

2.1. MD3

MD3 is a 3D model format used by id Tech 3 engine and games based on it, like Quake 3 and Tremulous.

We have advanced support for this format, including skins and animations. More information in a dedicated page about MD3 support.

2.2. Simple images

You can load image as a scene too. That is, you can load a simple PNG, JPG etc. file using TCastleScene.Load method. It will create a rectangle (which you can use as 3D or 2D object) using this image as a texture, with size adjusted to the image size.

Or, even better, use a dedicated TCastleImageTransform that is a transformation dedicated to loading the image, it has helpful properties to easily adjust image size, repeat, pivot etc.

See also image loading documentation.

2.3. Animation through a series of static models

Animation through a series of static models like xxx000.obj, xxx001.obj, xxx002.obj....

This is useful if you have files named like:

xxx001.obj
xxx002.obj
xxx003.obj
...

You can load such animation from a sequence of files using the URL xxx@counter(3).obj. It's exactly how you can load a movie from a sequence of images. See demo-models/.../wavefront_obj_animation for an example, you would load them by skinned_anim_@counter(6).obj.

It's not an efficient way to store the animation in a file (or to load it). It is much better to export to X3D or glTF animation, if you can. But it may be useful when you have no other option to export.

Blender exporter to Wavefront OBJ with "Animation" checkbox generates such animation. Hint: uncheck "Write Normals" and check "Keep Vertex Order" in the exporting dialog box, to make sure models are "structurally equal" which allows CGE to merge the animation nicely (even produce more intermediate animation frames, if needed). This also means that CGE will recalculate normals by itself (unfortunately this isn't always desired, because Blender doesn't pass the creaseAngle information to CGE, so CGE cannot smooth the normals as in Blender -- it doesn't know when it should).

The animation is played and smoothed following the same logic as castle-anim-frames format. In a way, using URL xxx@counter(4).obj is just a shortcut for creating a xxx.castle-anim-frames file that would list the appropriate static frames using XML elements.

2.4. Collada

Collada (.dae extension). We support a lot of Collada features — geometry with materials, textures, cameras, lights. Tested on many Collada examples, like Collada Test Model Bank and Collada models exported from various Blender versions. All modern Collada versions (1.3, 1.4, 1.5) are handled.

Animations in Collada files are not handled yet. If you need animations, we advise to use glTF instead. glTF is newer and has similar feature set. Khronos provides a converter from Collada to glTF.

2.5. OpenInventor

OpenInventor 1.0 ASCII files (.iv extension) are handled. Inventor 1.0 and VRML 1.0 are very similar formats, we also handle some additional Inventor-specific nodes.

2.6. 3DS

3d Studio 3DS format. We support most important things: meshes, cameras, materials, textures.

2.7. Wavefront OBJ

Wavefront OBJ files. We support most important things: geometry (with texture coords, normal vectors), materials (colors, opacity, texture filenames).

2.8. STL

STL (Standard Triangle Language, aka STereoLithography). STL is a simple popular 3D format used in 3D printing. We support both ASCII and binary formats.

2.9. Videoscape GEO

Videoscape GEO (.geo extension). Very basic support for this very old 3D format.

2.10. Deprecated: Castle Animation Frames (castle-anim-frames) format

Castle Animation Frames (castle-anim-frames) format, formerly known as kanim.

This is a simple format for animations, which we used in the past to export animated models from Blender. It supported animating of everything in Blender (transformations, skin, shape keys, materials, particles, physics...), although it is somewhat memory-hungry.

We advise now using glTF for all your animation needs.

3. Other formats (not supported by engine core, but can be used with additional tools)

3.1. SVG

You can use X_ITE converter to convert SVG to X3D and then read X3D inside our engine, as a scalable geometry. There is also a command-line converter x3d-tidy using the same X_ITE under the hood.

Note that in the generated X3D file, all objects will be placed at the same depth, Z = 0, at least right now. You may have to fix it to avoid Z-fighting in case SVG layers overlap. For simple cases, it is possible to do this by just manually editing the X3D file in any text editor.

For more information see:

• News post about it

• demo-models/svg with an example SVG and X3D files documenting the process.

Of course you can also convert SVG to a raster image (like PNG) using e.g. Inkscape export options.

3.2. FBX

FBX is a proprietary format from Autodesk. As such it has good support in Autodesk software like 3ds Max and Maya.

If you have FBX models, we recommend converting them to glTF using FBX2glTF. It's a simple command-line tool, just call it with the FBX model file name:

FBX2glTF model.fbx

After the export, the modelname_out subfolder will appear with the exported model. The conversion result can be easily compared using e.g. view3dcene and FBX Review.

Note: We do not recommend using FBX in your workflow. We believe that open standards, like glTF and X3D are a better way to innovate. See e.g. Michalis GIC 2022 presentation slides.