In a few locations, extensions are still listed (eg linux thumbnails) rework this to rely on the factory instead

Documentation is hard to maintain, here is the current state:

• README.md contains the whole user documentation
• GENERATE.md contains some developper oriented documentation
• documentation/* contains a duplicate, segmented and slightly modified version of the README.md
• src/F3DOptions code contains options, hotkeys and examples documentations to be delivered with --help
• man contains documentations generated from --help and --version
• We potentially will have one more version of the doc thanks to #47
  There is a few issues with this approach:

1. Generic doc is duplicated two times
2. Options/Hotkeys doc is duplicated three times
3. main README.md is getting very long and hard to read

This should be improved, here is what we need to have:

1. Complete user documentation should be available in a gitlab markdown format from the main README.md
2. Complete user documentation should be available in the webdoc
3. Limit duplication as much as possible

Here is a proposition to fix that:

1. Put only the most esential and nice looking information in the main README.md
2. Link from the main README.md to other logically organized .md files in a dedicated directory (see below for an example organization)
3. Generate webdocumentation .md files during build thanks to cmake custom commands (see below for more info)
4. If adressing #47, generate simple html doc during build OR generate actual web doc during build
5. (Optional) Find a way to generate a .h from the options/hotkeys .md file during build so that it can be used in the --help output (and other usages?)
6. (Optional) Use Pandoc instead of help2man to generate man, relying on generated .md file during build (see expected format here: https://www.pragmaticlinux.com/2021/01/create-a-man-page-for-your-own-program-or-script-with-pandoc/)

Example .md file organization, that could also be used as a webdoc organisation:

- README.md
- doc
-- OPTIONS.md
-- HOTKEYS.md
-- INSTALATION.md
-- USAGE.md
-- BUILD.md (should this go into dev?)
-- CONFIGURATION_FILE.md
-- LIMITATIONS.md
-- TROUBLESHOOTING.md
-- dev
--- GENERATE_WEBDOC.md
--- GENERATE_COVERAGE.md
--- GENERATE_MAN.md
--- DEVELOP.md
- webdoc
...

Differences between README.md and webdoc md files:

• Image paths are differents (could be fixable):

+ ![F3D Logo](./resources/logo.svg) 
- ![F3D Logo](logo.png) 

+ <img src="https://kitware.github.io/F3D/gallery/04-f3d.png"  width="640">
- ![F3D Demo](../gallery/04-f3d.png)

• many nbsp in the webdoc (could be fixable?)

+ Options                         &|Description
- Options|Description                                                                                                                                     

• Internals links are removed (should be fixable)

+ See the coloring cycle section for more info.
- See the [coloring cycle](#Cycling Coloring) section for more info. 

If all slight change are removed, simply symlinking from the webdoc to the doc.md could be a very easy solution to put into place.

Linux package currently rely on GLIBC. If the Docker image we use for building the Linux package uses a newer version than the user one, the application refuses to run.

See https://gitlab.kitware.com/f3d/f3d/-/merge_requests/224#note_901968

Possible solutions:

• Static build using musl
• use an older version of GLIBC in the Docker image
• Hack for a specific GLIBC version (https://stackoverflow.com/a/2858996/2609654)
• Create a Flatpak package

The current version of the package uses Ubuntu 18.04, which we consider good enough and should support Debian 10 and Centos 8. Letting this happen in case there are older distribution user in need of a package.

Steps to reproduce :

• run F3D with default config
• open a dragon.vtu
• press p
• label move
• press p
• label move
• press p
• label do not move anymore

Improve bokeh blur shader performance.

This approach looks promising: https://www.shadertoy.com/view/Xd33Ds

info here: https://gitlab.kitware.com/f3d/f3d/-/issues/144

We are running out of short options and hotkeys, Let's plan how to tackle that.

A few possibilities:

• Introduce modifies: Ctrl, Alt, Shift
• Use vim like commands: :comp=2

@Meakk please review .github/docker/Dockerfile and .github/workflows/build_docker_image.yml

It was not possible to put them in a PR

--no-background does not work, either because of a VTK regression or an issue in our code.

It works in 1.0, but not in 1.1

Context
When drawing lines coincident with polygons, there could be z-fighting.
We are currently using the default polygon offset value of VTK but I suspect that there is an issue when computing depth range in VTK. Let's investigate.

Steps to reproduce

• download machined-sphere-inside-cube-1.snapshot.4.zip
• `./bin/f3d Ball-Cube.STEP

Notes

more info here: https://gitlab.kitware.com/f3d/f3d/-/issues/217

Context
F3D is used to show models of different sizes. It can be hard to judge the size of a model when opening it in F3D.
Adding a Grid around it as shown below would help with this evaluation:

The idea of this issue is to add a CLI and libf3d options to control the showing of such a grid.

Suggested solution
In vtkF3DRenderer, add a vtkGridAxes3DActor similarly to how the GridActor is added and add the method to control the showing of it. In window_impl::UpdateDynamicOptions() , control the showing of the new actor based on a new option that has to be added in the options.
Finally, in F3DOptionsParser, add a CLI option to control the libf3d options.

CLI Option: --axes-grid
libf3d option: render.axes-grid.enable

No interaction planned to control it as of yet.

Required skill

No required skill, this could be a good-first-issue with a bit more work.

Potentially more info here: https://gitlab.kitware.com/f3d/f3d/-/issues/81

Currently direct scalars is being set by using the comp option to -2.
Let see if we want to improve that

Context
F3D is using a simple light configuration that works for most usecases. F3D also supports loading lights from files directly for a file formats supports it. However, there is no way to configure lights manually yet.

The idea of this issue is to add libf3d options and F3D cli options to be able to configure lights

Suggested solution
Being able to add a single light and control its type, position, direction, angle and color would be beneficial.
This light would be added on top of the usual light kit already in use.

CLI options:

• --light-type
• --light-position
• --light-direction
• --light-angle
• --light-color

And corresponding libf3d options (render.additional.light.X)

Special care would be needed to ensure --light-intensity works with it as well.

Discussions needed before adding "help-wanted" label

• Should we support multiple lights ? How would that look in CLI ?
• Should the CLI options clarify that this is an additional light ?

The feature should be implemented in VTK.
Example file can be downloaded here

https://gitlab.kitware.com/f3d/f3d/-/issues/177

libf3d was introduced in !259 (closed), let's brainstorm a stable API for it.

Tasklist:

libf3d

• Introduce f3d::options: #191
• Refactor F3DLoader and F3D to use f3d::options cleanly
• Introduce f3d::loader and use it
• Introduce f3d::window and use it
• modularize VTK code
• Add unit test for VTK modules : #265
• sanity check call order with window and interactor
• transform F3DLog into f3d::log
• fix #32 by using categories for options
• improve f3d_options by providing initialization methods
• store init value in f3d::options for easier reset ?
• support std::initializer_list to be able to call options.set("color", { 1., 1., 1. });
• add a way to inform user when an options does not exist
• introduce a factory and use it to create classes to hide the private API
• Add SDK test infrastructure
• Adress as many TODOs as possible
• Rework engine for bit flag and init early
• Add SDK tests
• (optional) expand f3d_interactor to support user set behavior for many more context
• add more window types
• improve all classes from f3d namespaces to ensure all santiy checks are done correctly
• unit testing of the API and general coverage improvements
• Add a vtkNoRenderWindow
• modernization of API
• constness of API
• Public Review of the API to anyone willing to help: #351

F3D

• Rework F3DOptions and F3DOptionsParser to interface with f3d::options
• (Optional) introduce f3d::config in libf3d ?
• rewrite F3DStarter from scratch to not depends on VTK

Doc

• In header doc
• example doc
• website doc

In order to extend windows explorer:

• Thumbnails
• Add opening folder support from context menu
• Property tab (number of points/cells and dataset type)
• Allow multi-files opening from explorer (currently open several instances): #497
• Integrate as a quicklook viewer: #900
• Improve thumbnails: #797
• Add dark title bar support: #895
• Fix FileAssociation: f3d-app/f3d-superbuild#160

References:

• https://docs.microsoft.com/en-us/windows/win32/shell/shell-exts
• https://docs.microsoft.com/en-us/windows/win32/shell/building-thumbnail-providers
• https://github.com/microsoft/Windows-classic-samples/tree/master/Samples/Win7Samples/winui/shell/appshellintegration/RecipeThumbnailProvider

If an image is 2D, it can be useful to have a 2D interactor (I'm thinking of DXF or medical images).
And tbh, if we implement it, then it makes sense to supports JPG/PNG/TIFF/HDR/TGA/... too since it is basically free.
I know this is not the main purpose of f3d but since f3d is GPU accelerated, it may outperform other image previewers with large images.

• Linux fullscreen issue : Fullscreen break interaction

• f3d cow.vtp -f
• cannot interact with the camera

• Linux fullscreen issue : Starting in fullscreen and then pressing f will not create a window of the right size

• f3d cow.vtp -f
• press f
• window is 300*300
• press f again window disapear

• Linux fullscreen issue : Fullscreen with multiple screens cover both screens

• Linux fullscreen issue : Starting in fullscreen and then pressing Escape segfaults

./bin/f3d --fullscreen
pres Escape
Segfault

• Windows full screen issue :

• open f3d.exe without parameter
• type f -> fullscreen
• type f -> does not revert to original size but 300x300

• MacOS fullscreen issue

• f hotkey is not working

• All os FullScreen issue :

• f3d -f
• H -> FullScreen is not enable
• F -> stays in fullscreen

Context
F3D can display a progress bar when loading a file, however, F3D relies on the progress reporting done by the readers and importers. Some of readers and importers we use, either from F3D or VTK, do not report accurate progress or progress at all.

The idea os this issue is to investigate the status of the different importers and readers in regards to progress reporting, and improve the one that do a bad job of it. First in F3D and second in VTK directly.

Suggested solution

• Investigate each and every readers and importers in use and check that they perform progress reporting.
• For the one that don't, implement a simple progress reporting mechanism and merge it into F3D and VTK

Skills needed

• Knowing how to contribute to VTK is a plus

Notes

• OBJ importer does not have progress
• glTF importer does not have progress
• Other importers may not have progress either

We are currently building VTK and F3D using the static system library on Windows.
Should we add InstallRequiredSystemLibraries CMake module in order to support the shared system library?

See https://cmake.org/cmake/help/latest/module/InstallRequiredSystemLibraries.html

./bin/f3d -v ../data/vase_4comp.vti --comp=-2

vtkOpenGLVolumeLookupTa:84 WARN| vtkOpenGLVolumeOpacityTable (0x5575e3ea0b10): This OpenGL implementation does not support the required texture size of 131072, falling back to maximum allowed, 32768.This may cause an incorrect lookup table mapping.

The rendering seems fine.
Cycling to -2 does not create this warning for some reason.

Actual Behavior

If no argument is provided, a rendering window is created with nothing shown (gray background). It can be difficult to know if the program is working or freezing.

Expected Behavior

In case no argument is provided, we should expect that the program show a clear drop zone

Specifications

F3D - A fast and minimalist 3D viewer
Version: 1.1.0
Build date: 2021-04-07 11:48:28
System: Linux-5.8.0-48-generic x86_64
Compiler: GNU 10.2.0
RayTracing module: OFF
VTK version: 9.0.0 (build 20210406)
Author: Kitware SAS

eg :

f3d ./files/* --output=output.png

Could create output_0.png, output_1.png ...

Context
F3D supports many file formats, but they are many that F3D does not support, lets add supports for these formats!

Help wanted
Not an usual help wanted issue, but if you are familiar with any of these formats and want to add supports for it, please say so and we will create a dedicated issue with all needed information.

Formats

• .fbx : Must have #37

Formats to consider sorted by reddit upvotes:

• .usd 9: #780
• .3DXML 9
• .dae (collada) 7
• .x (directx) 7 : #1124
• Parasolid (.x_b, .x_t) 7
• ACIS (.sat) 7
• .blend 7: #1125
• .3mf 7: #1126
• .ma 4
• .jt 4
• .ipt/.iam 3
• .dwg 3
• .ifc 3
• Navisworks .nwd 2
• .dwx/.dwfx 2
• .ztl/.ztr 2
• vdb 2 : supported by VTK ! #181
• .skp 1
• .wire 1
• Revit formats RVT, RFA, RTE, RFT. 1
• e57. 1
• .ztl 1
• .pcd 1
• .las 1
• .brep 1 : #946
• point clouds: #201

more info here: https://gitlab.kitware.com/f3d/f3d/-/issues/99

New feature description

Please add support for the DXF/DWG file format.

Contribution

I'm afraid not. It seems that paraviewgeo is able to open dxf files, see http://paraviewgeo.objectivity.ca/documentation/user-manual/supported-formats

We should consider ways to add support for FBX file format

@michael.migliore

Found this:

• https://github.com/nem0/OpenFBX
• https://github.com/assimp/assimp
• Blender native support ?

Context
F3D is a tool that let user visualize 3D models easily. Having a mobile android version would be benificial for the project.
A simple idea would be able to support opening a file attached to an email. iOS version could be considered as well.

Current status
@Meakk has created a prototype of an android app that rely on the libf3d: https://github.com/f3d-app/f3d-android

Some non-exhaustive related tasks

• Migrate to Kotlin
• Improve zoom and pan interaction (it jitters, there must be something wrong)
• Create CI to generate one .apk per architecture
• Add an hamburger menu to toggle some options (e.g. grid)

The following discussion from !265 should be addressed:

• @jpouderoux started a discussion: (+3 comments)

  May be out of scope of this MR but quite related: it could be nice to generate a HTML file to be installed for Windows users.

https://gitlab.kitware.com/f3d/f3d/-/issues/235

Each community of users may want to have different default config file, especially regarding interaction style, up direction, coloring.

It would be nice to provide default config file for each of the basic usage of F3D, eg:

• 3D Printing
• Gamedev
• Animation
• Sciviz
• Medical

Ideally, for the NSIS windows installer, a dedicated screen would let the user choose the default config to install.

Since ffmpeg is included in VTK, we should be able to export animation in h264 or animated gif files.

Hello, I tried to package F3D as Flatpak and I want to submit to Flathub.
flathub/flathub#2282

I could build and run F3D without OSPRay just fine.
But since OSPRay is needed for ray tracing, I will try to add them.

Right now I have some problem with ISPC needed by OSPRay because it need glibc-32bit, which I have a bit of issue how to do it in flatpak.
flathub/org.freedesktop.Sdk.Extension.llvm11#10

** Context **
F3D is able to load many type of files. For full scene format, F3D relies on each individual importers to provide meta data information about the file. However, some importers are not great at providing such info.

To recover such info cleanly, we probably need #653

** Notes **
more info here: https://gitlab.kitware.com/f3d/f3d/-/issues/174

We need to do something smarter to avoid this problem.
One idea:

• Compute render time for opaque, translucent and volume pass
• Update the timer
• Render overlays

Another idea:

• Use a different renderer for geometry and overlays

more info https://gitlab.kitware.com/f3d/f3d/-/issues/212

Run f3d and load (ノಠ益ಠ )ノ.vtp file. Press 'N' to display the file name. It prints (1/1) ( ).vtp.

https://gitlab.kitware.com/f3d/f3d/-/issues/232

• Add color to quickly see which option is enabled
• Using bold for changed options
• Using color "flash" when changing the option.

Release packages do not contain OSPRay, this requires creating some sort of a superbuild.

• Create https://github.com/f3d-app/f3d-superbuild
• Create a first version that builds VTK + F3D f3d-app/f3d-superbuild#1
• Add optional modules f3d-app/f3d-superbuild#1
• Add a simple CI f3d-app/f3d-superbuild#2
• Use window-latest: f3d-app/f3d-superbuild#4
• Add packaging f3d-app/f3d-superbuild#6
• Add packaging macos: f3d-app/f3d-superbuild#9
• Adding testing: f3d-app/f3d-superbuild#8
• Add source selection for VTK: f3d-app/f3d-superbuild#7
• Add source selection for F3D: f3d-app/f3d-superbuild#7
• Add cross platform CI that generate downloadable binary release out of it: f3d-app/f3d-superbuild#6
• Check every project for option we may not need : f3d-app/f3d-superbuild#12
• Avoid using LFS wherever possible: issue opened
• Include fixes from pvsb: f3d-app/f3d-superbuild#15
• Last fixes: Better packaging, remove useless projects: f3d-app/f3d-superbuild#17
• Enable tbb in VTK: f3d-app/f3d-superbuild#22
• Add a release workflow: f3d-app/f3d-superbuild#16
• Tag 1.3.1 !
• Make fsb work with f3d master: f3d-app/f3d-superbuild#25
• Add a nightly: f3d-app/f3d-superbuild#27
• Use scache
• Publish release with an option
• Rework CI by using matrix config if possible
• Add extensive doc on sb
• Clean fsb repo
• Focus F3D CI on testing instead of binary release
• Consider adding caching
• Move docker logic to another repo: f3d-app/f3d-docker-images#2
• Improve common sb chrpath : issue opened on common sb: https://gitlab.kitware.com/paraview/paraview-superbuild/-/issues/236
• #588

This thread is meant to discuss code improvements. It can be edited by everyone.

Use sub-folders

Architecture may be improve by splitting files in folders:

• Core
• Data
• Filters
• Rendering
• Interactors
• Options
• ...
  please, edit this list, I am not the best fit to fill it.

Use namespaces

• create new namespaces for
  • f3d
  • exceptions f3d::except?
  • subfolders (see thread: f3d::filter, f3d::data, ... may be too verbose.)
• change the clang-format to avoid re-indenting everything (see NamespaceIndentation)

Add CMake Preset for build / testing

• build
  • minimal (the lightest version)
  • ray-tracing
  • testing

Class splitting/reorganization

...

Misc

• enforce C++ 11 in clang-format and CMake
  • switch to C++ 14 ?
• use #pragma once

more info here: https://gitlab.kitware.com/f3d/f3d/-/issues/173

When using a HDRI, spherical harmonics and specular textures are computed.
The result should be cached on disk to improve performance.

more info here: https://gitlab.kitware.com/f3d/f3d/-/issues/168

Steps to reproduce

• ./bin/f3d AnimatedBog.gltf
• zoom out
• press space
• move the scene while animation is running
• animation is not smooth

Context
F3D is able to show data using a colormap. Such a colormap has a range. This range is initialized using the min and max value of the data at the first time step. This works in most cases but in same cases, this would lead to unreadable results.

A workaround to this is of course to specify the colormap manually, however, F3D could have a better behavior.

** Suggested Solution**
F3D should expand the colormap on each timestep so that when the animation has been played fully, the colormap will not change anymore and further play through the animation will not make the color map evolve.

To implement this, one would need to ensure that changing the timestep in animationManager turn a flag on in vtkF3DRendererWithColoring so that it knows that the colormap should be expanded, and take that information into account in vtkF3DRendererWithColoring::ConfigureRangeAndCTFForColoring .

Context:
F3D has many different rendering mode, surface, volume, point sprites.
The idea of this issue is to add yet another rendering mode using VTK provided tools in order to represent the normals as glyphs on top of the surface.

Suggested solution:

• Add a command line option to enable this : --normal-glyphs
• Add a libf3d options to enabled this: normal-glyphs
• Add an interaction key to enable this: Shift + N
• Implement the feature itself in vtkF3DRendererWithColoring by adding a vtkGlyph3D filter
• Configure the vtkGlyph3D with a normal orientation

Possible pain point:

• Nothing

Discussions needed before adding "help-wanted" label:

• is CPU the right choice here ? It may be simpler to implement but a GPU based solution may be faster

CAD formats has been introduced by !236
Visual quality highly depends on the meshing parameters.
Currently, these parameters are hard-coded with a trade-off between loading speed and visual quality.
Moreover, it is standard for CAD visualizer to display surfaces boundaries (curves discretized with poly-lines) but sometimes we do not want it.

How to handle these CAD specific options?

We can already write the color buffer in a PNG image.
We should be able to write the depth buffer too.
I can easily imagine cases where you want to use f3d in a script to generate color and depth images and composite several images using the depth buffers.

Implementation details:

• Add a new F3D and libf3d option to enable depth rendering
• Handle this use case by modifying the shader in the function vtkF3DPolyDataMapper::ReplaceShaderLight

For now, just writing the normalized depth in the shader as a greyscale value (something like gl_FragData[0] = vec4(vec3(gl_FragDepth), 1.0);) should be enough, but we could also consider doing color mapping like the image below: