Maxime Boguta
Développeur Python / Django en temps partiel
informatique
developpement
polyvalent
33 ans
Permis de conduire
Toulouse (31190) France
Situation professionnelle
Etudiant
En recherche active
Présentation
Dors et déjà titulaire d'un DUT en Techniques de Commercialisation et développant actuellement des compétences visant à la maîtrise des outils du numérique, ma vision élargie du développement de produits issus de l'industrie logicielle font de moi un élément polyvalent et à la forte adaptabilité. Aujourd'hui étudiant motivé de 5ème année à EPITECH et fort de plusieurs expériences variées, je suis capable d'innovation et de réflexion, pour ensuite déployer une force de développement conséquente.
Maîtrisant actuellement les langages C, C++ et Python ainsi les systèmes UNIX, réseaux et technologies web, ma force d'adaptation et ma curiosité me permettent d'apprendre et d'être opérationnel rapidement. Mon expertise technologique se situe dans le développement web backend (Django python / REST API, webapps) ainsi que dans la programmation système (C/C++,embarqué haut niveau) et mobile hybride (Ionic / React).
Maîtrisant actuellement les langages C, C++ et Python ainsi les systèmes UNIX, réseaux et technologies web, ma force d'adaptation et ma curiosité me permettent d'apprendre et d'être opérationnel rapidement. Mon expertise technologique se situe dans le développement web backend (Django python / REST API, webapps) ainsi que dans la programmation système (C/C++,embarqué haut niveau) et mobile hybride (Ionic / React).
Développement d'un programme de lancer de rayons en 3D dans le cadre de ma formation au cours de 3 mois de travail et à la tête d'une équipe de 8 personnes. Projet qui fut très bien reçu lors de la soutenance finale.
Principe du raytracer :
À partir d'une scène précedemment décrite comportant objets, lumières, et point d'observation, un "rayon" sera lancé à partir de ce point pour chaque pixel de l'image, à l'inverse de la relation oeil - environnement classique. Ce rayon touchera, ou pas, un objet présent. Pour savoir si c'est le cas, il est nécéssaire de calculer les résultats d'une intersection entre ce rayon et tous les objets présents dans la scène. S'il n'y a pas d'intersection, le rayon part dans le vide, et le pixel est noir (absence de couleur). Dans le cas contraire, selon le point d'intersection sur l'objet par raport à son type (sa forme), la normale en se point permettra de determiner l'éclairage à cet endroit. Interviennent alors d'autre facteurs, tels que la reflexion ou l'ombrage, qui nécessitent un autre lancer de rayon en changeant de point de vue (le point d'intersection) et se dirigeant vers l'objet reflété pour la reflexion, vers la lumière pour l'ombre. Les calculs d'intersection sont effectués pour savoir s'il y a réflexion ou si le point est ombragé (plus sombre par rapport à la couleur initiale de l'objet). Si l'éclairage est plein et le point d'intersection non ombragé, le pixel aura la pleine couleur de l'objet. Un calcul initial est donc nécessaire pour chaque lumière présente dans la scène, en vue de moyenner la couleur du pixel calculé.
Cahier des charges :
Programme affichant dans une fenêtre X une scène décrite par des objets de types et composantes différents (couleur, position, rotation), éclairés par des lumières (spots) de spécificités différentes (intensité, brillance), et vue depuis une caméra de position et rotation propre.
Compétences et difficultés:
Gestion d'un large groupe (8 personnes).
Modélisation mathématique avancée (équations de 4ème degré, vecteurs et matrices).
Algortithmie et gestion des ressources système (calculs demandant beaucoup de ressources, architecture threadée pixel par pixel).
Maitrise du langage C et du serveur X.
Comment s'est divisé le projet :
Lexing parsing d'un fichier de scène, décrivant cette dernière.
Module calculatoire effectuant les opérations visant à définir la couleur de chaque pixel de l'image finale à partir de ladite scène.
Affichage par initialisation d'une fenêtre via le serveur X et par insertion (blit) de l'image.
Ce qui à été fait :
Partie obligatoire décrite ci-dessus.
Architecture de calcul threadée (répartie sur plusieurs coeurs de calcul du processeur).
Possibilité de calcul en cluster (calcul déportée sur des machines distantes par réseau local ou internet).
Lexeur parseur sous forme de XML pour des fichiers de configuration de scènes diversifiés et confortables de création.
Texturing des objets.
Objets exotiques (cube troué, torus).
Options de développement (diminution des calculs, output en formant BMP).
Antialiasing par supersampling (très chronophage en terme de calculs).
Softshadowing (définition des lumières comme des volumes et non plus comme des simple points, permettant l'adoucissement des ombres).
Réflexion des objets.
Principe du raytracer :
À partir d'une scène précedemment décrite comportant objets, lumières, et point d'observation, un "rayon" sera lancé à partir de ce point pour chaque pixel de l'image, à l'inverse de la relation oeil - environnement classique. Ce rayon touchera, ou pas, un objet présent. Pour savoir si c'est le cas, il est nécéssaire de calculer les résultats d'une intersection entre ce rayon et tous les objets présents dans la scène. S'il n'y a pas d'intersection, le rayon part dans le vide, et le pixel est noir (absence de couleur). Dans le cas contraire, selon le point d'intersection sur l'objet par raport à son type (sa forme), la normale en se point permettra de determiner l'éclairage à cet endroit. Interviennent alors d'autre facteurs, tels que la reflexion ou l'ombrage, qui nécessitent un autre lancer de rayon en changeant de point de vue (le point d'intersection) et se dirigeant vers l'objet reflété pour la reflexion, vers la lumière pour l'ombre. Les calculs d'intersection sont effectués pour savoir s'il y a réflexion ou si le point est ombragé (plus sombre par rapport à la couleur initiale de l'objet). Si l'éclairage est plein et le point d'intersection non ombragé, le pixel aura la pleine couleur de l'objet. Un calcul initial est donc nécessaire pour chaque lumière présente dans la scène, en vue de moyenner la couleur du pixel calculé.
Cahier des charges :
Programme affichant dans une fenêtre X une scène décrite par des objets de types et composantes différents (couleur, position, rotation), éclairés par des lumières (spots) de spécificités différentes (intensité, brillance), et vue depuis une caméra de position et rotation propre.
Compétences et difficultés:
Gestion d'un large groupe (8 personnes).
Modélisation mathématique avancée (équations de 4ème degré, vecteurs et matrices).
Algortithmie et gestion des ressources système (calculs demandant beaucoup de ressources, architecture threadée pixel par pixel).
Maitrise du langage C et du serveur X.
Comment s'est divisé le projet :
Lexing parsing d'un fichier de scène, décrivant cette dernière.
Module calculatoire effectuant les opérations visant à définir la couleur de chaque pixel de l'image finale à partir de ladite scène.
Affichage par initialisation d'une fenêtre via le serveur X et par insertion (blit) de l'image.
Ce qui à été fait :
Partie obligatoire décrite ci-dessus.
Architecture de calcul threadée (répartie sur plusieurs coeurs de calcul du processeur).
Possibilité de calcul en cluster (calcul déportée sur des machines distantes par réseau local ou internet).
Lexeur parseur sous forme de XML pour des fichiers de configuration de scènes diversifiés et confortables de création.
Texturing des objets.
Objets exotiques (cube troué, torus).
Options de développement (diminution des calculs, output en formant BMP).
Antialiasing par supersampling (très chronophage en terme de calculs).
Softshadowing (définition des lumières comme des volumes et non plus comme des simple points, permettant l'adoucissement des ombres).
Réflexion des objets.
Date de création
08 juin 2014
