Discussion :

[plegat]

Salut,

-Possibilité de créer des modèles 3D comme avec le logiciel blender

Houla... motivé dis...

le logiciel utilisera son propre format de fichier grâce à la sérialisation, car, je trouve cela plus simple à réaliser que de faire des exportations vers des fichiers .md5, .obj, etc...

La sérialisation pour faire de la sauvegarde binaire propre à ton moteur (ou à ton interface plutôt), pourquoi pas... ne pas faire d'exporteur, ça se conçoit... par contre fait au moins un importeur obj... ça, c'est la base... que ton futur utilisateur soit obligé de se faire son modèle à la mano, et ne puisse pas importer celui qu'il a déjà sous le coude, ça serait une grosse limitation. Voire un point bloquant.

Cependant je compte faire un système similaire à géogébra c'est à dire créer des points et les relier pour créer des lignes/faces, et donc, faire bien plus que le simple système d'extrusion proposé par blender, bref, j'ai trouvé ce dernier logiciel pas toujours très pratique à utiliser.

A t'entendre, tu ne sais pas te servir de Blender (dans le sens, s'en servir de manière intuitive et efficace...).
On peut très bien créer des faces dans Blender en reliant des points, en reliant des edges, en splitant, en raffinant... etc etc. Il y a 36 manières de faire des quads, et autant de faire des triangles!
Après, en réfléchissant:
- extruder une ligne pour faire une face = 1 opération (allez, 2 pour être exact, il faut sélectionner la ligne d'abord...)
- créer deux points, les relier aux deux points existants, les relier entre eux, créer la face = 6 opérations (sans compter les clics souris...). 4 de plus... à répéter autant de fois que tu as de quads...

-Possibilité de dessiner sur les faces du modèles, je ne comptes pas reprendre le système de dépliage du modèle de blender car je ne m'en sors pas avec et je le trouve compliqué à utiliser.
Je pense faire un système de sélection de faces plutôt et dessiner dessus.

C'est con, l'unwrap de blender a été plébiscité par pas mal de monde à une époque... dont des utilisateurs d'un autre logiciel proprio concurrent...
Cela dit, il y a aussi un mode "texture paint" dans blender où tu dessines... directement sur les faces!
Tu comptes nous refaire le sculpt mode aussi? Avec baking des normal maps?

Là, à mon avis, tu te lances dans un truc:
- soit infaisable, si tu comptes arriver au même niveau que Blender.
- soit inutile, parce que Blender (ou un autre) le fera mieux.


Le moteur de script, c'est intéressant.
Un éditeur de map, ça serait intéressant.
Un importeur de modèles (avec les formats courants du moment), ça serait intéressant.
Refaire blender, non. Ca, ça ne l'est pas...

Mais ce n'est que mon avis, fais ce que tu as envie de faire!

[Invité]

Je vais poster une image reprenant l'interface graphique version brouillon, je pense que vous aller mieux comprendre ce que je raconte.

Je ne compte pas refaire blender, il y a trop d'options là dedans, j'ai juste envie de quelque chose de plus simple..., comme je l'ai déjà dit plusieurs fois, je ne m'en sors pas très bien avec blender car trop de manière de faire et puis trop d'options. :/

Je ne pense pas faire mieux que blender, ce n'est pas le but ici, mais au moins proposer quelque chose de plus simple, quitte à faire un logiciel qui ne soit pas dépendant d'autres logiciels via des importations/exportation comme il faut le faire avec unity.

PS : Personnellement je ne vois pas le problème de faire mon propre logiciel pour modéliser, de toute façon, je n'ai pas de graphiste sous la main, et puis, rien ne l'empêchera d'utiliser mon moteur.

Je ne suis pas sûr que blender se penchera sur de nouvelles technologies tel que l'opengl moderne ou encore vulkan pour le rendu et je le trouve relativement lent d'ailleurs pour cela. (D'autant plus qu'il est codé en python)

3DS je ne compte pas l'utiliser car il est payant.

[skeud]

Ok c'est sur que faire un outil de création de modèle pour ton moteur est vraiment bien car tu ne peux pas importer des modèles des autres logiciel.

En revanche, et là c'est par rapport à ton modèle économique, tu dis que tu ne veux pas utiliser 3DSMax car il payant, c'est un peu le même principe pour ton moteur, les gens ne voudront pas l'utiliser car il est payant ><. Surtout si tu ne gères pas les modèles classiques.

[maeiky]

Bref, le moteur étant pratiquement terminé, je pense faire un outil pour le moteur!

Peux-tu nous faire part de ce qui à été accomplie jusqu'ici?

Il me semble que tu réalisais un moteur portable, as-tu prévu/commencé une version Windows? Il nous serait plus facile de tester.

J'aime bien le fait de faire ton propre système de création de modèle 3D simpliste, sans recréer blender tu peux faire de super jeux, par exemple, star fox sur snes, ça n’empêche pas que c'est un excellent jeu, sans avoir nécessairement à recréer la réalité. Tu peux même faire de magnifiques effets de particules et autre avec les méthodes d'aujourd'hui.

Néanmoins, il serait bien de pouvoir importer un modèle externe connu, sans supporter tous les modèle possible, prend seulement le meilleurs.

[LittleWhite]

Je ne suis pas sûr que blender se penchera sur de nouvelles technologies tel que l'opengl moderne ou encore vulkan pour le rendu et je le trouve relativement lent d'ailleurs pour cela. (D'autant plus qu'il est codé en python)

Désolé, mais c'est ce qu'ils font. OpenGL moderne (en version 2, pour une grande compatibilité, mais cela peut être assez moderne (shaders + VBO)) et ils ont aussi un support de OpenCL.

[Iradrille]

PS : Personnellement je ne vois pas le problème de faire mon propre logiciel pour modéliser, de toute façon, je n'ai pas de graphiste sous la main, et puis, rien ne l'empêchera d'utiliser mon moteur.

Quelqu'un qui maitrise Blender (ou autres) est efficace avec. Devoir réapprendre à utiliser un soft, qui sera limité en fonctionnalités ça dérange pas mal de monde.
Si tu veux faire un soft de modélisation, pourquoi pas, mais supporte au moins les formats standards (Assimp permet d'importer un bon paquet de formats, et d'en exporter quelques-uns).

C'est comme dire 'toshop s'trop compliqué, je vais utiliser un format d'image proprio et coder un genre de mspaint, ça ne devrait pas gêner les graphistes.
Même si j'adore mspaint (tellement pratique pour faire des schémas quand je code et que j'ai pas de papier / crayon sous la main...), on atteint vite les limites du soft, même sans être graphiste.

