EC - Objects

Information from objects contain position and geometry data, but also deformation data. For example: soft bodies or vertex manipulations performed with scripts and plugins. Even objects without enabled dynamics features can be recorded. Although the positions of these objects remain absolutely static, it is possible to extract their shape from the export resource and recreate the original geometry inside a 3D program. Please be aware that RealFlow's object cache formats do not support objects which are dynamically created during a simulation. All objects, added via scripting, must be added before the simulation starts, otherwise their motion and position data will not be correctly recorded.

RealFlow provides two fundamental concepts for the export of objects data. The first method is based on the individual nodes: when you add, let's say, 15 different objects, you will see the corresponding number of entries under the “OBJECT” branch. For each object it is possible to separately activate or deactivate their export resources. Individual export resources are, for example, required for the cache mode, or wetmaps. After the simulation there is also a total of 15 SD files in the project's “object” folder, carrying the names of the exported bodies.

The other mode writes all object-related data to one single file, called “animation.sd”. This file contains all information from the nodes including their geometry and camera data. A very common workflow is to export wetmaps into separate image files, while motion and transformation data are saved within the “animation.sd”. As you can see, both methods can coexist.

Animation (.sd)

As mentioned above, this method is used to record animation data for the export of individual "Animation (.sd)" files. They are available for each object in your current scene. Of course, the files will not be stored as “Animation.sd”. By default, they carry the name from the appropriate node. In this case “Sphere01.sd”. Please note that RealFlow can slow down significantly if you decide to store large amounts of objects individually. SD files are fully supported by the exchange plugins, but please mind your nodes' name if you want to connect existing objects with data from the files (see below under “ANIMATION (.sd)”).

Alembic Animation (.abc)

With this option it is also possible to write out individual files for each object in the ABC format. Since Alembic is relatively new it is not supported by all 3D platforms so far, but for some programs there are 3^rdparty plugins available. Older versions of 3D applications will most probably not be able to read this file type. RealFlow's implementation of the Alembic format supports 10 different compression levels from 0 to 9. A higher value indicates a stronger compression. As usual, the compression requires some time and so the saving process becomes slower, but it is more resource-friendly.

Arnold Scene Source (.ass)

This is the scene description format of Solid Angel's Arnold render engine. You can export simulation data to native ASS files for direct use inside Arnold.

Geometry (.obj)

The OBJ format is very common and can be read by any 3D program as well as countless plugins or helper tools. In RealFlow you also have the possibility to export OBJ files.

Wetmap texture (*)

If you have activated wetmaps with your objects, it is necessary to enable their export. By double-clicking on “tga” in the “Options” column you can find all available image formats.

ANIMATION (.sd)

When this export resource is active, the data and information from all objects in your scene are written to a single file – regardless of whether they have dynamics features or not. RealFlow's exchange plugins can recreate objects from the contained data and connect them with the motion, position and deformation information. Cameras are also included inside this file. In some cases it is not desirable to use the geometry data from the SD file, for example in cases where you have worked with low-polygon proxy objects. In such a situation, the motion data from the SD is connected with an already existing model in your 3D program. This workflow can lead to problems and confusion, because it is absolutely necessary to follow a simple rule:

Each external object needs an exact representation in RealFlow regarding names. Here is an example:

As you can see the names have to be exactly the same. By changing the name either in your 3D software or RealFlow, the plugins will not be able to find the original objects and the simulation data cannot be connected – the result is an immobile object. There are also some characters that should be strictly avoided with names: never use a dot, because it is used internally by RealFlow’s Python scripting engine. Forbidden characters are also vowels (ä, ö, ü) or glyphs like $, %, §, & and brackets. A filename should only consist of these characters:

CACHE (.bdc)

BDC files can be used to replace the other available formats, but only if exporting to other programs is not required. You can resume from BDC sequences and since they work on a scene level, all dynamics data from all object nodes will be stored in the same way as with the global "ANIMATION (.sd)" file.

If you want to use the "Cache" mode for simulations, you still have to use SD files for each object. The BDC format does not support the "Cache" mode.