RealFlow Official Forum

Hi, I remember having this convo at some point last year when some fine members of the RF dev team came for a visit around siggraph time, But I wanted to get back to it and refresh my memory.

currently RF has a bunch of file formats..
moving forward, which ones are going to be "THE" formats to use and which ones are being deprecated?

I seem to remember you guys saying that all the grid formats like gfc are going away?
to be replaced with openVDB and Field3d I'm imagining ?

then for particle formats. you have several.

.bin
.rpc
.pxy

it seems to me that .pxy could be rolled into .rpc now that .rpc supports any arbitrary channels
and you could use the selective load / unzipping feature to skip attrs you didn't want to load to speed things up... still wouldn't speed up disk IO.. but you could always write out the same format with less channels on disk as well.

so that leaves .bin... is it staying or going? it seems to be the only format that is still supported across the board, but its about 3-5x slower than the new RPC format and I'd hope you had plans to convert all the current .bin functionality to be able to use .rpc instead..

so that being asked..

whats the skinny?

please let me know when you have a chance..
-johnc

Hello, the idea, now talking about particle file format, is to move everything to RPC, as you cleverly pointed out now that with support arbitrary channels and compression into RPC the other file formats, specially PXY and BIN can be deprecated. We will be doing this in the next versions, and eventually PXY and BIN will disappear.

I want to stress the idea that RPC is the internal file format used by RealFlow where you can get the most, in terms of speed and memory footprint. But, ABC (alembic) is going to be improved and supported in future versions of RealFlow as well, as an alternative way of import/export particles that is more compliant with people pipelines.

About field file formats, GFC is out internal format, is fast and the memory footprint is low compared to VDB and F3D, mainly because those being not our internal format need conversion that takes time and memory. No plans to remove GFC in the medium term, maybe eventually in the future if we change our internal data structure to be OpenVDB we could remove the GFC file format. As I said this is something we don't know yet.

Thank you for your questions.

Thanks for the info Angel,

I will continue work on the RPC file format then and will not worry about the pxy format at all.
Are you guys going to put out a file spec on the GFC file format ? does it contain the particle positions per voxel or is it just the voxel data that gets interpolated particles put into it? what data channels get stored in it?

Alembic and OpenVDB are definitely going to be more useful as things move forward, and I'm definitely hoping in more and more support for those natively.

thanks for the info

-johnc