Ben ouais c'est le bute, simplifier la représentation 3D pour faire un moteur de jeux très simple pour se concentrer sur la logique de jeux Sinon autant utiliser l'unreal engine 4 et blender.
Après je me suis concentrer sur autre chose, gérer les ombres , et permettre de créer des labyrinthes énorme et d'afficher le tous avec un FPS supérieur à 60 FPS.
Tu utilses quoi comme structure pour déterminer les objets visibles , un octree ou un BSP ou autre ????
Tu gère comment les textures atlas , avec des textures arrays ???
Ce la permet de faire un prototype de jeux rapidement, après je suis d'accord on aime ou on aime pas les graphismes à base de cube, ça ce discute pas.
- Edité par Banisardevidad 26 octobre 2016 à 17:04:57
Ce n'est pas une question d'aimer ou pas. Développer un moteur de qualité comme Nazara ne laisse pas le temps de réaliser un jeu de qualité à côté, c'est tout.
Ce n'est pas une question d'aimer ou pas. Développer un moteur de qualité comme Nazara ne laisse pas le temps de réaliser un jeu de qualité à côté, c'est tout.
Lynix a écrit:
@charlesfire: Ce n'est qu'un morceau du fond qui n'appartient pas au logo
Il s'en passe des choses quand on part une petite après-midi :D
Str4nger a écrit:
Oui, enfin Nazara permet quand même des rendus plus élaborés que le cubisme à la Minecraft ! C'est forcément un peu plus long à développer.
Après il faut dire quelque chose, le plus gros du boulot autour de Nazara n'a pas été consacré au rendu mais bien aux capacités du moteur de jeu.
Si on regarde l'évolution graphique, du moteur, on voit que ça n'a presque pas bougé ces trois dernières années, pour la simple raison que je me suis consacré à d'autres tâches que je considérai plus importantes, mais le moteur a toujours été flexible et permis à ses utilisateurs de rajouter ce qu'il manquait, par exemple l'utilisateur peut fournir ses propres techniques de rendus sans devoir recompiler le moteur, ou rajouter des post-process au Deferred Shading (et changer la composition du G-Buffer, etc.), pareil pour le système de particules qui est très flexible.
Je trouve important de le préciser car récemment on a vu des moteurs de jeux comme Kit ou Instrinsinc, ces deux moteurs de jeux proposent un rendu plus avancé que celui de Nazara, des éditeurs, l'un propose même un rendu via Vulkan.
Seulement voilà, il suffit de fouiller un peu le code pour se rendre compte que l'architecture de ces moteurs est atroce, Kit est tellement lié à OpenGL qu'il faudrait le réécrire pour rajouter le support d'un autre Renderer ou juste certaines fonctionnalités un peu plus poussées, et Instrinsinc utilise Vulkan de façon peu optimisée et avec un découpage tout aussi atroce (il suffit de voir que l'implémentation du rendu de la végétation et du reste se trouve dans le renderer Vulkan).
Bref, si les moteurs de jeux étaient des châteaux de cartes, je dirais que mon objectif n'est pas de faire le château le plus haut, mais le plus solide, qui ne s'écroulera pas en claquant des doigts, et qui à terme sera l'un des plus beau château de cartes du paysage des châteaux de cartes du libre, même si ça doit me demander du temps et des tubes de colle
Banisardevidad a écrit:
Tu utilses quoi comme structure pour déterminer les objets visibles , un octree ou un BSP ou autre ????
Pour l'instant, et depuis l'ECS, le culling n'est pas présent.
J'ai développé sur une autre branche (culling) une solution à base de frustum-culling cache-friendly, par la suite je passerai à une représentation en octree, mais ce n'est pas pour tout de suite.
Banisardevidad a écrit:
Tu gère comment les textures atlas , avec des textures arrays ???
Non, les texture arrays ne répondent pas à la problématique car la taille doit être la même à chaque face, ce qui n'est pas du tout ce que je veux, les texture atlas pour le texte ne sont que des textures régulières, découpées de façon logique par le moteur.
Str4nger a écrit:
Ce n'est pas une question d'aimer ou pas. Développer un moteur de qualité comme Nazara ne laisse pas le temps de réaliser un jeu de qualité à côté, c'est tout.
Je plussoie, même si ça dépend du degré de qualité, mais il est vrai que si je voulais développer un jeu comme disons Helium Rain avec Nazara, je devrais mettre le moteur en pause excepté pour les additions qui concernent directement le jeu.
edouard22 a écrit:
Str4nger a écrit:
Ce n'est pas une question d'aimer ou pas. Développer un moteur de qualité comme Nazara ne laisse pas le temps de réaliser un jeu de qualité à côté, c'est tout.
Lynix a écrit:
@charlesfire: Ce n'est qu'un morceau du fond qui n'appartient pas au logo
@edouard22:
A priori si.. le but reste de developer utopia
Alors ça c'est juste une petite démo en préparation d'Utopia, mais rien à côté du boulot colossal d'Helium Rain par exemple :)
Moi c'est une des chose que je me suis consacré le plus l'utilisation d'un octree et des query opengl , pour optimiser au maximum le rendu quand on est a l’intérieur de bâtiments ou de labyrinthe quelque soit la taille du monde, c'est indispensable pour faire un jeux.
Après les texture array tu peux en faire de taille différente après c'est vrais que les texture arrays c'est super adapté pour les jeux fais a base de cube car un pack de texture c'est un texture array.
Moi j'utilise un texture array couplé avec une texture 3D pour texturer chaque cube de façon différente.
Sinon Lynix, est-ce que tu aurais de la lecture sur la conception d'Engine 3D? Ou est-ce que tu pourrais nous partager ton pokédex de liens intéressant plz?
@Banisardevidad: La différence c'est que je dois faire quelque chose de la façon la plus générique possible avec Nazara, afin que tout le monde retrouve son compte peu importe l'objectif final, mais je suis sûr que tes techniques sont très bonnes pour les voxels.
@Bl4ckb0ne: Non je n'ai pas vraiment de lecture à vous faire parvenir, je lis souvent des choses à gauche et à droite comme ça, pour ce qui est de l'architecture c'est surtout de l'essai/erreur et de la réflexion (il m'arrive de passer des semaines à réfléchir avant d'attaquer un nouveau design), pour les features de rendu ça va faire trop longtemps pour retrouver les liens, et il y en a certainement toute une chiée :)
Donc il va falloir être plus précis je le crains !
La censure est la limitation arbitraire (cad libre choix sans logique ni accord avec la justice) ou doctrinale de la liberté d'expression de chacun.
Tu dérives du sujet, tu lances des débats dont personne ne veut et persistes à les continuer quand on te demande d'arrêter. Si tu veux étaler ta culture, lances des messages privés, ouvres un blog, comme tu veux. Mais pas ici.
Ce n'est pas un choix arbitraire de ma part, c'est une simple conséquence de ta dérive en hors sujet. Si tu dis avoir l'habitude des forums, tu devrais comprendre, sinon les forums ne sont pas faits pour toi et ça ne concerne que toi.
Sur ce, je modère ton énième hors sujet et supprime les réactions engendrées. Bonne continuation.
Alors ma question je vais faire différent , mon ton moteur tu va faire comment le culling ??????
Lynix a écrit:
Banisardevidad a écrit:
Tu utilses quoi comme structure pour déterminer les objets visibles , un octree ou un BSP ou autre ????
Pour l'instant, et depuis l'ECS, le culling n'est pas présent.
J'ai développé sur une autre branche (culling) une solution à base de frustum-culling cache-friendly, par la suite je passerai à une représentation en octree, mais ce n'est pas pour tout de suite.
Pour compléter un peu, je pense mettre en place après ça de l'occlusion culling software: les occluders seraient affichés (de façon extrêmement simplifiés) dans un depth buffer software, et les objets ayant passé le frustum culling seront ensuite testés par rapport à ce depth-buffer.
Voici un lien sorti de mon pokédex qui explique tout ça:
Très très bien merci , merci pour la réponse c'est ce que je cherchais a avoir discutions.
Merci.
C'était un peu l'idée de mon algorithme que j'avais présenté dans le poste qui a été supprimé.
Sinon j'ai un autre question , j’espère que mon poste sera pas supprimé...
tu connais des techniques pour afficher différemment un décor vu de très loin , genre faire un rendu dans une texture ou autre , tu a un truc dans ton pokédex ?? ???
Moi je trouve ce qui est intéressant dans ton projet c'est pas de faire un enième moteur 3D (il existe orgre3D irrlicht et autre ) mais de faire un truc modulable , comme par exemple rendre le culling entièrement modulable a sa sauce.
Il y a trop de moteur qui sont monolithique, donc bon courage sur cette voie la ....
- Edité par Banisardevidad 30 octobre 2016 à 10:19:29
tu connais des techniques pour afficher différemment un décor vu de très loin , genre faire un rendu dans une texture ou autre , tu a un truc dans ton pokédex ?? ???
Pour un modèle, il y a bien la technique des impostors, qui consiste à rendre le modèle du point de vue de la caméra dans une texture et puis d'afficher un sprite avec le résultat jusqu'à ce que le point de vue (l'angle entre la caméra et l'entité) change d'un certain facteur.
Pour un décor entier, là y'a pas photo, il faut soit le simplifier (le LOD est ton ami) soit utiliser une technique similaire aux impostors: rendre le décor lointain et uniquement lui dans un cubemap qu'on affichera comme une skybox, je ne sais pas trop ce que ça peut donner, surtout en automatique mais ça peut être intéressant.
Banisardevidad a écrit:
Moi je trouve ce qui est intéressant dans ton projet c'est pas de faire un enième moteur 3D (il existe orgre3D irrlicht et autre ) mais de faire un truc modulable , comme par exemple rendre le culling entièrement modulable a sa sauce.
Il y a trop de moteur qui sont monolithique, donc bon courage sur cette voie la ....
À vrai dire, contrairement à Unity/UDK/Cry Engine, Ogre3D et Irrlicht sont des moteurs que je souhaiterai voir Nazara dépasser, les mauvaises langues diront que ça n'est pas difficile mais pourtant je n'y suis pas encore :)
Mais oui, j'apporte pas mal d'importance à la modularité, il suffit de voir que mon premier moteur (l'ancêtre de Nazara) était entièrement basé sur un système de plugins qu'on pouvait changer à chaud.
Il faudrait que je fasse une liste de tout ce qu'il est possible de modifier à chaud dans Nazara, ça pourrait être intéressant :)
Si j'ai compris après avoir vite fait regarder le github et les commentaire de OC tu utiliser OpenGL pour le rendu
En effet, le renderer actuel est basé sur OpenGL 3.3.
Je suis en train de développer un nouveau Renderer multi-API sur une branche séparée (même si des changements vers cet objectif ont déjà été appliqués à master), proposant à terme Vulkan, OpenGL 2 et OpenGL 3.
J'ai été assez réticent à remettre le support d'OpenGL 2, mais visiblement il existe encore des personnes avec un ordinateur incapable de faire tourner OpenGL 3.3 et j'ai quand même envie de pouvoir dire que Nazara tourne à peu près partout.
Le point qui m'a le plus embêté avec OpenGL 2 c'était les shaders, mais étant donné que Vulkan veut de toute façon du SPIR-V et OpenGL du GLSL, je dois bien faire en sorte que les shaders puissent être compilés/traduits en différents langages.
A propos de Vulkan, je te prie de ne pas faire n'importe quoi avec les barrières ! Genre faire une "memory barrier from the bottom to the top" qui n'a juste aucun sens !
Pour le reste c'est du très bon boulot !
http://cpp-rendering.io : Vous trouverez tout ce dont vous avez besoin sur Vulkan / OpenGL et le rendu 3D !
A propos de Vulkan, je te prie de ne pas faire n'importe quoi avec les barrières ! Genre faire une "memory barrier from the bottom to the top" qui n'a juste aucun sens !
De quoi parles-tu ? Du code de Nazara ? (Si oui, de quel endroit ?) et aussi, depuis quand étudies-tu Vulkan ?
Mais c'est juste que quand on regarde les codes sources, article sur internet (GPU Open), Sascha Willems, Vulkan tutorial, sur les barrières de mémoires ils écrivent n'importe quoi à certains moments. Du coup je voulais t'éviter que tu écrives ce genre de choses en ne sachant pas vraiment ce qu'il se passe ;).
Je m'explique : GPU Open n'écrit pas n'importe quoi mais le suggère (enfin je trouve), je cite ce qui est écrit pour une barrière BOTTOM TO TOP :
This transition expresses that every command currently in flight on the GPU needs to finish, then the transition is executed, and no command may start before it finishes transitioning. This barrier will wait for everything to finish and block any work from starting. That’s generally not ideal because it introduces an unnecessary pipeline bubble.
Ce qui est écrit est clairement vrai, mais tu peux (enfin j'ai compris au début) comprendre que les accés mémoires en écriture effectué de la première commande sont rendu disponible lorsque toute la première commande atteint le BOTTOM, et qu'ils sont visible lorsque la seconde commande en est au TOP. Ce qui est actuellement faux étant donné que BOTTOM / TOP. La seule façon de faire une barrière bloquante sur tous les stages est de faire ALL_COMMANDS to ALL_COMMANDS (ce qui est relativement lent je te l'accorde ). Mais ils n'auraient jamais créés TOP/BOTTOM si ils pouvaient remplacer ALL_COMMANDS ;). D'après ce que j'ai pu lire sur github, le fait que les spécifications ne sont pas claires à certains moments, voir fausses (mais corrigées depuis) y est surement pour quelques choses.
Pour Sascha Willems, il transitionne ses images avec une barrière mémoire TOP to TOP. Ce n'est pas "correct" dans pas mal de cas (même si c'est sûrement "suffisant" dans les cas qu'il utilise), mais vu le nombre d'exemples qu'il a fait, on peut admettre que du lazy programming / ainsi que les spécifications fausses à l'époque n'ont pas du aider à gérer tous les types de barrières mémoires de manières correctes.
Pour Vulkan tutorial, j'ai ouvert des issues sur github pour expliquer en quoi il avait tort.
Il y a aussi les "faux warnings" des validations layers qui peuvent induire en erreur. Genre le validation layer te dit d'utiliser HOST_WRITE lorsque une image est PREINITIALIZED, ce qui est TOTALEMENT FAUX (car elle a déjà été faite) et qui est un bug des validation layers ! (j'espère que ma PR sera acceptée x)). Il y a aussi que lorsque tu utilises une ressource en lecture dans la première commande, ils te disent que tu dois utiliser en srcAccessMask le READ_BIT associée, ce qui n'a pas de sens, car tu n'as pas besoin de flush un cache lorsque tu fais une lecture. (Ça ils sont en discussion pour savoir si ils doivent ou non le supprimé).
Depuis quand j'étudie Vulkan, alors j'ai commencé le jour de sa sortie, puis fais une grosse pause (même si je me renseignais / lisait les forums etc). Je dirais que ça fait 2 mois que je bosse sur Vulkan à plein temps ou presque...
Néanmoins, voilà quelques liens qui peuvent être utiles:
C'est très instructif, je garde tes liens au chaud !
Et merci
Désolé du manque de nouvelles dernièrement, j’ai pas mal voyagé (d’ailleurs, bonjour à Ardakaniz, rencontré aux Utopiales de Nantes ).
Aujourd’hui sort enfin la nouvelle version de Nazara, la version 0.2.
Elle corrige tous les bugs connus (à l’exception du RUdp qui se verra corrigé d’ici deux ou trois versions, à cause de sa complexité), et ajoute quelques changements intéressants !
Quelques points marquants:
Le module Physics a été renommé en Physics3D
Le module Physics2D a fait son apparition (Nazara peut maintenant gérer de la physique bi-dimensionnelle rudimentaire).
La configuration NAZARA_UTILITY_THREADED_WINDOW a été remplacée par le style WindowStyle_Threaded (permettant de faire tourner sélectivement des fenêtres dans un thread séparé).
Material, Matrix4, Sprite, Texture, etc. sont maintenant accessibles depuis le binding Lua.
Correction de la compilation d’un shader interne sur les chipset Intel.
Un lien vers le changelog (beaucoup plus complet) et les liens de téléchargement:
J’ai aussi mis en place plusieurs issues sur Github permettant de discuter de certaines fonctionnalités à venir, et voir quand je prévois leurs arrivées. J’ai aussi mis en place un tableau de bord plus complet sur les fonctionnalités à venir, afin de partager ma vision sur l’évolution du moteur.
Comme toujours, vous pouvez venir retrouver la toute dernière actualité/poser vos questions sur le moteur sur le canal dédié à Nazara sur Mattermost ou bien ici même.
Ca serait pas une bonne idée, Microsoft a annoncé qu'ils arrêtaient le C# l’année prochaine. Et Oracle a annoncé que le Java serait encore maintenu quelques années, mais que ca ne serait que du bug fix, il n'y aura plus d'évolutions majeures du langage.
EDIT : ceci est un troll, ce n'est absolument pas vrai, il est inutile de m'envoyer un MP pour demander confirmation...
Pourquoi pas avoir fait le moteur en C# ou en Java ?
Ok, alors même si je vais immanquablement lancer un débat, je t'invite à ne pas répondre ici, on peut argumenter par MP ou sur un autre topic du forum, mais pas ici.
Donc, pourquoi pas Java ou C# ? Pour plusieurs raisons (et je vais même ajouter que ce sont mes opinions personnelles):
Ces langages, même s'ils sont plus performants qu'avant, n'arrivent pas à la cheville du C++ quand il s'agit de performances. J'ai déjà passé des heures à grapiller quelques microsecondes (1e-6, véridique) sur l'emploi de fonctions souvent appelées par le moteur, des langages comme le Java ou le C# ne peuvent pas subir la même optimisation, et ont un environnement plus lourd.
Je suis totalement contre l'idée d'un Garbage Collector Stop-The-World dans ce genre de contexte, comment faire attention à des microsecondes si l'environnement peut arrêter tous les threads pendant plusieurs millisecondes à n'importe quel moment ?
(Java) Je pense également que la compilation AOT est largement supérieure en terme de bénéfices à l'heure actuelle que le JIT (je sais qu'on peut compiler Java en AOT, mais ce n'est pas la tendance).
(Java) Devoir dépendre d'une JVM est selon moi contraire à ce qu'un moteur devrait être.
Le RRID (ou RAII ou RFID) est selon moi l'une des meilleures façons de gérer la mémoire, un garbage collector (selon l'implémentation courante) bouffe énormément de mémoire.
Ces deux langages dépendent de sociétés, je préfère un langage libre comme le C++.
J'aime le C++, de part sa nature multi-paradigme.
J'aime les pointeurs.
Minecraft.
Voilà, c'est tout pour mes opinions totalement personnelles.
× 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.
Moderateur forum || FAQ 3D || discord 3D francophone || OC Tweak script
Moderateur forum || FAQ 3D || discord 3D francophone || OC Tweak script
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Moderateur forum || FAQ 3D || discord 3D francophone || OC Tweak script
Moderateur forum || FAQ 3D || discord 3D francophone || OC Tweak script
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Discord NaN. Mon site.
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)