La technique qu'utilise mon moteur de jeux pour réaliser cela s'appelle dynamic environment mapping!
L'inconvénient c'est que cette technique consomme beaucoup de ressources (je chute à 6 FPS) mais c'est la technique la plus simple que j'ai trouvée sur Internet et le seul tutoriel que j'ai trouvé.
Pour l'instant ça ne fonctionne qu'avec les fenêtres de même dimension parce que une cube map c'est un cube. Je vais chercher une solution pour redimensionner une texture rectangulaire en texture carrée pour la cube map!
Je suis justement entrain de nettoyer le code et de retirer les shaders et uniform que je n'utilise plus.
Je ne connais pas Shadertoy c'est quoi c'est pour tester des shaders ?
EDIT : maintenant que j'ai fais la réfraction je vais entamer la dernière étape, faire un shader pour donner l'impression que l'eau bouge.
EDIT 2 : j'ai essayé sans les erreurs opengl et sans la réfraction, avant ça tournait a plus de 300 FPS et maintenant je suis passé a 36-60 FPS, je ne sais pas ce qui a provoqué cette chute de FPS, pourtant je n'ai rien changé au framework j'ai essayé de retirer les normales que je n'avais pas passé avant au shader mais ce n'est pas ça le problème.
Oui Shadertoy sert à tester, prototyper des shaders, faire des démos, aussi de les partager à la communauté, on peut examiner ceux des autres et en apprendre beaucoup sur leur fonctionnent.
OmbreNoire a écrit:
Il n'y a pas un profiler avec cwc ?
Ça c'est une excellente idée, je vais ajouter ça pour la prochaine version
GZE, un moteur multiplateforme, adapté pour de la 2D, 3D et création de logiciels.
Bon j'ai optimisé un petit peu en remplaçant les copies d'images par une cubemap attachée à un FBO du coup, je ne fais plus de copie, mais je ne gagne que 2 FPS.
EDIT : j'ai aussi rajouté un shader pour donner l'impression que l'eau bouge par contre je n'ai pas réussi à faire varié la couleur de l'eau.
EDIT 2 : peut être devrais je "caster" un rayon sur une image comme sur le lien que tu m'as donné mais je n'y comprends rien à se shader ça m'a l'air beaucoup plus compliqué à faire.
EDIT 3 : j'ai un résultat étrange, pas le même à chaque exécution
Ah ouai, probablement quelque chose qui n'est pas initialisé (qui prend une valeur aléatoire de la mémoire)
Pour le Shadertoy c'est du raymarching, ce qui est un peu différent du raytracing oui, mais hésite pas à faire une recherche parmi les shaders, il y a une tonne de références
Il y a un projet assez impressionnant, similaire au tien, qui serait une également une bonne référence: ALAG Engine
La différence c'est qu'il n'utilise pas d'objets semi-transparent ce qui simplifie grandement les choses. Je suis d'avis que la semi-transparence est une des chose les plus complexe et lourde à traiter.
GZE, un moteur multiplateforme, adapté pour de la 2D, 3D et création de logiciels.
Ah ouai, probablement quelque chose qui n'est pas initialisé (qui prend une valeur aléatoire de la mémoire)
Pour le Shadertoy c'est du raymarching, ce qui est un peu différent du raytracing oui, mais hésite pas à faire une recherche parmi les shaders, il y a une tonne de références
Il y a un projet assez impressionnant, similaire au tien, qui serait une également une bonne référence: ALAG Engine
La différence c'est qu'il n'utilise pas d'objets semi-transparent ce qui simplifie grandement les choses. Je suis d'avis que la semi-transparence est une des chose les plus complexe et lourde à traiter.
La cubemap est correcte c'est lorsque je dessine sur la texture 2D en appliquant mon shader de réfraction qu'il y a un soucis pourtant je clear bien la texture donc tout doit être initialisé en mémoire avec la couleur transparente (0, 0, 0, 0) et j'écris bien le pixel de la couleur de la cubemap en mémoire avec le vecteur directeur de la réfraction pour les objets "réfractable". Ca va être dur à déboguer, là je sèche, je n'ai pas d'idée, jamais eu ce problème ni avec ma texture de lumière, ni avec ma texture d'ombre et ni avec la texture de la scène.
Toujours aussi impressionnant ce qu'arrive à faire Grégoire en peu de temps en plus, j'ai travaillé un peu avec lui sur le projet holyspirit, mais je n'ai plus de nouvelles de lui depuis longtemps et je vois que son post date de 2018. (Bref je vois que ce qu'il fait est similaire à ce que je fais sauf que lui il utilise de la 2.5D moi j'essaye des techniques pour que ça fonctionne en 2D et en 3D).
Bref, pour la suite, je compte continuer le projet ODFAEGCreator, tout d'abord je vais me contenter de faire un éditeur de niveaux, mais, si j'ai le temps et la motivation je compte faire quelque chose de similaire au moteur de jeux Unity pour coder le moins possible et avoir des scripts que se modifie tout seul en fonction de ce que je veux faire.
Pour rappel le but de ODFAEG n'est pas seulement de créer un moteur de jeux mais aussi de pouvoir créer des applications en 2D et en 3D, en effet, j'utilise ODFAEG pour la démo en 2D, la démo en 3D et ODFAEG Creator.
Ce qui pourrait être une bonne idée aussi c'est d'essayer de faire du raytracing avec des "compute shader" mais ça c'est pas pour tout de suite.
Le fait que ça soit que 2.5D lui a permis de sauver beaucoup de temps et aussi en performance. Comme par exemple transformer du high poly en "pré-computé" (heightmap, normales, etc)
Je suis du même avis, le "compute shader" est essentiel pour faire du raytracing performant, puisque ça ne suis pas vraiment le pipeline traditionnel.
Aussi, pense à utiliser Renderdoc, c'est essentiel pour déboguer le GPU.
GZE, un moteur multiplateforme, adapté pour de la 2D, 3D et création de logiciels.
Le fait que ça soit que 2.5D lui a permis de sauver beaucoup de temps et aussi en performance. Comme par exemple transformer du high poly en "pré-computé" (heightmap, normales, etc)
Je suis du même avis, le "compute shader" est essentiel pour faire du raytracing performant, puisque ça ne suis pas vraiment le pipeline traditionnel.
Aussi, pense à utiliser Renderdoc, c'est essentiel pour déboguer le GPU.
Ha, je n'aime pas trop faire du "pré-computé" pour les objets statique ok mais pour les objets dynamiques je ne vois pas trop comment faire parce que si le personnage bouge l'environment map change, hors que sur les images qu'il a montré je ne vois que des objets statiques.
Lorsque je lance l'app avec renderdoc elle se lance puis se ferme, je n'ai pas ce problème avec gDEBugger mais il se passe un truc étrange c'est que quand j'affiche les FBO avec gDEBugger elles affichent toutes la même texture pourtant ce n'est pas toutes les mêmes texture que je lie à mes FBO. (Et j'ai tout simplement repris la classe FBO de la SFML que j'ai amélioré un peu pour pouvoir attacher des cubes maps)
EDIT : je crois que j'ai trouvé le problème mais je ne sais pas comment le résoudre, mon shader de réfraction s'exécute avant que la cubemap aie fini de se dessiner du coup il prend une couleur aléatoire de la cube map. Pourtant j'ai bien appelé glMemoryBarrier et glFinish.
EDIT 2 : j'ai essayé d'ajouté ça après avoir dessiné la linked list :
T : Bon j'ai réussi à viré cette FATAL error de memory allocation, j'ai juste réduit la taille du SSBO pour les "per pixel linked list" en remplaçant ça :
Je ne comprends pas j'ai une VRAM de 6 GB et quand je crée une "per pixel linked list" de 20 pixels de profondeur l'allocation échoue.
Cependant j'ai toujours ce problème de réfraction texture qui ne s'affiche pas bien comment je fais pour débogué ça avec RenderDoc ? Lorsque je clique sur capture frame l'application se ferme!
EDIT : bon il fallait lancé l'application en mode debug maintenant je ne sais pas comment utiliser RenderDoc pour voir ce qui cloche.
EDIT : Bon j'ai essayé de capturé une frame mais les textures sont toutes noire dans le texture viewer c'est bizarre.
Bon j'ai mis 5, puis pour les textures noir, j'ai l'impression qu'il faut choisir la bonne texture et le bon moment d'affichage, c'est à dire après le "glClear" et après avoir dessiné quelque chose.
Ça fonctionne pour moi en "release"
GZE, un moteur multiplateforme, adapté pour de la 2D, 3D et création de logiciels.
Bon j'ai reporté ce bug à nvidia j'espère qu'il sera rectifié prochainement je ne trouve pas d'erreurs dans mon code.
Du coup je suis bien dèg j'achète du nouveau dans l'espoir d'avoir un meilleur FPS et que ça marche bien mais là..., mais bon, ça me le fait pas à toutes les exécutions mais faut relancer c'est embêtant.
En attendant je continue le développement de ODFAEGCreator, j'ai corrigé un bug dans la classe DropDownList.
J'ai retiré une méthode déclarée mais non définie dans la classe Shape et j'avance petit à petit sur ODFAEGCreator et j'ai décidé, contrairement au précédent éditeur, de faire un seul outil à la place de 3 pour ajouté des entités, les supprimer ou tout simplement les sélectionner, bref, pas envie de me casser la tête avec un tas d'outils, juste envie de faire quelque chose de très simple.
Il n'y aura qu'à créer un rectangle de sélection et dans ce rectangle on pourra soit :
-Ajouter des entitiés.
-Supprimer des entités.
-Sélectionner des entités pour changer la couleur, la texture, etc...
Je n'ai pas encore d'idée pour la création d'animations par contre.
Cependant, je ne suis pas très motivé, en fait, je vais pouvoir faire un éditeur de map voir même un éditeur de script comme Unity mais le problème c'est que je n'ai pas d'idées de gameplay pour un jeux, pour, les compétences par exemple, si j'avais une équipe j'aurai pu faire directement un jeux avec le moteur et puis l'éditeur mais comme je bosse seul, tant pis!
Salut, tu t'es lancé dans un projet est assez gros, par contre ça peut faire peur à certain pour monter un équipe.
Ce que je conseil c'est de simplifier ton projet, et quand je parle de simplifier je dis bien de simplifier au maximum, car en fait un projet peut devenir complexe très vite, si ce n'est pas de façon exponentiel.
Au final c'est bien peu motivant, et tu te mets beaucoup de poids sur les épaules (je parle par expérience)
Voici mes conseils:
Les Shaders:
Il est mieux de bien séparer les Shaders de ton code, dans des fichiers à part, pour plusieurs grande raisons. C'est non seulement plus clair de cette façon, mais il est possible de pré-compiler les shaders et de voir les erreurs directement, au lieu d’être dans un phase au runtime (quand ce n'est plus vraiment le temps de corriger les erreurs)
Il est beaucoup mieux de faire des shaders générique, par exemple on écrit nos shader dans un langage uniforme GLSL 330 puis on le convertie en SPIR-V, ensuite on choisie notre backend comme Metal ou D3D11 etc...
Ce qui est bien plus portable et évite de devoir trouvé toute sorte de hack et correspondances.
Ici le projet sokol-shdc permet tout ça directement et bien plus, comme par exemple la possibilité d'inclure des sous-shader (ce qui est essentiel).
La Modularité
Il est bien plus intéressant d'avoir des petits modules qui fonctionnent indépendamment, c'est non seulement plus simple, mais tu as meilleurs chances de succès. Bien rendre indépendant chaque partie permet au autres développeur de contribuer plus facilement et tu peux remplacer des morceaux à ta guise. Si tout est inter-d’épandant tu risque d'avoir quelque chose de difficile à maintenir.
Ici je conseille fortement un style ECS et en tout particulier le projet flecs
Quoi de plus satisfaisant que ne ne pas partir de rien, sans avoir à passé beaucoup trop de temps pour un maigre résultat
Ici la lib Sokol est ultra simple d'utilisation et très solide. Ce servir d'une lib qui est en constante évolution donne l'impression de travailler en équipe, on peut y contribuer, l'auteur peut ajouter de nouvelles fonctionnalités et corriger les bugs trouvé. Il n'y a que des avantages
Tu as développé une grande expérience en développement GPU. Je voie que tu t’intéresse en particulier aux Linked-list, utilise ce que tu connais pour contribuer et faire sortir le potentiel de ces ressources, il faut éviter de nager à contre courant. Tu vas pouvoir développer beaucoup plus rapidement de cette façon et surtout de manière plus valorisante.
Bien entendu ce ne sont que des conseils dans le but de te donner un peu d'inspiration.
Bonne continuation
- Edité par Maeiky 13 novembre 2020 à 4:34:44
GZE, un moteur multiplateforme, adapté pour de la 2D, 3D et création de logiciels.
Merci pour tes conseils mais j'ai déjà tellement donné rien que pour le framework et je n'ai plus le courage pour le reste même pour des petits projets je n'ai plus de courage.
Les shaders je ne les ai pas mit dans des fichiers parce que lorsque j'utilise le framework dans un de mes projets, le chemin d'accès vers les fichiers change, donc, il ne trouve plus les fichiers pour compiler mes shaders, je n'ai pas ce problème en les chargeant avec la mémoire.
J'ai décomposé le framework en 7 parties indépendantes :
-Le cœur avec les fonctionnalités utilitaires.
-Le module fenêtre.
-Le module mathématique.
-Le module physique.
-Le module graphique.
-Le module réseau.
-Le module audio.
Et certaines de ces parties peuvent communiquer entre elles grâce à une classe statique.
Au niveau du design j'ai imaginé un système Entités, composants, systèmes et monde.
-Les entités : tout objet du framework dessinable et transformable. (tuiles, mesh, animations, etc...)
-Les composants : Ils permettent de dessiner les entités en utilisant des shader par exemple, l'utilisateur peut créer ses propres composants si il veut utiliser ses propres shaders. (Composant de rendu pour les ombres, composant de rendu pour les lumières, composant de rendu pour "l'order independant transparancy", composant de rendu pour la réfraction, etc...)
Il y a deux types de composants :
-Les composants lourd c'est à dire ceux qui affichent des entités à l'aide de shaders dans un ou plusieurs FBO pour ensuite dessiner le rendu final sur la fenêtre principale.
-Les composants léger qui ne sont autre que des GUI (boutons, combo box, etc...) qui sont dessiné sur la fenêtre principale.
Ensuite on a :
-Les systèmes : Ils mettent à jour les entités comme par exemple les animations ou encore les entités visible du monde. (L'utilisateur peut créer ses propres systèmes)
Il y en a de deux types :
-Les timers qui mettent à jour les entités toutes les x temps.
-Les workers qui mettent à jour les entités quand l'utilisateur le veut.
Et enfin on a :
-Le monde : Cette classe contient toutes les entités, tous les systèmes et tout les composants, c'est cette classe qui fait le lien entre tout les objets du framework et c'est aussi cette classe qui contiennent toutes les scènes, l'utilisateur peut créer sa propre classe pour gérer les scènes. (je les gère à l'aide d'une grille et pour l'instant c'est suffisant mais l'utilisateur pourrait utiliser un quadtree ou un bsp-tree)
Ensuite il y a un tas d'autres classes telle que la classe application par exemple dont on peut hériter et qui se charge de tout (passer les évènements aux composants, dessiner les composants sur les fenêtres, etc...) mais on est pas obligé de passé par cette classe surtout pour des plus petits projets on peut utiliser le framework comme si on utilisait la SFML.
J'ai voulu en plus laissé le choix à l'utilisateur de la bibliothèque à utilisé pour le fenêtrage par exemple (la SFML, ODFAEG, etc...) en créant des interfaces.
Bref, il y a pleins de fonctionnalités et de possibilités qu'offre ce framework, moi même, je n'ai jamais pu toutes les testés car il me faudrait :
-Plus de graphismes.
-Un éditeur de maps voir même de scripts.
Je m'intéresse beaucoup aux linked list et c'est un sujet qui me passionne car je trouve ça tellement pratique, malheureusement, j'ai des problèmes avec les linked list surtout lorsque j'utilise une texture dans un shader qui a été dessinée avec une linked list. (C'est le cas lorsque j'utilise la cubemap dessinée avec une linked list dans mon shader de réfraction, je n'ai pas ce problème si je n'utilise pas de linked list, je crois que utiliser une liked list crée des problèmes de mémoire au niveau du GPU et ça à l'air d'être plus lent mais bon c'est mon choix parce que j'aime ça mais je suis un des seul à les utiliser.)
Mais bon je vais essayer de trouver le problème en espérant que ça ne soit pas un soucis du driver parce que sinon je ne peux rien faire mais ça me surprendrais quand même que le problème vienne du driver.
Mais il faut aussi que j'avance sur l'éditeur de map, en effet, le jeux étant déjà bien avancé il me faudra faire des maps pour ajouté de nouveaux lieux, de nouveaux monstres et de nouvelles quêtes.
Il me faudra aussi, avec l'éditeur de map, déterminer la zone de combat des monstres, créer des quêtes, etc..., pour l'instant je fais tout ça dans le code mais le code peut vite devenir très lourd surtout si je ne sauvegarde pas tout ça dans un fichier ou une base de donnée.
Mais vu la masse de travail et que je n'ai plus d'équipe, ça devient vite démotivant et l'impression de ne pas pouvoir finir tout ça à temps.
Avant, ça ne me dérangeait pas de programmer toute la journée et une partie de la nuit et c'est pour cela que j'avait visé un projet ambitieux mais là j'ai besoin de plus d'air et je n'imaginais pas à l'époque que ce projet aller devenir si lourd.
Utiliser le framework c'est plaisant mais faire cet éditeur de map ça me semble rébarbatif, utiliser les guis pour créer, modifier du texte (les scripts), bref, il n'y a rien de plus chiant.
Ah oui c'est certain que ta mis pas mal d'effort dans ce projet, et je te comprend d'avoir mal au cœur de laisser tout ça de coté.
Par contre tu essais de tout faire toi même, dans ce cas c'est certain que l'avancement ne sera pas aussi rapide que souhaité.
Hésite pas à te servir de ressources externes, par exemple tu peux commencé par utilisé Tiled pour tes maps. Ensuite si ton projet évolue suffisamment et que Tiled ne te convient plus, bien c'est à se moment qu'on peut se lancer dans son propre map editor.
Comme pour ta GUI, la plupart des gens utilise ImGUI, et c'est pas pour rien, c'est simple, beau, ça fait la job. Ensuite c'est facilement remplaçable.
En utilisant des ressources externe ça permet aussi une séparation claire entre les modules et fonctionnalités.
Ton projet repose sur des appels direct d'OpenGL et ce n'est pas vraiment une bonne chose. Il y a trop de variante d'OpenGL et ce n'est pas très portable. Même chose pour les Shaders, n'oublie pas que le monde de la programmation évolue très vite et gérer toutes c'est petite évolution demande du temps.
C'est pour ça que je te conseil d'utilisé une lib tierce, cette lib va gérer toutes c'est petite évolution pour toi, ce qui va te sauvé un temps infini.
Je crois sincèrement que tu devrais prendre les meilleurs éléments de ton moteur et les transposés, vers une nouvelle base. Au final tu va sauver énormément de temps, et probablement que tu vas te dire que c'est le meilleurs move que ta fais par la suite.
Garde en tête qu'en programmation tout évolue très vite, il faut que tu soit capable de te retourné sur un 10 cent.
Prend le temps de regarder les exemples wasm de Sokol, un peu d'air frais ne fait pas de mal, remarque à quel point ces exemples demande peu de code, le tout tien toujours dans un seul fichier. Toute la gestion des shaders est simplifier au maximum. Et c'est portable sur une multitude de plateforme.
Utiliser cette lib ne te demandera que quelques heures de travaille, ensuite tu pourras transposé tes morceaux tranquillement et faire un petit ménage par la même occasion. Tu n'as rien à perde, bien au contraire tu vas développer plein d'outils et de nouvelles façons de travailler.
GZE, un moteur multiplateforme, adapté pour de la 2D, 3D et création de logiciels.
Ok bon je suis entrain d'essayer de résoudre ce problème avec la réfraction texture et j'ai remarqué que lorsque j'utilise une "per pixel linked list" ma skybox ne se dessine plus dans le FBO, et donc, j'ai un cube tout noir je crois que le problème vient de là bien que en utilisant les classes du framework ça affiche quand même quelque chose mais pas toujours ce qu'il faut.
EDIT : bon ça y est ma skybox se dessine correctement maintenant mais ça ne me dit toujours pas pourquoi ma texture de réfraction ne se dessine pas bien. :/
- Edité par OmbreNoire 14 novembre 2020 à 17:09:21
Bon, je crois que le problème vient du fait que j'ai des GL_OUT_OF_MEMORY_ERROR alors à mon avis, c'est pour ça que la texture de réfraction ne s'affiche pas toujours bien. Je n'ai pas l'impression d'avoir 6GB de VRAM on dirait qu'il y a une limite au niveau du nombre de bits que je peux allouer et je ne sais pas comment changer cette limite.
Bon mauvaise nouvelle pour la texture de réfraction qui ne s'affiche pas toujours bien on dirait que c'est mon driver qui bug la valeur du vecteur r dans le shader varie à chaque frame parfois le vecteur est null, parfois pas alors quand le vecteur r est null forcément ça n'affiche pas bien la texture de réfraction parce que j'envoie un vecteur null comme coordonnée de texture pour la cubemap du coup il affiche un pixel au hasard et toujours le même.
Ca valait la peine d'acheter un nouveau PC..., j'espère qu'ils vont corriger ce bug sinon autant vendre mon nouveau PC j'ai pas envie de le garder rien que pour jouer.
Mais il faudrait tester avec un autre driver que ce "game ready driver".
- Edité par OmbreNoire 21 novembre 2020 à 18:31:20
Voilà que j'arrive par hasard ici et je vois qu'on parle de ALAG. Alors oui l'idée était de faire du prérendu pour avoir un rendu "old-school" que je cherchais, mais c'est facile d'ajouter de la 3D (d'ailleurs la version Vulkan que j'ai écrite après le fait sans soucis). De toute façon, les plupart des effets sont calculés en screen-space (prérendu oblige). Par contre, j'avais une gestion basique de la transparence en faisant tout simplement 2 couches, et en estimant qu'en général il n'y a pas plusieurs objets semi-transparent qui se chevauchent (et quand ça arrive je fais simplement un alpha blending dessus et c'est good enough).
Mais j'ai mis ce projet de côté car c'était trop demandant pour moi de faire des modèles 3D en haute définition et j'ai repris les bases du "moteur" (si on peut vraiment appeler mon bricolage un moteur) pour faire ce petit projet sans prétention. Au moins, il y a du gameplay, donc c'est gratifiant.
Ton problème Laurent je pense, c'est que la complexité de base de ton projet est telle qu'il est très dur de prototyper dessus (tu ne sais pas si les bugs que tu obtiens sont du aux bases bancales de ton moteur ou à ton prototype, probablement les deux). Donc c'est normal que tu n'arrives pas à implémenter correctement quelque chose comme des réflexions (et d'ailleurs, tu n'y arriveras jamais vraiment bien en 2D iso si tu n'as pas plus d'info sur la position 3D de tes fragments). Ce que tu devrais faire, c'est prototyper sur une base minimale (quitte à prendre un moteur de rendu ou quelque chose du genre), et une fois que tu es à l'aise avec ce que tu veux implémenter tu peux voir pour le faire dans ton moteur (et probablement que tu auras appris des choses et voudra rechanger ton moteur au passage).
Voilà que j'arrive par hasard ici et je vois qu'on parle de ALAG. Alors oui l'idée était de faire du prérendu pour avoir un rendu "old-school" que je cherchais, mais c'est facile d'ajouter de la 3D (d'ailleurs la version Vulkan que j'ai écrite après le fait sans soucis). De toute façon, les plupart des effets sont calculés en screen-space (prérendu oblige). Par contre, j'avais une gestion basique de la transparence en faisant tout simplement 2 couches, et en estimant qu'en général il n'y a pas plusieurs objets semi-transparent qui se chevauchent (et quand ça arrive je fais simplement un alpha blending dessus et c'est good enough).
Mais j'ai mis ce projet de côté car c'était trop demandant pour moi de faire des modèles 3D en haute définition et j'ai repris les bases du "moteur" (si on peut vraiment appeler mon bricolage un moteur) pour faire ce petit projet sans prétention. Au moins, il y a du gameplay, donc c'est gratifiant.
Ton problème Laurent je pense, c'est que la complexité de base de ton projet est telle qu'il est très dur de prototyper dessus (tu ne sais pas si les bugs que tu obtiens sont du aux bases bancales de ton moteur ou à ton prototype, probablement les deux). Donc c'est normal que tu n'arrives pas à implémenter correctement quelque chose comme des réflexions (et d'ailleurs, tu n'y arriveras jamais vraiment bien en 2D iso si tu n'as pas plus d'info sur la position 3D de tes fragments). Ce que tu devrais faire, c'est prototyper sur une base minimale (quitte à prendre un moteur de rendu ou quelque chose du genre), et une fois que tu es à l'aise avec ce que tu veux implémenter tu peux voir pour le faire dans ton moteur (et probablement que tu auras appris des choses et voudra rechanger ton moteur au passage).
Rha j'ai presque réussi la réfraction c'est pas ça, je sais que je peux y arriver, c'est juste que à chaque exécution la texture de réfraction ne s'affiche pas toujours bien parce que parfois le vecteur r est null, mais contrairement à toi j'utilise des "per pixel linked list" pour gérer la semi-transparence. J'ai presque réussi à faire de la réfraction en 2.5D (et cette technique est facilement adaptable en 3D) d'ailleurs tout ce que je dessine (ombre, lumières, etc...) s'affiche aussi bien en 2D que en 3D.
Mais je ne fais pas de "pré-rendu" comme toi je gère ça de façon dynamique donc c'est plus complexe encore que ce que tu fais en effet.
Mais je ne fais pas de "pré-rendu" comme toi je gère ça de façon dynamique donc c'est plus complexe encore que ce que tu fais en effet.
D'abord je pense que ce que tu essaies de faire c'est des réflexions et pas réfraction (ou alors je n'ai pas bien vu). Et sinon, non ce n'est pas plus dur vu que je travaille en screen space, donc ce que je fais fonctionne autant en 3D qu'en 2.5D. D'ailleurs, j'ai des éléments 3D dans la scène.
Ok bon je laisse tombé pour la réflexion, il y a vraiment un truc qui m'échappe c'est ce vecteur dans ce shader qui de temps en temps est null, de temps en temps pas.
Et puis, c'est assez complexe comme code ce que je fais surtout que je dessine dans un FBO la texture de réflexion, parce que je n'utilise pas la même version d'opengl pour dessiner la texture de réflexion et le sprite du rendu final.
- Edité par OmbreNoire 21 novembre 2020 à 23:41:02
Ca y est la réfraction ou réflexion fonctionne!!! J'ai désactivé l'instanced rendering pour deux raisons :
-Ca n'optimise pas le FPS.
En fait oui ça optimise les FPS (généralement de beaucoup), il ne faut pas ce m’épandre Il faut savoir quel est le goulot d'étranglement. Le CPU ou le GPU? Si c'est le CPU (ce qui est le cas) en effet ça n'aidera pas les FPS.
Puisque tu es sous Windows maintenant, je te conseil vivement d'utiliser Process Explorer pour voir l'utilisation GPU et CPU de ton application
J'ai 4 core sur mon CPU donc 100/4 = 25 [23.20] <-- goulot
Regarde du coté du cache friendly pour optimisé ton moteur.
@Gregouar, tout tes projets sont super et très inspirant, ça me donne quelques idées pour faire quelque chose dans le même style que ALAG, entre autres cette démo, mais j'ai rien d'aussi évoluer qu' ALAG (Si c'est un bricolage, il pourrait réellement devenir un outil intéressant, avec un peu d'amour).
- Edité par Maeiky 23 novembre 2020 à 3:45:34
GZE, un moteur multiplateforme, adapté pour de la 2D, 3D et création de logiciels.
Ok, j'ai réactivé l'instanced rendering et j'ai calculé les normales avec le GPU et non plus avec le CPU, ça résous le problème mais maintenant je vais surtout me penché sur l'optimisation car j'ai un FPS assez bas. (16-22 de FPS quand je l'exécute sans cwc, 6-8 de FPS avec CWC)
Ce sont surtout les environments map qui pompent mais il me semble que le CPU est surchargé pourtant j'essaye de l'alléger au max. (calcul des matrices côté GPU avec l'instanced rendering, calcul des normales côté GPU)
J'ai aussi optimisé en remplaçant les push_back de mes std::vector par des accès indexé avec la méthode resize.
Par contre je ne sais pas ce que c'est les cache friendly faut que je regarde.
EDIT : j'ai mit à jour la documentation ainsi que le premier post, avec la nouvelle fonctionnalité (gestion de la réfraction/réflexion)
Pour la suite il faudra :
-Que j'optimise le framework.
-Que je créer une interface graphique pour le framework. (comme celle de Unity par exemple)
-Et sans doute tenter un rendu optimisé au raytracing avec les "compute shader" certains jeux utilise ce type de rendu.
Bref j'ai encore du boulot avant que ce framework soit reconnu, surtout pour l'interface graphique.
- Edité par OmbreNoire 23 novembre 2020 à 16:49:49
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.