La 3D.

[Lolilolight]

Salut,

je voudrais savoir si plus tard tu prévois de faire de la 3D avec SFML, j'entend par là faire des choses comme par exemple une view mais dans un monde en 3D.

Moi, je pense que se serait bien.

Si pas je pense que je vais modifier SFML pour faire ce genre de chose, je n'aurai qu'à rajouté ça et une composante z aux vertex et le tour sera joué je pourrai faire aussi de la 3D. 

[Laurent]

Non ce n'est pas prévu.

[Lolilolight]

Ok, ce n'est pas grave j'ai réussi à faire une vue 3D moi même en projection perspective et orthographique.

Il ne me reste plus qu'à faire des classes du genre RenderWindow, RenderTarget et Transformable mais pour de la 3D.

Je pense que je vais m'inspirer de ton code. 

[Nexus]

Il y a des bibliothèques qui sont spécialisées pour la graphique 3D, par exemple Irrlicht.

[Lolilolight]

Je sais mais je n'aime pas le faire via un moteur de jeux pré-existant surtout que je manipule très bien opengl et que je suis assez fort pour faire mes propres algorithmes à ce niveau là.

J'ai eu des problèmes pour comprendre le fonctionnement de Irrlicht et Ogre, je n'ai pas trouvé d'exemple, ni de documentation ni de tutoriels vraiment bien fait comme pour ici, bref...

Et puis j'ai surtout envie de faire ça dans un but d'apprentissage au niveau programmation parce que si il y a tout de déjà implémenté niveau ingénieurerie je ne vais rien apprendre du tout si un jour je dois coder des applications plus spécifiques pour lesquelles il n'existe pas vraiment de bibliothèques pour le faire.

