Ton projet à l'air vraiment intéressant! Juste quelques questions:
De ce que j'ai compris, ton moteur graphique est sensé être portable sur tout. Mais il utilise la technologie OpenGL. Donc, ton moteur graphique a-t-il besoin qu'OpenGL soit déjà installer dans le système d'exploitation (ce qui peut mener à des problèmes de compatibilité) ou bien OpenGL est-il implémenter directement dans ton moteur graphique, lui permettant d'être "autonome" du système d'exploitation?
Quelle serait pour toi la charge de travail pour porter ton moteur graphique sur d'autres OS alternatifs comme les quatres BSD (Free-, Open-, Net- et DragonFly,-), AmigaOS 4.1, MorphOS, AROS, Syllable, Haiku, Plan 9, Minix ou encore FreeDOS?
Après, il serait peut-être intéressant à moyen terme d'intégrer ton moteur graphique à une technologie comme Nex.
Cela permettrait des créer des applications réseaux qui tireraient profit de la puissance de serveur web ou d'une multitude d'appareils inactifs connectés au réseau pour effectuer des tâches lourdes en terme de calculs (simulation par exemple).
Ton moteur graphique serait ainsi un concurrent intéressant au WebGL, qui s'utilise via le javascript.
En tout cas, je te dis bravo pour tout le travail accompli et te souhaite bonne chance pour la suite.
Bonne soirée.
Projet: cours "Histoire des OS" (titre provisoire). Stade: annulé
De ce que j'ai compris, ton moteur graphique est sensé être portable sur tout. Mais il utilise la technologie OpenGL. Donc, ton moteur graphique a-t-il besoin qu'OpenGL soit déjà installer dans le système d'exploitation (ce qui peut mener à des problèmes de compatibilité) ou bien OpenGL est-il implémenter directement dans ton moteur graphique, lui permettant d'être "autonome" du système d'exploitation?
Quelle serait pour toi la charge de travail pour porter ton moteur graphique sur d'autres OS alternatifs comme les quatres BSD (Free-, Open-, Net- et DragonFly,-), AmigaOS 4.1, MorphOS, AROS, Syllable, Haiku, Plan 9, Minix ou encore FreeDOS?
Il utilise OpenGL en option, car le plus gros du travail à été de créer un rendu graphique CPU donc en jouant avec des tableaux de pixels. Si j’intègre OpenGL c'est principalement une question de performance pour des jeux, même si mes algorithmes sont relativement bien optimisés. Il ne nécessite donc pas OpenGL, mais ne le remplace pas non plus, car je n'interface pas la carte graphique. Pour les OS que tu présente il serait en effet possible d'y inclure le moteur assez facilement tant qu'il prend en charge un compilateur C++. Mon principe d'affichage est très modulaire, le moteur retourne un tableau de pixel et il suffit de trouver un moyen de l'afficher à l'écran selon l'OS.
colorguest a écrit:
Après, il serait peut-être intéressant à moyen terme d'intégrer ton moteur graphique à une technologie comme Nex.
Ton moteur graphique serait ainsi un concurrent intéressant au WebGL, qui s'utilise via le javascript.
J'ai un peu de mal à comprendre ce qu'est Nex, mais il sera difficile de pouvoir remplacer WebGL, car pour pouvoir utiliser mon moteur dans une page Web, il faudrait au préalable télécharger un plugin un peu comme Unity. WebGL est un standard directement inclue dans les navigateurs. Par contre, il sera probablement possible d'exporter le C++ vers WebGL, au final je m'en servirais au lieu de le remplacer.
GZE, un moteur multiplateforme, adapté pour de la 2D, 3D et création de logiciels.
Je pense que le but du projet est de faire du rendu à la fois par CPU et si besoin par GPU mais pas sur navigateur.
Pour distinguer les deux, on va prendre le format SVG par exemple (format d'image animées vectoriel ) qui est supporté par tous les naviguateurs modernes, ce format utilise un rendu uniquement par CPU.
Le CPU n'étant pas idéal pour le rendu, l'utilisation du SVG pour des animations complexes donnera des animations saccadées et très lentes.
Le WebGL se propose comme solution pour les navigateurs, il passe donc par l'appel direct au GPU.
C'est une API javascript qui permet d'envoyer des instructions à la carte graphique pour faire du rendu et donc là on peut faire un rendu d'excellente qualité sans avoir de lag.
Ce projet ne vise pour l'instant pas les navigateurs, il se propose comme solution de fenêtrage et de rendu (à l'instar de la SDL, SFML, Allegro, GLFW) mais avec des caractéristiques qui lui donnent son originalité :
1/ Deux possibilités de rendu : Par CPU et GPU
C'est n'est pas juste un rendu GPU avec une API comme OpenGL.
Il est ainsi possible de faire du rendu avec CPU sur des microcontrôlleurs par exemple.
Mais il est aussi possible de faire une partie des calculs sur CPU et envoyer le résultat au GPU avec OpenGL pour plus de calculs avec un glMapBufferRange par exemple.
Ceci permet dans certains cas d'alléger le travail du GPU si on a un CPU qui ne fait pas grand chose.
C'est très utile par exemple dans le domaine des simulations en physique.
2/De plus cette librarie permet de faire du fenêtrage crossplatform(windows, mac, linux) et bientôt sur Android et les autres plateformes mobiles.
3/Elle supporte la transparence, donc possibilité de faire des splashs screens de qualité sur toutes les plateformes sans avoir affaire à un rectangle avec fond opaque tout le temps.
4/Très facile à utiliser configurer dans un projet puisque elle ne nécessite que des headers.
Donc pour tout ce qui est rendu, cette bibliothèque est juste géniale.
Enfin c'est ce que j'ai compris, l'auteur te donneras certainement plus d'informations.
Merci, ça résume très bien ce que je tente de faire
En fait les 2 types de rendu catégorise 2 grand type de projet, ceux qui veulent faire des applications, dont le plus souvent ont un affichage qui change peu, dorme et laisse du temps aux autres tâches, puis les jeux qui ont besoins de beaucoup de traitement graphiques qui préconise le GPU.
Pour le GPU, j'ai trouvé le moyen de faire du rendu optimal pour un grand nombre de sprites, je dessine tout en "Batching", le principe est de tout envoyer en une fois au GPU avec des instances qui ont des paramètres différents. Puisque on ne peut pas "Binder" ou changer d'image source pour les différents sprites dans le Shader, j'utilise un TexureArray pour faire un Atlas sur plusieurs layers. Sinon la méthode traditionnel consiste à envoyé les données au GPU, qui ensuite dessine le sprite, en même temps le CPU attend la fin du dessin, ensuite il envoie le second etc. Ce qui cause un grand ralentissement à la fois CPU et GPU.
Ici je tombe sur un os, OpenGL ES 2.0 et WebGL ne supporte pas les instances et les tableaux de textures. Donc pour le moment je me concentre sur OpenGL ES 3.0 et WebGL 2.0. Il ne sera pas impossible de faire un rendu traditionnel éventuellement, par contre les performances ne seront pas optimales. Et puis, je me demande si ça en vaut la peine, d'ici 2 ans ES2 et WebGL 1 n'existera pratiquement plus.
invalidip a écrit:
4/Très facile à utiliser configurer dans un projet puisque elle ne nécessite que des headers.
C'est presque ça, tout inclure dans des headers ne serait pas une bonne idée car chaque .cpp qui l'inclurait serait très long à compiler. C'est plus comme un framework, ou bien comme si vous seriez 2 à travailler sur un projet, chacun fait leur fichier .cpp et .h de leur coté. Il y a quand même un petit défaut à ça, si vous voulez tout recompiler votre projet, ça recompile la librairie entière ce qui prend un peu plus de temps à absolument tout recompiler. En réalité c'est plus l'IDE qui est mal fait et qui ne permet pas de recompiler par section. La solution serait de se créer une petite commande qui efface seulement les fichier .o de votre projet et pas ceux de la librairie, je vais inclue cette commande à Code::Blocks.
invalidip a écrit:
Mais il est aussi possible de faire une partie des calculs sur CPU et envoyer le résultat au GPU avec OpenGL pour plus de calculs avec un glMapBufferRange par exemple.
Ceci permet dans certains cas d'alléger le travail du GPU si on a un CPU qui ne fait pas grand chose.
Oui exactement, mais bon nos GPU sont quand même vachement puissant, ça serait plus pour de petits traitement spécial, par exemple le texte, je crée tout les caractères dans un buffer avant de l'envoyé au GPU.
Ryglen a écrit:
Pourquoi ne pas utiliser le webGL?
Oui, il est possible d'exporter du C++ en opcode pour faire du WebGL. Je n'ai pas tester cette méthode, mais ça a de bonnes chances de fonctionner.
Un autre problème sur lequel je travaille en ce moment est que le framerate n'est jamais égale, dépendamment de l'écran ou du périphérique. Donc je change tout le système de positionnement, contre un système d’interpolation des coordonnées, lors d'un déplacement de celui-ci selon le temps. Aussi, je permet la possibilité d'avoir du easing In/Out, donc de vite à lent et de lent à rapide.
J'ai aussi commencé le module audio, j'arrive à faire jouer des OGG, le tout prend moins de 2 secondes à compiler.
Il faudra aussi que je fasse une meilleurs création de mon tableau d'Atlas car pour le moment chaque sprite prend un layer entier, le but est de mettre le plus grand nombre de sprites par layer. Les layers doivent avoir tous la même dimension, donc je prend la plus grande supporter ou du moins un minimum de 1024x1024. De plus le nombre de layer est non modifiable, il faut donc prévoir le bon nombre de layer et si ne n'est pas suffisant un faudrait les copier vers un nouveau tableau. Il faudrait aussi pouvoir updater l'image source des sprites ou bien en ajouté/supprimé. Tous ça devient très complexe.
De l'aide ne serait pas de trop.
- Edité par Maeiky 12 novembre 2014 à 16:16:53
GZE, un moteur multiplateforme, adapté pour de la 2D, 3D et création de logiciels.
Je ne sais pas si tu as vu la derniere conférence GDC, ça tente d'approcher le zero overhead des drivers avec OpenGL : gdcvault.com/play/1020791/
Le 2ème intervenant dit qu'il vaut mieux utiliser des Texture Arrays sauf si on passe par les Bindless Textures, Le 3ème intervenant Graham Sellers parle de Bindless Textures, je n'ai pas tout suivi mais je pense que ça devrait grandement t'aider.
Sinon j'étais entrain de voir que récemment Microsoft sont entrain de changer GDI pour Direct2D pour les versions Windows 8, peut être qu'il va falloir adapter le code en conséquence, enfin je dis ça, j'y ai jamais touché...:p
Salut, j'ai regardé la vidéo qui est très intéressante. Ils montrent les nouvelles approches pour évité l'overhead, sauf que la plupart de ces approches demande les dernière version d'OpenGL ou bien des extensions. Je veux être moindrement portable, donc les fonction doivent être supporté par OpenGL ES 3.0.
Le Bindless Textures et l'indirectdraw sont des fonction très tentante, mais elle ne sont supporté que par ES 3.1, c'est un choix difficile, mais il n'y a trop peu de chose supportant ES 3.1 aujourd'hui et je crois même que ça requière OpenGL 4.0 pour le PC. Donc je vais rester avec mon tableau de texture, qui est un peu plus difficile à manipuler mais sera très efficace.
Il ne parle pas vraiment des appels par instances, mais je crois que ça revient un peu au même entre un appel par instance et plusieurs par indirects.
Pour GDI, normalement les futurs versions de Windows sont "Backward compatible", mais tu me fais pensé que je n'ai pas testé sur Windows8. Dans le pire des cas, je n'utilise que 2 fonctions GDI
Je suis en train de tout restructuré la partie graphiques du projet pour êvité le plus de calcul CPU, surtout si le rendu est par GPU. J'ai hâte d'avoir fini cette partie délicate
GZE, un moteur multiplateforme, adapté pour de la 2D, 3D et création de logiciels.
Bon, puisque j’hésitais grandement entre une méthode par instance disponible seulement sur OpenGL ES 3.0 avec la complexité de construire un Atlas et la méthode naïve avec un peu plus d'overhead qui pourrait fonctionner sur ES 2.0. Je crois bien que je vais suivre la méthode simple avec ces principes :
YAGNI : You ain't gonna need it => pas la peine de programmer des fonctionnalités dont tu n'auras pas besoin. KISS : Keep it Simple, Stupid !
Ensuite si tout fonctionne, je pourrais penser à l'optimisation, car avec la venue de ES 3.1 qui permet les Bindless Textures ça va simplifié grandement les choses. Il suffit d'attendre un peu. Merci invalipIp
J'ai pas mal avancé la restructuration de mon système graphique, ça va être beaucoup plus propre. J'espère bien sortir le code avant 2015, sous une licence très permissive, surement Apache
GZE, un moteur multiplateforme, adapté pour de la 2D, 3D et création de logiciels.
Humm, pour la licence ça fait un moment que j'y pense, au début je voulais prendre une licence qui serait gratuite pour les programmes/jeux gratuit, et payant pour ce qui serait commercial. La seule licence qui permet ça est une licence Binpress. Ensuite je me suis demandé comment faire la différence entre une grosse entreprise qui fait déjà des millions et un petit indépendant qui tente de se faire de l'argent de poche. La license serait le même prix?
Donc, je pense opté à la place d'un système de don, dans l'esprit que si tu veux que la lib évolue ça va aller plus vite avec des dons et peut-être même faire des demandes spéciales
Je ne suis pas vraiment à l'argent, en réalité je ne souhaite qu'une chose, pouvoir travailler à temps plein sur le projet. Car il est très difficile de travailler 40 heures semaines et de faire 40 heures de projet en plus.
J'ai déjà créer une petite lib open source dans un autre projet et à vrai dire personne ne ma jamais rien donné. Qu'en pensez-vous? Un système de dons peut-il réussir? Ou bien est-il mieux de forcer les gens à payer?
- Edité par Maeiky 21 novembre 2014 à 1:30:42
GZE, un moteur multiplateforme, adapté pour de la 2D, 3D et création de logiciels.
systeme de dons car ton moteur a l'air génial, faire payer peut degouter les gens. comme ton moteur arau l'air génial (et il l'est) aupres du grand public, ils n'hésiteront pas trop avant de donner je suppose. un projet comme celui ci on veut le voir avancer !
Je pense que tu devrais faire un double système : un système de don, et un système du style : tu prend + ou -15% de la vente d'un jeu/programme utilisant ton moteur graphique.
J'avais pensé à quelque chose du genre, mais malgré le fait que j'y ai passé environ 6 ans de travail et que si j'aurais tout mis ce temps dans une vrai job, je serais sans doute riche (mais on fait ce qu'on aime et j'ai acquis beaucoup d'expérience). Je ne le ferais pas pour ces raisons :
#1 Le moteur n'est pas populaire, ça va juste l'être encore moins si c'est payant. #2 Le moteur n'est pas au points, il est trop tôt pour devenir payant. #3 Je réserve encore bien d'autres surprises.
Entre autres, le moteur cache un langage de programmation complet et simple (un peu comme Java), car mon précédant projet est d'avoir réalisé mon propre langage. GZE est en réalité réalisé en grande partie grâce à celui-ci. Il génère automatiquement le C++. Ça me prenait une base solide pour créer des applications c'est pour ça que j'ai fais GZE, les deux vont ensemble. C'est à la fois natif dans ce langage et utilisable dans n'importe quel projets C++. Un jour je vais le dévoiler au grand public
En gros GZE est gratuit, au pire je me rattrape sur mes autres projets, mais bon ça sera surement gratuit aussi
La partie Android commence à fonctionner, je suis en pleine refonte du système, tranquillement ça prend forme
GZE, un moteur multiplateforme, adapté pour de la 2D, 3D et création de logiciels.
je vien de le télécharger pour Linux, rien à dire, installation rapide, simple, même accessible aux plus jeunes débutants.
Juste une remarque : peut-on changer l'image, la sauvegarder, etc... car pour l'instant juste un chien auquelle on peut le déformer et modifier la couleur, etc... ça ne sert pas à grand chose et je n'arrive pas à comprendre comment tu à fait l'affichage de ton appli avec la batterie.
J'ai peut-être zappé un truc, si c'est le cas, dîtes le moi s'il vous plait.
Merci, oui en fait l'image n'est pas modifiable car c'est ma première démo et c'est pour montré les possibilités. Ça l'air de rien, mais il y a un grand potentiel derrière. Faire une application légerte avec les ressources intégré, le tout sans dépendances.
N'importe quel débutant télécharge Code::Blocks, puis clique sur compile et 10 secondes plus tard obtient ce résultat. Le moteur est déjà utilisable, tu as l'exemple pour afficher et transformer une image, ensuite tu laisse libre recours à ton imagination.
Pour la batterie c'est un peu plus complexe, j'ai tout fait l'électronique pour un projet de fin d'étude. Il faut connaitre les microcontrôleurs. Par contre, il existe des boards de développent déjà tout fait, d’ailleurs je montre que GZE tourne sur un STM32F429 discovery. En gros les graphiques ce font par manipulation de pixels dans un tableau 2d, ensuite j’envoie ce tableau à l'écran.
GZE, un moteur multiplateforme, adapté pour de la 2D, 3D et création de logiciels.
J'ai finalement réussi à rendre mon moteur compatible OpenGL ES2! De plus, je suis parvenue à faire une première version Android!
J'utilise l'IDE Éclipse pour compiler sur Android en C++. L'autre choix aurait été Android Studio, mais il est tout bogué et vraiment pas au point. Un projet Éclipse tout fait sera inclue à GZE, car utiliser cet IDE pour faire du Java/C++ ce n'est pas de la tarte.
Voici ce que donne mon premier test :
Donc mon moteur sera compatible sur tout les périphérique Android disposant d'OpenGL ES 2 et plus, ce qui correspond à environ 98% des mobiles. Bien entendu c'est un premier test, il me reste encore quelques bogues à régler. Prochaine plateforme, une version WebGL
GZE, un moteur multiplateforme, adapté pour de la 2D, 3D et création de logiciels.
Rectification : Android studio est passé en beta et il n'est plus bogue, j ai un ami qui l utilisé et pas de problème !
C'est peut-être un problème isolé, mais même avec les dernières versions, chez moi à chaque petite action dans Android Studio, tout "freeze", ma sourie, ma musique, etc. C'est vraiment trop désagréable à utiliser, c'est beau faire du multi-thread, mais il faut laisser respirer le reste . Il faut aussi dire que je doit utilisé le NDK pour faire du C++. Sinon, éventuellement il n'est pas impossible qu j’inclue un projet Android Studio aussi.
Ardakaniz a écrit:
Le moteur, c'est une lib ou une application ?
Toute mes excuses si ce n'est pas suffisamment clair. GZE est bien une lib (bibliothèque) comme base à n'importe quel projet C++. C'est à dire des applications, widgets avec transparence, jeux 2d et même 3d. Le tout dans le but de supporter le plus de plateforme possible sans changer une seule ligne de code. Le moteur est très modulaire, une nouvelle plateforme se rajouter assez aisément.
C'est un peu comme la SDL ou SFML, mais avec une philosophie très différente. Premièrement, il n'y a aucune dépendances, pas de librairie audio, image, font ou de glew machin requis. Je vise légerté et efficacité, une compilation complète très rapide (exemple :10 secondes vs 30 minutes pour SFLM). Un autre point important, je suis contre tout système avec librairie dynamique (lib pré-compiler en .dll, .so). Ça brise toute portabilité et ce n'est pas supporté sur tout, comme certain MCU. De plus, ça brise la visibilité de l'open source, et toute modification live. Sans parler de problèmes de versions et compilateur que ça cause.
Bef, c'est un excellent point de départ destiné à n'importe quel nouveaux projet, pensé pour les débutants, entre autre il y aura des projets de divers IDE directement compilable, avec des tutoriels.
GZE, un moteur multiplateforme, adapté pour de la 2D, 3D et création de logiciels.
Merci de votre intérêt, ça m'encourage vraiment à sortir une première version
Donc pour sortir quelque chose plus rapidement, j'ai pensé à limiter les features, puis à les ajouter tranquillement, je ne vais pas tout rendre disponible d'un coup car ce n'est pas suffisamment stable.
La première release est la plus difficile car c'est un projet très ambitieux. Aussi, je veux évité d'avoir à recommencé le code, donc il faut que je sois très avant-gardiste. Il faut que ce soit en béton, surtout quand l'on joue sur plusieurs plateformes.
Il me reste encore beaucoup de choses à corrigé, mais je donne les bouchées doubles. Si tout va bien dans 2 semaines j'aurai une release.
J'ai aussi refais le logo, qui indique l'avancement des plateformes
GZE, un moteur multiplateforme, adapté pour de la 2D, 3D et création de logiciels.
Même si tu ne sort pas encore une bêta de la lib. est-ce que tu peux au moins montrer un code d'exemple avec '
Voici un exemple de code pour créer une interface avec une image qui tourne :
#include "GroundZero.h"
#include "Example/_Rc/Transform_png.h"
Example_GroundZero::Example_GroundZero(GZ_Root* _oParent){
//Création d'une inteface, sur Windows c'est une fenêtre dans son propre thread indépendant des autre fenêtres
Ini_GZ_Interface(gzLStr(L"GroundZero"), 800, 600, bTransparent, 0xFFFFFFFF, GZ_SysWindow_eWinBorder_nNormal);
fCreateInterface();
}
//Quand l'interface est créé, WinStart est appelé
void Example_GroundZero::fWinStart(){
//Création d'une image
oImg = new GZ_Img(this, 0, 0, GZ_sFile_Resource_Transform_png, true);
//GZ_sFile_Resource_Transform_png est une ressource prégénéré en un fichier .cpp
oImg->WnX(-200); //W = Wrap Teleport pos X à 380
oImg->WnY(250); //W = Wrap Teleport pos Y à 250
}
//Fonction exécuté à chaque frame
//Chaque objet peut avoir des enfants, il y a 2 fonction appeler qui où l'ordre d'exécution diffère : (fUpdateChildToParent/fUpdateParentToChild)
void Example_GroundZero::fUpdateChildToParent(){
oImg->MnRoll(0.01); //M = Mouvement, tourne continuellement
oImg->TnYaw(15.7); //T = To, se positionne à la valeur 5
oImg->EnYaw(150); //E = Easing, ralenti progressivement
oImg->TnX(400); //T = To, se positionne à la position 400
oImg->EnX(40); //E = Easing, ralenti progressivement
}
Voici le résultat, (Rendu par OpenGL 3.3, pour l'instant la détection n'est pas automatique de sa disponibilité) :
Pour les 2 car il n'y a pas vraiment de logo qui les différencies, quoi je pourrais indiqué OSX et IOS. Je vise principalement IOS avant tout à moins que certain préférait voir naître une version OSX avant? Mais bon c'est pas pour tout de suite.
J'ai fait une erreur pour la version OpenGL de Windows qui n'activait même pas les points 3D de mon exemple ci-dessus
Ça resemble à une bibliothèque bas-niveau type openGL avec des préfix particuliers et tout.
Sinon, je trouve que plusieurs fonctions ont la même utilité : WnX() et TnX()
Et les fonctions ...Yaw() servent à quoi. En fait c'est les nuances de mot clés des fonctions que je ne comprend pas (c'est peut être que je ne connais pas assez l'anglais)
Sinon si tu a besoin d'aide je peux t'aider (ou même faire parti du projet )
Bon réveillon !
EDIT : J'ai essayé GZE_Demo_Roll et mon antivirus (Avira (gratuit)) le bloque et dit qu'il contient le virus ou le programme indésirable "HEUR/APC (cloud)"
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
GZE, un moteur multiplateforme, adapté pour de la 2D, 3D et création de logiciels.
GZE, un moteur multiplateforme, adapté pour de la 2D, 3D et création de logiciels.
GZE, un moteur multiplateforme, adapté pour de la 2D, 3D et création de logiciels.
GZE, un moteur multiplateforme, adapté pour de la 2D, 3D et création de logiciels.
GZE, un moteur multiplateforme, adapté pour de la 2D, 3D et création de logiciels.
GZE, un moteur multiplateforme, adapté pour de la 2D, 3D et création de logiciels.
GZE, un moteur multiplateforme, adapté pour de la 2D, 3D et création de logiciels.
GZE, un moteur multiplateforme, adapté pour de la 2D, 3D et création de logiciels.
GZE, un moteur multiplateforme, adapté pour de la 2D, 3D et création de logiciels.
GZE, un moteur multiplateforme, adapté pour de la 2D, 3D et création de logiciels.
GZE, un moteur multiplateforme, adapté pour de la 2D, 3D et création de logiciels.
GZE, un moteur multiplateforme, adapté pour de la 2D, 3D et création de logiciels.