Let F3D take as input a model via streaming rather than filename

[mrdeveloperdude]

See related issue for streaming output.

F3D currently accepts a model name as a command-line argument.

F3D will then read the model from disk before generating a preview.

In many cases model files can be quite large and reading them from disk can incur significant IO penalty. Further, in many cases we already have the contents of the model file in memory from previous work.

This feature request is for having a sanctified and documented way of streaming the model data into F3D without having to save it to disk first to avoid said IO penalty.

There are ways to possibly do this (untested by issue author) by the use of tmpfs on linux platforms, and by passing /dev/stdin as the model filename.

There is also the possibility of using libf3d instead of the stand alone executable.

Here are some relevant comments from discord:

stream input is on the to-do list but requires changes in underlying libs so the ETA isn't entirely up to F3D (the changes are slowly but surely making their way into VTK as far as I know)
stream output should be doable on F3D's side

tracks that can be investigated without waiting for any new features:
using a ram disk, I'd be interested in seeing a benchmark of piping from stdout to stdin vs. writing and reading in a tmpfs directory (in theory piping should be better because it allows actual streaming, however in the case at hand we can't really render without buffering the whole input model and output image anyway so the streaming aspect won't matter and we just want fast/cheap IO)
using libf3d instead of the F3D application, for example through the python bindings, would let you read rendered images from memory and also allows to do multiple renders of the same model without reloading it

[mwestphal]

Please note being able to stream would be great for two other issues:

• Windows thumbnailer improvements: Improve Windows Thumbnailer #797
• Android version: Add a mobile version #27

This already support by the libf3d API however not all format supports it, this require major improvements in VTK to support all formats.

It also requires to identify how to do that with the F3D application in a cross platform way.

[joa-quim]

I would love to give this a try from Julia. But C++ is difficult to interface with. It would much easier if a C API could be added as well. ... Just wishing.

[mwestphal]

We thought about a C API but it would have been too restrictive. Maybe use the python API instead ?

[joa-quim]

OK, it's perhaps a bit too soon to talk about it since this feature doesn't exist yet, but a python API is no option for me. What I'm interested is in a way to exchange data, already in memory, between Julia and F3D. I mentioned C for two reasons. First because that's what I know and second because Julia has a very convenient way of communicating with C that doesn't depend on any 3rd party tools.

[mwestphal]

Sure, C API is not planned for F3D I'm afraid.

[Meakk]

I agree with @joa-quim, C bindings are required. Not only for Julia, but other language like Rust could use it.

[mwestphal]

C bindings seems indeed required in order to support interop with rust and julia. Lets see if there is interest from the community: #1307