feat: use a model exported from blender (1 of 3)

[tsawyer999]

Description

The goal was to use a model outside of bevy community show case with texture, animation and transparency.

• Remove previous 3d models
• Bought a model on bitgem
• Convert the model from fbx to gltf format with blender
• Render the converted model in bevy

How to test

• execute cargo run
• model should load as the printscreen

Technical discussion

• How should we manage our 3d asset? It would be cool that we could include .blend files with textures but this create an heavy load on the git repository.

Notes

Future

• This model should be animated: moving, attacking, dying, etc. Bevy community created a PR with 3d model animation. Feeling this PR will be merged around September 2022. This give us the opportunity to focus on other features like networking;
• The transparency is heavy in F3d, this means there is no issue in bevy but some tweaks are needed when exporting to gltf;

In blender

• Move textures files in the save folder of the fbx file
• Import the fbx file
• export the scene as tfgl2 format

In F3d

• Install F3d
• validate the exported model with /usr/bin/flatpak run --branch=stable --arch=x86_64 --command=f3d --file-forwarding com.kitware.F3D bat.gltf

Printscreens

Bevy

F3d

[tomkcey]

build failed
error: failed to run custom build command for `alsa-sys v0.3.1`

Caused by:
  process didn't exit successfully: `/home/tomkcey/Documents/dev/perso/rust-project/frontend/target/rls/debug/build/alsa-sys-f129900ea7d7b18c/build-script-build` (exit code: 101)
  --- stdout
  cargo:rerun-if-env-changed=ALSA_NO_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG
  cargo:rerun-if-env-changed=ALSA_STATIC
  cargo:rerun-if-env-changed=ALSA_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_STATIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR

  --- stderr
  thread 'main' panicked at 'Pkg-config failed - usually this is because alsa development headers are not installed.

  For Fedora users:
  # dnf install alsa-lib-devel

  For Debian/Ubuntu users:
  # apt-get install libasound2-dev

  pkg_config details:
  `"pkg-config" "--libs" "--cflags" "alsa"` did not exit successfully: exit code: 1
  --- stderr
  Package alsa was not found in the pkg-config search path.
  Perhaps you should add the directory containing `alsa.pc'
  to the PKG_CONFIG_PATH environment variable
  No package 'alsa' found
  ', /home/tomkcey/.cargo/registry/src/git.luolix.top-1ecc6299db9ec823/alsa-sys-0.3.1/build.rs:6:50
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

[tomkcey]

build failed
error: failed to run custom build command for `alsa-sys v0.3.1`

Caused by:
  process didn't exit successfully: `/home/tomkcey/Documents/dev/perso/rust-project/frontend/target/rls/debug/build/alsa-sys-f129900ea7d7b18c/build-script-build` (exit code: 101)
  --- stdout
  cargo:rerun-if-env-changed=ALSA_NO_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG
  cargo:rerun-if-env-changed=ALSA_STATIC
  cargo:rerun-if-env-changed=ALSA_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_STATIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR

  --- stderr
  thread 'main' panicked at 'Pkg-config failed - usually this is because alsa development headers are not installed.

  For Fedora users:
  # dnf install alsa-lib-devel

  For Debian/Ubuntu users:
  # apt-get install libasound2-dev

  pkg_config details:
  `"pkg-config" "--libs" "--cflags" "alsa"` did not exit successfully: exit code: 1
  --- stderr
  Package alsa was not found in the pkg-config search path.
  Perhaps you should add the directory containing `alsa.pc'
  to the PKG_CONFIG_PATH environment variable
  No package 'alsa' found
  ', /home/tomkcey/.cargo/registry/src/git.luolix.top-1ecc6299db9ec823/alsa-sys-0.3.1/build.rs:6:50
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

J'avais mi ça car j'avais des problèmes de dépendences sur mon Linux, ce qui est très dommage, mais en gros il faut pouvoir installer les dépendences libudev-dev et libasound2. Il y en a peut-etre une autre que j'oublie.

Maintenant, tout est beau.

[tomkcey]

A way I think we should handle loading assets is through an initial remote call to a server that would stream back the requested assets. That would mean we need to host the backend on a server and have it communicate with a S3 Bucket, for example, where we could dump our assets.

Initially this could be done via HTTP and later be moved to a websocket. Optimization could be done client-side to cache the assets so the server doesn't have to send them back. An initial idea would be to have triggers on the S3 bucket sending a new/modified file to a message queue which would handle a configuration where all asset versions would be listed. Upon first connecting to the server the client fetches that configuration and if request is done for a ressource that is already cached on client system then forgo calling the backend and simply use the cached resource.

It's sounds complicated because it's step-sensitive and there's alot of coming-and-going but it seems fairly robust to increase performance.

Caching the dependencies on client side is an entirely other discussion because if we're using the browser where do we store? Local storage? Session storage? How big is the space in those stores? Can data be lost? All these fancy considerations...