EC - RealWave Surfaces

With RealWave objects it is possible to export various data types and it is necessary to differentiate between emitter particles, RealWave particle layers, surface deformation and textures. The RealWave node itself is built from polygons, representing a flat mesh, and becomes displaced by a number of modifiers, creating many different wave types. The deformations of a RealWave mesh can be stored in various surface cache formats.

Particle cache data, on the other hand, is directly created from the vertices and polygons of a RealWave object. It is possible to create 3D meshes from these particles and combine them seamlessly with "Object splash" or "Crest splash" particles. This option is also called “Particle layer”. Since particle layers are directly generated by the RealWave object, the associated particle resources can be found under the "REALWAVE" branch.

Particle cache (.bin)

To write out particle cache data, the RealWave node's “Particle layer” must be active – regardless of the used format. The BIN format is RealFlow's standard particle format and supported by our exchange plugins and the RealFlow RenderKit. Particle BIN files contain the full range of properties which are available for the different particle/fluid types.

Particle proxy (.pxy)

Proxy formats are perfectly suited to save large amounts of particle data, but not all of the information is stored with these files. Depending on the adjusted quality level particles are left out during storage. There are five quality levels (best – draft) to choose from. They can be seen/adjusted with a double-click on the “Best” option right of the export resource's name. The PXY format is only internally supported by RealFlow.

Krakatoa Particle File Format (.prt)

Thinkbox Software’s Krakatoa™ is a volumetric particle rendering system for 3DStudio Max. RealFlow is capable of writing native PRT files for direct use inside Krakatoa™. The PRT format also supports a wide variety of individual channels for all standard particle attributes. You can activate and deactivate them on demand by simply ticking the checkboxes.

Particle sequence (.pd)

The abbreviation “PD” stands for “Particle Data”. The advantage of PD is that you can select the data you want to see exported by simply clicking on the desired attributes. This feature saves disk space effectively. Since PD is also well documented, it is possible for users to write their own importer for reading out the files. As seen in the image, you can choose from a wide variety of attributes.

Particle sequence (.asc)

To write out standard ASCII files (a text format that is valid for all computers), please activate this option. Entries are directly readable and editable with any text editor. Currently, ASC is only supported for writing out files and customized data exchange, e.g. by using your own scripted or programmed readers.

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.

Particle sequence (.pdc)

The PDC format contains similar data as PD, but without the possibility to choose from attributes. “PDC” stands for Maya’s “Particle Data Cache” and it is an exchange format.

Alembic sequence (.abc)

The Alembic format is relatively new, but quickly found its way into the most common 3D platforms. One of the most important advantages is that Alembic is a hierarchical format. This means that the original structure of the source objects will be preserved, e.g. groups, links, connections etc. The Alembic format is also available for all major operating systems and does not require any extra plugins or exchange tools to load and process the data. RealFlow's Alembic particle files support all relevant magnitudes and properties: simply expand the Alembic tree and make your selection. 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.

Surface cache (.rwc)

Like the other cache files, the RWC format is for RealFlow’s internal use only to increase playback speed.

Surface cache (.sd)

RealFlow's SD format is, similar to BIN files (one the core formats) and is fully supported by the exchange plugins. The difference to other RealWave surface cache formats is that the entire RealWave simulation is stored within a single file. RWC or BIN formats, for example, follow the one-frame-one-file principle. Depending on the RealWave mesh's resolution, SD files can become very large.

Surface deformation (.lwo)

Another possibility is to write out a sequence of LigthWave LWO files – a format that is supported by many other 3D programs and therefore suited for data exchange. You might have to use special import filters outside LightWave, using LWO files to display the entire sequence.

Surface deformation (.bin)

This file type does not store particle data, but geometrical data from the RealWave mesh. RealWave BIN files have the same structure as their fluid mesh counterparts: they can be imported with the exchange plugin's mesh loader.

Surface deformation (.abc)

The RealWave mesh's displacement can also be saved as a sequence of Alembic files. Like the other Alembic export resources, the RealWave type supports ten compression levels from 0 to 9, with 9 being the highest level.

Surface deformation (.ass)

--->>

Foam texture (*)

Due to the fact that RealWave objects can create foam textures, it is possible to store matching greyscale images with the waves. By clicking on “tga” under “Option” you can choose from several common image formats. It is also important to know that RealFlow textures are always square shaped.

Displacement texture (.tif)

With RealFlow it is possible to export tileable displacement textures instead of, respectively additionally to the surface displacement file(s). These textures always use the TIF format and RealFlow writes out one file per frame. The files can either be loaded as sequences for post processing or merged to create a video that is attached to a texture’s displacement shader. They can also be used with Next Limit's RFRK 2 displacement shader.