[plegat]

Je ne suis pas sûr que blender se penchera sur de nouvelles technologies tel que l'opengl moderne ou encore vulkan pour le rendu et je le trouve relativement lent d'ailleurs pour cela. (D'autant plus qu'il est codé en python)

Raté... C essentiellement, du C++ autour, et juste un peu de python pour le scripting.
En prime, le rendu ne se fait pas avec OpenGL, mais avec les moteurs de rendu (internal, cycles... qui est en rendu GPU tout de même, donc dire que c'est lent... hum...)

Mais peut-être que tu parles du BGE et pas de blender... mais si c'est du BGE que tu causes, on n'est plus dans le modeleur, là, c'est pas le même usage...

[Invité]

Salut!

Bonne nouvelle, je viens de corriger un nouveau bug, désormais les objets contenant des pointeurs sur des objets de même type sont sérialisé et désérialisé correctement!

Code cpp :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
Entity::vtserialize(Archive& ar) {
       //Sérialise ou désérialise le pointeur vers l'entité parente.
       ar(parent);
       //Sérialise ou désérialise l'entité courante.
       .....
      //Sérialise ou désérialise les pointeurs vers les entités enfantes.
       ar(children);
}

Ce qui clôture la correction des bugs (dans ceux que j'ai repéré), je mettrai à jour le dépôt git demain.

Il ne manque plus qu'une interface graphique à tout ça!

Le moteur permettra de créer non seulement des jeux mais aussi des applications de tout types, même pour mobile!

Je n'aime pas le support des formats existant car ils m'imposent de faire leur propre système pour les animations, hors que mon moteur utilise un système de scène node beaucoup plus simple surtout pour gérer les animations squelettiques.

Le problèmes des formats connus tels que le md5 c'est qu'ils ne gère pas les animations squalettiques, mais juste l'interpolation linéaire, donc, pour animer un personnage équipé c'est lourd.

Le système de scène node me permet de bouger l'équipement en même temps que un membre du personnage. (Il me suffit de faire des scenes nodes de frames pour toutes les animations de mes personnages)

Donc cela se rapproche plutôt du format .blend plutôt que des formats connus tel que le md5 qui sont beaucoup plus simple et limité à des FPS.

De plus il est très simple de sauvegarder des pointeurs vers des objets parents et enfants et d'effectuer les transformations de manière récursive, si certaines frames dépendent d'autres frames comme c'est le cas pour les animations squelettale, avec les frames parents et les frames enfants.

Par exemple j'ai une frame parent qui est l'animation du personnage qui court, la frame enfant est l'animation d'un équipement quand le personnage court, lorsque j'interpole les vertex de la frame parent ça interpolera aussi les vertex de la frame enfant.

Plutôt que de partir sur des quaternions que je ne maîtrise absolument pas...

Les entités ça peut donc être n'importe quoi, une frame, une lumière, ou un objet de plus haut niveau propre au jeux. (un équipement, un personnage, etc...)

Mais l'interface graphique simplifiera les choses, il n'y aura plus à réfléchir sur comment interragir avec les noeud enfants lorsque l'on modifie le noeud parent, dès lors que l'on dessinera les entités, les scripts se modifieront automatiquement on conséquence, de ce fait, on pourra très bien créer une animation et la lier à un personnage, on pourra également créer une animation pour chaque équipement et la lier à l'animation du personnage, les deux animations de l'équipement et du personnage seront interpolée de manière synchrone, exactement comme lors des animations squelettiques lorsque les sommets suivent le mouvement des bones.

[maeiky]

Super, j'ai hâte de voir ça.

De plus il est très simple de sauvegarder des pointeurs vers des objets parents et enfants et d'effectuer les transformations de manière récursive, si certaines frames dépendent d'autres frames comme c'est le cas pour les animations squelettale, avec les frames parents et les frames enfants.

Par exemple j'ai une frame parent qui est l'animation du personnage qui court, la frame enfant est l'animation d'un équipement quand le personnage court, lorsque j'interpole les vertex de la frame parent ça interpolera aussi les vertex de la frame enfant.

Plutôt que de partir sur des quaternions que je ne maîtrise absolument pas...

Mais, les quaternions c'est justement pour faire des transformation récursive, j'ai un peu de mal à savoir comment tu va faire sans, il y a bien un moyen, mais il faudrait appliquer une transformation des points dans l'espace pour chaque niveau (coté performances c'est pas top), sinon tu vas avoir de problèmes avec tes rotations.

Le moteur permettra de créer non seulement des jeux mais aussi des applications de tout types, même pour mobile!

Alors, tu fais une version Windows ou pas?
Mobile? Quel version? OGL ES2, ES3, Vulkan?

[Invité]

Je ne pense as faire de version windows, mon bios ne veux même plus booter sur clé usb ni sur cd...

Donc impossible d'installer un quelconque OS que ce soit.

J'ai mit à jour le dépôt git!

Correction de deux bugs.

[yildiz-online]

machine virtuelle

[skeud]

Je ne pense as faire de version windows, mon bios ne veux même plus booter sur clé usb ni sur cd...

Pas de version windows pour un moteur de jeu 3D? J'ai du louper une étape

[Invité]

Machine virtuelle c'est encore pire, ça ne supporte même pas la version 3.0 de opengl, la seule chose que j'ai installé c'est wine mais ça ne me permet que d'exécuter des applications windows, pas d'en développer.

Soit je vais faire réparer ce bios ou alors j'achète un nouveau PC à la sortie de vulkan mais je préfère la second solution.

[maeiky]

machine virtuelle

Sous VMWare c'est du OpenGL 2 max

Edit :


Finalement la toute nouvelle dernière version supporte OpenGL 3.3!

Il est disponible pour Windows et Linux 64bit, voir ici :

http://blogs.vmware.com/workstation/2015/07/vmware-workstation-technology-preview-2015.html

Plus d'excuse

[LittleWhite]

La seule chose que j'ai installé c'est wine mais ça ne me permet que d'exécuter des applications windows, pas d'en développer.

Ah, dommage. Un des buts de Wine (car Wine Is Not an Emulator), c'est de permettre de développer des applications Windows, sous Linux.

[maeiky]

Pauvre Lolilolight ... , en fait il pourrait avoir quelque chose de très bien s'il apprenait à faire du batching, à faire de la transparence correctement, avec une meilleur portabilité.

Lolilolight, tu devrais te concentrer sur ces points avant tout, avec un meilleurs fps et une qualité de rendu correct, on va te prendre au sérieux.

[Invité]

Bonjour,
je n'ai malheureusement pas de solutions actuellement afin de gérer la transparence correctement avec un système de batching, car, le système de batching dessine tout avec un seul draw ce qui signifie un seul appel au shader, et donc, une seule lecture et écriture dans le framebuffer.

Si je veux faire plusieurs lectures et écritures je n'ai pas le choix, je dois appeler plusieurs fois la méthode draw et je suis sûr que avec les autres moteur c'est pareil.

Le FPS sera amélioré dès la sortie de vulkan, ou alors si je trouve un driver qui supporte les atomics read write dans le fragment shader.

Il sera alors possible de lire et de modifier le framebuffer de ma texture de rendu sans devoir rappeler le shader à chaque fois avec un draw call pour que le framebuffer se mette à jour. (Ce qui est lent et je trouve que l'opengl ancien est vraiment très lent et c'est pénible de ne pas avoir un driver supportant l'opengl moderne (la version 4.5) à portée de main)

C'est juste cela qui pose problème mais malheureusement actuellement comme mon driver ne supporte pas les nouvelles versions d'opengl je n'ai pas de solution de plus le code source est propriétaire et toutes les spécifications de la carte graphique sont gardée par le constructeur.

Donc merci de ne plus troll, le soucis avec le FPS sera réglé dès la sortie de Vulkan c'est à dire l'année prochaine au plus tôt.
Avant cela, pas la peine d'investir.

Les déceptions j'ai l'habitude mais je suis d'accord avec Neckara, c'est pas très sympa et je n'ai pas apprécié de m'en prendre plein dans la tronche de cette manière. (Aussi bien sur ce forum que dans la vie réelle)

[maeiky]

Bonjour,
Si je veux faire plusieurs lectures et écritures je n'ai pas le choix, je dois appeler plusieurs fois la méthode draw et je suis sûr que avec les autres moteur c'est pareil.

Je vais te dire le secret de la performance GPU, tout les moteurs moindrement décent utilisent des techniques de batchings. C'est inévitable, dans le cas contraire, le CPU et CPU passe sont temps dans un état de synchronisation qui gaspille toutes les ressources.

Le batching ce n'est pas que le nombre de drawcall, c'est aussi comment tu envoie tes données, le nombre d’appels d’envois et de mise à jours de tes données. Même si Vulkan offre un pipeline atomique, je doute que tout périphérique le supporte de base et les performances ne seront pas nécessairement les même qu'avec le pipeline fixe (que l'on peut considérer comme des opérations gratuites). Même si ça marche, il te faut faire du batching.

Vulkan reprend les fonctionnalités d'OpenGL, il sera encore bien plus difficile à utiliser. OpenGL, ça sera du gâteau à coté. Tant que tu ne maitrise pas OGL, tu vas tomber dans les pièges de l'utilisation même du GPU, donc tant que tu n'arrive pas à faire ce que tu veux avec une technique déjà existante dans OGL, ça ne sert à rien de passer à Vulkan.

je n'ai malheureusement pas de solutions actuellement afin de gérer la transparence correctement avec un système de batching, car, le système de batching dessine tout avec un seul draw ce qui signifie un seul appel au shader, et donc, une seule lecture et écriture dans le framebuffer.

Tu n'as pas besoin de changer de shader à chaque fois et si tu gère le detph test, c'est encore plus facile de regrouper tes éléments.

Je parle par expérience, sans batching, à 60fps, j'avais du mal à afficher 100 sprites différents, avec batching je peux en afficher 20 000 et mon GPU n'est qu'à 20% avec un shader assez lourd. Le CPU est donc le goulot (sans grandes optimisations de ce coté).

[Iradrille]

Bonjour,
je n'ai malheureusement pas de solutions actuellement afin de gérer la transparence correctement avec un système de batching, car, le système de batching dessine tout avec un seul draw ce qui signifie un seul appel au shader, et donc, une seule lecture et écriture dans le framebuffer.

Si je veux faire plusieurs lectures et écritures je n'ai pas le choix, je dois appeler plusieurs fois la méthode draw et je suis sûr que avec les autres moteur c'est pareil.

Le FPS sera amélioré dès la sortie de vulkan, ou alors si je trouve un driver qui supporte les atomics read write dans le fragment shader.

Il sera alors possible de lire et de modifier le framebuffer de ma texture de rendu sans devoir rappeler le shader à chaque fois avec un draw call pour que le framebuffer se mette à jour. (Ce qui est lent et je trouve que l'opengl ancien est vraiment très lent et c'est pénible de ne pas avoir un driver supportant l'opengl moderne (la version 4.5) à portée de main)

Çà déjà été dit plusieurs fois, mais c'est possible d'avoir de bonnes performances sans Vulkan (si tu veux une preuve regarde du coté des jeux AAA).

Peu de draw calls c'est bien, mais ce n'est pas suffisant : tous les changements d'états sont longs (bind une texture / buffer différent(e) par exemple).

La transparence c'est lent et il n'y à pas de solution miracle actuellement : la seule solution qui existe (actuellement) c'est de ne pas (ou peu) utiliser la transparence.

Si tu regarde bien les jeux AAA, c'est ce qu'ils font.

Le rendu se fait en 2 étapes : d’abord tous les objets opaques, puis les objets transparents.
Il n'y a pas 1 draw call pour tous les objets opaque + 1 draw call par objet transparent (car certains objets transparents peuvent être regroupés (particules par exemple), et qu'il ne sera pas forcément rentable de regrouper TOUS les objets opaques), mais dans l'idée on est proche de ça.

[Invité]

Salut, tu parles de regrouper toutes mes tiles dans un même VBO pour éviter au max les bind au buffers ?

Sincèrement je devrai en effets regarder à cela.

Mais pour l'appel des draw calls je n'ai ps le choix surtout que j'utilise de la semi-transparence, et le shader ne mets pas à jour la texture de rendu au fur et à mesure qu'il la modifie.