Clone this wiki locally
GTO File Format, Plugins, and Utilities
GTO is an open source file format designed for computer graphics. It was developed by Tweak Films to serve as the core storage format for our geometry and rendering pipeline. GTO is used by VFX and animation facilities, post-houses, and game developers for a wide variety of applications. It’s small size and versatility make it useful for animation, modeling, particle dynamics and 3D paint. It can be used to replace file formats such as PDB/PDC, obj, and binary RIB.
At heart GTO is just a clean and optimal way of storing large, named, and organized arrays of binary data (although there is a text version of the file too). GTO naturally lends itself to a “least common denominator” role between computer graphics applications. The storage mechanism and the data layout are independent, so that the format can be easily adopted without regard to how the format is used by any particular application. The GTO library has bindings in C++ and Python making it relatively easy to develop custom tools to read, write and manipulate GTO files.
The GTO library includes the low-level reader and writer classes, a slightly higher level raw data reader/writer, and source code for a Maya scene and particle export, particle display, a Maya deformer to use GTO as a geometry cache, Houdini plug-ins, a number of command line tools, a Wavefront .obj parser (for a command line converter), and a Python module for reading and writing GTO files. The GTO reader/writer and tools have been tested thoroughly in feature film and game production on GNU/Linux and OSX as well as Windows XP, Vista, and 2000. GTO is also used as part of Tweak Software’s commercial products.
GTO is still being developed. In the past, all development occured at Tweak Films. However, since Tweak Films has gone into hibernation, that situation has changed: there are now a handful of organizations contributing to the project. We at Tweak Software are also continuing development (GTO is native file format for RV), and are coordinating with the other big users.
There is a new project which is currently in the design phase to create a higher level library on top of GTO to make geometry and other graphics related data even easier to deal with in an agnostic manner. The primary use target for this work will be simulation, modeling, and image processing applications. Two of the major goals will be to have machine verifiable correctness for data layout and the storage and retrieval of multiple arbitrary graphs connecting GTO objects.
The current development release version is 3.5
The GTO library and included programs are provided under the terms of the GNU Library General Public License with exceptions for static linking (see LICENSE file in the source code for details).
If you extend, repair, or invent a new protocol for the GTO format and would like it incorporated in our tree drop us a line at some email address you can probably figure out. Or just drop us a line telling us you’re using it (at the same email address).
Older Version History
- Version 3.4
- Human readable plain text version of GTO. Some readers may
not function if they assume that the property size is known
when the property() virtual function is called. The property
size is only really known when the data() virtual function is
- Animation curves are now stored per-object using the animation
- New GTV file format is a GTO derived movie file format.
- Version 3.1
- RenderMan plug-in documentation added.
- Version 3.0
- An interpretation string has been added to the property
- An additional uint32 has been added as padding to the object,
component, and property headers for future expansion slop.
- A section on interpretation strings has been added to the
documentation and to the reader/writer classes.
- Added a type reference to the documentation.
- Version 2.1
- `gtofilter’ was changed to optionaly accept POSIX style
regular expressions in addition to shell-like “glob”
- The C++ writer class now defaults to writing compressed files
when the open() function is called. A second bool argument
can be passed to it to prevent the compression.
- The proposed texture assignment protocol (from version 2.0.4)
has been rejected.
- A new protocol “channel” is introduced for assigning mapped
surface varying data on geometry. An arbitrary number of
texture maps may be assigned to the geometry.
- The material protocol has been fleshed out.
- The polygon protocol was missing the definition of the
optional mappings component.
- Version 2.0.5 Bug fix version. Repaired problems with the
configuration scripts. Missing headers.
- Version 2.0.4 Bug fix version. Some configuration problems solved.
- Version 2.0 File headers changed. The format is not compatible
- Version 1.0