The future of loading files with F3D and the libf3d

[mwestphal]

In the context of resolving https://github.com/f3d-app/f3d/issues/597, some discussions happened on discord and offline, so I will try to summarize it here.

Currently, F3D and the libf3d dinstinguish between fullscene loading and geometry loading. Some formats even do not support both. Almost all format support geometry loading and only a handful support fullscene loading.

The fact that some format do not support the to be opened as a full scene makes sense from a dev POV of the file does not contains any scene information, only geometries.

The fact that some format can't be opened only as geometries is an limitation of VTK and F3D file readers.

From a user POV, loading a file as a geometry should not be much more different than loading a fullscene that happens to not have any lights, cameras or texture.

Of course, implementation wise, there must be some difference, but they should not be so fundamental as impacting as much the architecture and user experience of f3d and the libf3d.

How would that look like as a F3D user ?

• geometry-only and group-geometries option will disapear
• A new option for group file together appears, whatever their types and support of fullscene or not, probably regex based
• Switching between geometry mode and fullscene mode will just be an interactive binding, with a corresponding command line option to choose the mode at start

eg:

f3d ./path/to/folder --group="*.fbx" --rendering-mode="geometry"

or

f3d ./path/to/folder --group=".fbx" --rendering-mode="scene"

How would that look like as a libf3d user ?

The loader API that was reworked here: https://github.com/f3d-app/f3d/pull/634, but it will be reworked much further it would look as simple as this:

loader.add("a.obj"); // ok (A is visible)
loader.add("b.obj"); // ok (A and B are visible)
loader.reset();
loader.add("b.obj"); // ok (B is visible)

the rendering mode will simply be controlled by an option.

What do we need to do implement it ?

1. vtkImporter API improvement

First and foremost, an improvement should be made on the vtkImporter to be able to recover individual component easily and implement such API on all importers that VTK needs. This is a change that should be made in VTK and it should be made before the next VTK minor release. It will let us do something like:

importer->GetGeometries()

2. vtk 9.0 compatibility

Even if we have a nice API in vtkImporter, we will need to find a way to implement this with older version of VTK. It seems possible to do that by doing some smart bookeeping of the actors on the renderer. This needs to be tested and designed

3. Importer just imports now

While we already have the vtkF3DGenericImporter, most of its logic rendering style of rendering (point gaussian, volume..) will havbe to be taken out and be put in the renderer, so that the logic could be applied on any importer providing geometries

4. Importer do not load multiple geometries

In #634 we introduced the possibilities to load multiples geometries. This logic will be taken out of the importer and handled in the loader by manipulating multiple importer instead of only two (generic and standard) as currently

5. Rework rendering

All of this will have lots of impact on how rendering is handled and we do not foresee everything. We will try our best though.

Wait ? What happens when I do this ? f3d my_plyl_with_normals.ply, can I still show the normals ?

Well, yes, but with one more step. Indeed, the default rendering mode will be scene mode, which focus on texture and nice rendering. One will have to switch to geometry rendering mode. So this change is not retro compatible, even for F3D users.

So we will probably go into a major version change for this. F3D 3.0 here we come. We could even start to say that the libf3d API is coming out of beta and may start to be stable now, but this yet another can of worm.

When will that happen

Not before 2024 for sure. We already have tons of stuff to deliver in 2.0.

Hav