Et puis je suis toujours amené à un moment ou à un autre à me replonger dans du code de plus bas niveau. (Soit parce que j'ai des problèmes d'incompatibilités et que ça ne marche pas comme prévu à cause de problèmes de synchronisations entre différentes bibliothèques très difficile à résoudre. (j'ai eu le cas quand je travaillais avec swing et JOGL qui utilisait un thread en interne), ou bien parce que je ne trouve pas la documentation que je veux (j'ai eu le cas quand j'ai travaillé sur un projet qui utilisait ogre)

Du coup j'ai préféré faire mes propres algorithmes les seules librairies que j'utilise sont juste des librairies qui implémentent les fonctionnalités de bases les plus importantes et qui assurent une certaine compatibilité (comme par exemple la SFML ou bien QT qui font abstraction sur certaines librairies de bas niveaux qui sont plus difficile à prendre en main surtout si l'on veut rendre le code compatible sur plusieurs os), mais, pour les librairies plus spécifique comme par exemple celles pour créer des jeux vidéos, je préfère faire mes propres algorithmes.

Par contre si je dois faire des choses ou les performances sont vraiment plus critique comme par exemple la manipulation des grands nombres en c++ et la cryptographie alors là je préfère utiliser openssl parce que moi..., je pourrai jamais faire quelque chose d'aussi performant et sécurisé que des projets opensource.

[Nexus]

J'ai eu des problèmes pour comprendre le fonctionnement de Irrlicht et Ogre, je n'ai pas trouvé d'exemple, ni de documentation ni de tutoriels vraiment bien fait comme pour ici, bref...

Tu as lu ceux d'Irrlicht? Je ne trouve pas qu'il sont mal faites. Pour Ogre, c'est une différente chose...

Documentation: http://irrlicht.sourceforge.net/docu
Des tutoriels: http://irrlicht.sourceforge.net/tutorials

Si tu as besoin de plus de flexibilité qu'avec une bibliothèque, OpenGL est une bonne idée, mais je ne comprends pas pourquoi tu demandes d'avoir 3D en SFML? Tu aurais exactement le même problème... Irrlicht est une abstraction de OpenGL (et de DirectX, si tu veux) pareille à SFML, mais il offre aussi des choses au niveau plus haut. Améliorer les performances d'une bibliothèque qui existe depuis plusieurs ans n'est pas toujours simple, particulièrement quand tu commences à dessiner des scènes complètes. C'est aussi la question si tu aimerais plutôt comprendre les téchniques bas-niveaux et écrire ton propre moteur, ou developper un jeu

[Lolilolight]

Oui mais je ne suis pas fan de Irrlicht et de leur système de "scene node". (Surtout pour la caméra, le driver, etc...)

Même si je trouve que le moteur de jeux est bien fait et qu'il gère les drivers opengl et directX.

De plus je ne sais pas du tout si il est multi-threadé ce moteur de jeux vu qu'il date quand même un peu. (Donc si je peu faire la même chose mais en multi-threadé pour décharger un peu le CPU et pouvoir faire plus de choses dans mon jeux je ne dirai pas non)

De plus il ne prend pas en charge la physique, il faut donc utiliser une autre librairie pour cela, non pas que ça me dérange mais bon.

Et, je la trouve un peu incomplète encore cette librairie, j'ai regardé un peu les classes, à part des aabb je ne vois pas grand chose que je pourrai utiliser pour la détection de collision.

J'avais fait quelque chose de plus complet à un moment donné avec des intersections ligne triangles, des octree, des bsp-tree, etc... (Chose que je ne pourrai pas faire avec Irrlicht, si je crée mon propre scene node ça risque d'être contraignant, je préfère le système à la SFML quand même. ^^)

Et puis je n'aime pas utiliser trop de librairies ensemble (une pour la physique, une pour le réseau, une pour le rendu, etc...)

J'ai déjà parfois du mal avec juste la SFML, Qt et le standart du c++11 avec des crash parfois difficile à débuguer alors...

Bon, j'espère que ça va s'améliorer à l'avenir mais bon quand tu charges une map et que tu veux faire le rendu avec un thread mais que ça crash une fois sur deux au chargement de la map ou bien quand je fait le système d'identification d'utilisateur avec la base de données..., ça va pas être très pratique, surtout que certaines libairies utilisées par la SFML utilisent déjà des threads donc si les fonctions des différentes librairies ne sont pas thread safe c'est les crashs assuré. (Comme c'était le cas lorsque j'utilisait JOGL en parallèle avec une autre librairie, et que ça plantais au rendu car conflit entre les thread de la librairie swing et celle de JOGL)

Bref..., je pensais avoir plus simple en installant un tas de librairies mais j'ai des problèmes supplémentaires qui surviennent et que je n'ai pas si je n'utilise pas certaines librairies donc. :/

Dans certains cas, je préfère éviter d'utiliser une librairie surtout si ce n'est pas indispensable et que le code design ne correspond pas trop à ce que je veux faire.

PS : quand j'aurai le temps je posterai des codes minimes ou je parlerai justement de ces problèmes.

En gros j'ai envie de faire une seule librairie qui fait tout, plutôt que d'en utiliser plusieurs qui risquent d'entrer en conflit.

[Nexus]

Toutes les bibliothèques 3D ont un graphe de scène, c'est presque le standard. Multi-threading depend surtout de l'application, il n'y a pas beaucoup de sens de synchroniser des choses quand tu ne les utilises pas. Irrlicht offre la détection de collision et de la physique basique. Si tu as besoin de la fonctionnalité plus complexe, il faut utiliser une bibliothèque physique de toute façon, tu ne peux pas écrire tout le code toi-même. Mais c'est aussi vrai qu'Irrlicht est déjà un peu âgé, particulièrement le code C++ n'est pas très moderne.

Je ne dis pas qu'il faut developer avec Irrlicht, mais il paraît que tu ne l'a pas assez utilisé pour connaître toutes ses possibilités. Et peut-être tu sous-estimes un peu le travail necessaire pour la graphique 3D, car c'est beaucoup plus complèxe que 2D: Matériels, terrains, lumières, ombres, brouillard, shaders, animations, particules, modèles 3D, algèbre linéaire, ... Voici toutes les choses qu'Irrlicht déjà offre. Avec OpenGL, tu as une éternité pour implementer même une partie.

[Lolilolight]

Tout dépend de ce que tu veux implémenter en 3D. (Si je veux juste faire un terrain et une caméra avec détection de collision, je vois pas l'intérêt d'utiliser Irrlicht, surtout que je veux faire des trucs basique dans un premier temps, et que je ne sais pas ce qu'utilise Irrlicht pour sa génération de terrain, moi, je compte essayer un système de heightmap, bref, des choses vraiment basique quoi)

Les graphs de scène c'est bien et beaucoup d'api de haut niveau les utilise mais le problème c'est que j'ai un FPS beaucoup plus bas car je dois combiner les transformations avant le dessin, c'est pour cela que je préfère utiliser une api custom qui effectuerais les multiplications matricielles au niveau du GPU.

Tu as raison je n'ai jamais essayé Irrlicht car c'est trop ancien selon moi et je ne sais pas comment ça fonctionne au niveau interne, il faudrait pour cela que je jette un coup d’œil si le projet est opensource comme celui de la SFML.
De plus je ne sais pas si c'est régulièrement remis à jour comme par exemple SFML qui de plus possède une communauté anglophone et française.

Donc voila Irrlicht c'est bien si t'a pas envie de te casser la tête au niveau programmation mais pas si tu veux faire un jeux plus optimisé il vaut mieux utilisé un truc plus moderne. (Même si c'est plus long parce que il faut coder toi même le code source pour charger des modèles 3D (au format md2 par exemple), charger et plaquer les matériaux, etc...))
Mais je peux te dire qu'en utilisant des techniques basique, c'est encore faisable sans utiliser de moteur 3D et puis plus tard rien ne t'empêche d'améliorer ton code source pour générer des ombres, améliorer l'éclairage, etc...