Which output format to use (and how)

[Theverat]

Hi,

LuxCore now has many output formats for film and scene saving.
I guess that for end users, the following are the most useful:

• Full scene + film in binary format (.bcf), future-proof, can't separate .blend file from film, can always resume
• Only the film (.flm), if the user does not want the overhead of the full scene data

The properties related to .flm saving seem to be grouped under periodicsave.film..
However, I found no such settings for the .bcf file (to save it periodically).

Which output formats should I support in the Blender addon and how do I set their properties?

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[Dade916]

".bcf" includes also a RenderState object. It is required to resume a rendering so or you save 3 separate files (film.flm + scene.bsc + renderstate.rst) or you save the resume.bcf alone. I would say the later is the most practical option for the end user. It is error proof however it may be time consuming, probably something to do every 30+mins.

There is a "periodicsave.resumerendering.(filename or period)" property to save the .bcf file: https://wiki.luxcorerender.org/LuxCore_SDL_Reference_Manual_v2.0#Periodic_save

There ins't an option to save the .bcf because it doesn't change during the rendering so it would be useless. It can be saved once before to start of the rendering and it is all you are going to need.

I can add an option to periodically save the render state if you want go for the 3 files solution instead of 1.

[Theverat]

There ins't an option to save the .bcf because it doesn't change during the rendering so it would be useless. It can be saved once before to start of the rendering and it is all you are going to need.

I thought it also contains the film?

[Dade916]

Nope, I followed your error in my answer (at the start, where there is written .bcf, it should be read .rsm).

.bcf => binary scene
.rst => render state
.flm => film
.rsm => binary scene + film + render state

[Theverat]

Ah, thanks for clearing it up.

I think it would be most convenient for users to save only a .rsm file periodically.
However that is probably too much data to write if the scene is very big, right?

Crazy idea: can LuxCore only write the film + render state to the .rsm file and skip the scene writing?
I realize this probably requires a lot of code changes, you don't have to do this if it's too much work.

Another question: does the render state change during the rendering? Or can that also be written at start?

[Dade916]

I'm looking into this problem. At the moment, you can not read only a single section of a .rsm file (for instance only the film or only the render state). This is due to Boost serialization because I don't know the size of serialized data before writing them (so I can not write a table with access offsets at the beggining of the file).
So I will probably have to write the single element to temporary files and than build a single file out of them.

Another question: does the render state change during the rendering? Or can that also be written at start?

Nope, it includes stuff like the current status of the sampler (for instance the sobol pass), Tile Repository for TILEPATH or the convergence status for adaptive sampling. It is not like the old Lux where only the seed was used, LuxCore really restarts the rendering from where it was left.

[Dade916]

My idea is to use a new archive-like file format with multiple-objects inside (so every single object can be read/written/updated). However it is a change a bit too big for my taste at this stage of v2.0 release. I'm going to postpone the implementation to the next release.

[Alpistinho]

Hi,

Just as a suggestion, I believe SQLite could be successfully used as a archive-like format.
According to my understanding it has some nice properties such as:

• It's a pretty small dependency
• It's production-proven
• It's available in python standard library (and has bindings for most other languages)
• It's interfaced with using default SQL language, instead of having to write some more obscure serialization/deserialization interface.
• Can support multiple ways of storing data, just by having a properly-defined table schema.
  • The scene definition and configuration could be stored in the same file, without any extra infrastructure