Category Archives: Programming

Sujet de bureau d’étude LFlex

Amélioration du moteur de rendu Radium

L’objectif de ce bureau d’étude est d’améliorer la gestion des caméras virtuelles et du rendu volumique dans le moteur de rendu open source Radium-Engine. Le développement se fera en c++/OpenGL et utilisera les outils de gestion de projet git via github.

Encadrement

David Vanderhaeghe vdh@irit.fr

François Gaits francois.gaits@irit.fr

Description du context

Radium-Engine est un moteur de rendu 3D orienté pour la recherche en informatique graphique. Il est développé et maintenu par l’équipe de recherche STORM. Ce moteur de rendu a de nombreuses applications, de la visualisation de modèles 3D à l’animation, mais surtout l’exploration et le développement de nouvelles méthodes de synthèse d’images.

Dans le cadre de ce bureau d’étude, vous serez amené à vous familiariser avec Radium Engine, son architecture et ses concepts, implémenter de nouvelles fonctionnalités correspondant à des besoins utilisateurs et finalement proposer une démo basée sur ces nouvelles fonctionnalités.

Radium est entièrement écrit en C++ et propose une abstraction haut niveau de l’API graphique OpenGL. Un premier travail d’apprentissage de l’environnement de développement peut être à prévoir, comprenant la compilation, l’utilisation du C++ et les concepts rendu classique.

Ce bureau d’étude s’axe principalement autour de deux thématiques : la gestion de la caméra et le rendu volumique

Gestion de la caméra

L’objectif est de fournir de nouveau outils comme la création de chemins de caméras permettant de créer des vidéos ou l’implémentation de nouveau types de caméras. Il sera sans doute nécessaire de modifier l’architecture du programme concernant ses caméras, mais surtout d’inventorier les caméras existantes.

Rendu volumique

les volumes 3D représentent une grande quantité d’information et sont très utilisés notamment en imagerie médicale, plusieurs techniques existent pour les visualiser (MIP, marching cubes, slicing…).Cette thématique a donc pour but de créer de nouvelles visualisations de volumes au sein de Radium, mais aussi d’étudier les mécanismes d’import et d’export de volumes présents. Cette thématique a donc pour but de créer de nouvelles visualisations de volumes au sein de Radium, mais aussi d’étudier les mécanismes d’import et d’export de volumes présents.

Radium fournit aussi la possibilité de créer des démos mettant en avant ses fonctionnalités. La finalité de ce BE est donc de créer une démo du travail effectué.

Cadre de travail

Le sujet est pensé pour une équipe de 4 à 12 étudiant.e.s. Les objectifs seront modulés en fonction de la taille de l’équipe.

Radium Engine utilise cmake comme gestion de la compilation.

Radium Engine est multi plateforme, l’environnement de développent est laissé libre pour chaque participants.

Le code devra être déposé sur github, et l’intégration éventuelle des résultats passera par le système de pull request de github. De plus le code devra respecter les règles de conduite du projet, en terme de qualité, tests unitaires, nommage des différents composants.

Nous accompagnerons la montée en compétences en c++, OpenGL, l’utilisation de git et github.

David Vanderhaeghe est membre de l’équipe STORM de l’IRIT.

François Gaits est membre des équipes STORM et MINDS de l’IRIT

Magic rebase and (re-) format

If you like clean coherent formatted code, you may already use something like clang-format and git hook to ensure format when commit

If you like clean history, you might use a lot of rebase.

Sometimes during conflit, format is lost, but it’s pita to fix it afterwards without introducing some commit out of the clean history

Update 2022-05-10

I have switch to pre-commit.ci to perform pre-commit hook and formating, applying the same principle, I run

git rebase --strategy-option=theirs -x 'git reset --soft HEAD~1 && \
git commit -C HEAD@{1}' origin/master 

Which reset and reapply commits, hence triggering pre-commit hook. Then conflict resolution is nearly the same, I use the following oneliner to fix all possible conflicts

git add -u && git commit -C HEAD@{1} && \
git rebase --continue          

Older version

I use run-clang-format script with rebase and exec. This will stop rebase if format is not respected

git rebase --exec "./run-clang-format.py -r -i \
--style file --extensions inl,cpp,hpp src/" \
new-base-branch

When it stops, you can examine the situation with

git status
git diff

Once everything looks good (in case of conflict, simply use remote, and reformat)

git add -u && \
git commit -m"fix format" && \
git rebase --continue

Then rebase -i again so you can squash/fix all “fix format” commits with their immediate ancestor.

TODO : explain a bit more

libGL.so compil problem

From time to time, on my ubuntu 11.10, i have link error like “undefined reference to glGetQueryObjectui64v”.
This is because an unidentify package update break libGL.so symlink in
/usr/lib or /usr/lib/x86_64-linux-gnu

The best solution I found is to manually
“sudo rm libGL.so libGL.so.1”
and to “ln -s nvidia-current/libGL.so .” in usr/lib
and “ln -s ../libGL.so .” in /usr/lib/x86_64-linux-gnu
and so on with libGL.so.1 if needed ..

Release and Debug with Cmake and QtCreator

I have used qmake for a while and the debug_and_release facilities to have both debug and release version of my code (with different executable, different build tress …)
Now I use cmake and qtcreator on a regular basis, to obtain the same behavior I have found the following approach :

in my CMakeLists.txtm something like

if(CMAKE_BUILD_TYPE STREQUAL "Debug")
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_SOURCE_DIR}/lib-debug)
set(LIB_INSTALL_DIR ${CMAKE_SOURCE_DIR}/lib-debug)
set(EXECUTABLE_OUTPUT_PATH ${CMAKE_SOURCE_DIR}/bin-dbg)
else()
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_SOURCE_DIR}/lib)
set(LIB_INSTALL_DIR ${CMAKE_SOURCE_DIR}/lib)
set(EXECUTABLE_OUTPUT_PATH ${CMAKE_SOURCE_DIR}/bin)
endif()

in QtCreator :
First time you open a CMakeLists.txt, simply choose a build dir (some thing like XXX/qtcreator-build) and run cmake,
then go to Tab projects->edit build configuration -> add -> clone selected
Chage build dir (something like XXX/qtcreator-build-dbg) and click “Run cmake”
In the Arguments edit line enter -DCMAKE_BUILD_TYPE=Debug
You can check that in run settings, working directory has changed to the new bin-dbg directory …