Vulkan ? C'est plus rapide que OpenGL ? Si c'est le cas je crois que ça m'intéresse. Comment ça marche ? Il y a aussi des VBOs ? Des instanciations ? On peut aussi gérer les shaders ? Les effets d'ombres, reflets et éclairage ?
Version imprimable
Vulkan ? C'est plus rapide que OpenGL ? Si c'est le cas je crois que ça m'intéresse. Comment ça marche ? Il y a aussi des VBOs ? Des instanciations ? On peut aussi gérer les shaders ? Les effets d'ombres, reflets et éclairage ?
Vulkan ... c'est "pire" (à prendre en main) :aie:.
Voici un premier guide pour vous : https://vulkan.developpez.com/tutori...plet-debutant/
Vulkan, c'est OpenGL, mais en plus bas niveau. On peut tout faire comme ce que l'on fait en OpenGL, mais avec plus de "précision" (et encore plus de possibilités de se tirer une balle dans le pied). Mais, vous avez déjà une base, donc la migration devrait pouvoir le faire. Eh oui, il y a toujours les shaders et vous pourrez faire tous les rendus que vous souhaiterez (car ce n'est pas l'API qui détermine si on peut faire des ombres et autres).
je n'ai pas regardé en détail cette API mais,sauf erreur de ma part, je pense que le collectif Khronos s'est inspiré de Microsoft avec son Direct3d 10 et versions supérieures où tout le code concernant le rendu est délégué à du code HLSL ( High ShaCitation:
Envoyé par KevinduC
Donc oui si vous voulez migrer sous Vulkan il faudra faire principalement du code GPU et gérer les shaders.
En programmant les Shaders on programme directement le GPU.
L'avantage de Vulkan, je n'y suis pas allé voir mais je pense que c'est comme Direct3d 11 ou 12 c'est possible de faire du multithreading avec du code GPU sur la carte graphique.
Par contre ça demande plus de temps d'apprentissage :mouarf: c'est un bon moyen pour s'occuper lors des longues soirées d'hiver.
Ouch ! Pour transposer mes projets et libs en Vulkan ça va être long !
Bah je ne pense pas du tout qu'il s'inspire de DX10 , techniquement l'équivalent de Vulkan , c'est DX12.Citation:
Envoyé par Mat.M
Ensuite , c'est une lib de AMD qui a inspiré Kronos , mais c'est plus une API qui se veut proche du hardware , ce qui n'est pas le cas de DX10.
c'est malheureusement le prix à payer si vous voulez développer un jeu qui ressemble à Call of Duty ou Far Cry :mrgreen:Citation:
Envoyé par KevinduC
cependant une fois la technologie un peu maitrisée c'est un bon investissement je pense.
J'ai déjà un problème, j'ai bien ajouté "vulkan-1.lib" à mon linker mais Code::Blocks ne trouve pas vkEnumerateInstanceExtensionProperties()
Je laisse tomber Vulkan, c'est incompatible avec Mingw et je viens de passer les 3 dernières heures à tenter de compiler un code tout simple avec Visual Studio mais c'est plein d'erreurs de liage incompréhensibles
Ne pas réussir du premier coup, avoir des erreurs, en informatique, ... c'est la routine. Ce qui fait un bon "informaticien" ou un bon programmeur, c'est de savoir chercher, d'apprendre en continu et de la persévérance.
Bref, ici, c'est un forum d'entraide. Si vous voulez de l'aide, expliquez nous votre problème. Je pars du principe que vous avez suivi le tutoriel que j'ai conseillé plus haut et qui permet une installation avec Visual Studio, mais peut être il n'est pas aussi bon que je le pensais.
J'ai réussi à faire fonctionner Vulkan finalement mais sous Code::Blocks. Perso je garde une image très moyenne de Visual Studio, je n'ai jamais autant galéré pour faire tourner une lib en 10 ans de programmation ! Je suis le tuto mais avec Code::Blocks au lieu de Visual Studio, c'est vraiment particulier, rien à voir avec OpenGL. Rien que pour créer une instance Vulkan c'est délicat
Je me permets de revenir vers vous : C'est un peu hors sujet car ma question est plutôt d'ordre mathématique, je me suis aperçu que c'était principalement un calcul de physique qui ralentissait mon programme : Dans le jeu on est censé contrôler un véhicule et pour que ce dernier suive la route il faut que le programme calcule en permanence si la voiture se trouve ou non sur tel ou tel triangle composant chaque route. Pour cela j'utilise un calcul d'angles qui passe par la fonction acos() et c'est apparemment cette dernière qui est coûteuse car dès que je la supprime le programme augmente considérablement. J'ai essayé de remplacer cette fonction par l'utilisation d'une map qui contient les valeurs des angles pour des cosinus allant de -1 à 1 mais il s'est avéré que ce n'était pas plus rapide. Est-ce que vous auriez des astuces pour déterminer si un point est dans un triangles sans passer par des cos, sin, acos, racines ... ?
Ah ben acos est effectivement super long.
Tu n'as pas besoin de faire acos pour faire des collisions point/triangle , il suffit juste de savoir si ton point est entre deux coté.
en image ça donne ça :
https://www.zupimages.net/up/21/44/4g5y.png
Sinon 5seconde sur google et j'ai ça :
http://www.jeffreythompson.org/colli.../tri-point.php
Bref je te déconseille de refaire un moteur physique , si tu n'as pas les bagages nécessaire en terme d’optimisation , et il me semble que c'est pas la première fois que tu as des soucis de ce coté là....
Apres bien sur , si tu fait ton test de collision avec 100 000 triangle , ça m’étonne pas que c'est long ,et ça peut importe l'algo x)
En effet, il serait judicieux de faire un pré filtrage avec une boîte de collision (ou plus simplement une sphère :)).Citation:
Envoyé par Kannagi
Après, je n'ai pas compris. La raison de ces tests, c'est pour que la voiture ne traverse pas le sol? ou pour qu'elle ne sorte pas de la route?
Merci pour le lien. C'est une forme de gravité, pour que la voiture monte et descende en même temps que la route.
Ça permettrait de faire un premier test de manière optimisée si je comprends bien ? Parce que pour le moment il n'y a que deux routes mais lorsqu'il y en aura 50 ce sera pas la même chose ...Citation:
En effet, il serait judicieux de faire un pré filtrage avec une boîte de collision (ou plus simplement une sphère )
Edit : Est-ce que vous pourriez me dire svp comment on peut en arriver à réaliser cela :
https://youtu.be/4M-wfzuCgvs
Des arbres, des ombres, un soleil réaliste et tout cela est fluide
Malheureusement l'algorithme avec la forum de Héron ne fonctionne qu'une fois sur deux, je suis entrain de vérifier s'il n'y a pas une erreur dans la formule mais je ne la trouve nulle part, je ne trouve que des formules différentes qui passent par les longueurs des côtés, et calculer ces longueurs reviendraient à passer par les fonctions sqrt() et pow() et je préfère éviter
Oui enfin refaire le moteur de rendu de UE4 , tu imagine bien que c'est tout sauf simple , et que tu trouvera pas forcément la réponse ici :aie:Citation:
Envoyé par KevinduC
Je t'ai donné deux algo , sur la méthode de heron ne te va pas, tu peux utiliser la première qui est facile à implémenter , mais un peu plus gourmande en calcul ,vu que ça demande de faire quelque div et if.Citation:
Malheureusement l'algorithme avec la forum de Héron ne fonctionne qu'une fois sur deux
comme je l'ai écris dans un message précédent il faut trouver une technique de hiérarchie spatiale peut-être avec des octrees.Citation:
Envoyé par KevinduC
J'aurais bien aimé que mr LittleWhite nous en dise plus là-dessus...:mouarf:
Qu'est-ce que les octrees exactement ? J'ai beau chercher je ne trouve aucune explication précise
Alors le octrees ,c'est pas une technique de rendu ,c'est juste une partition de l'espace pour tester qu'une partie des collisions.Citation:
comme je l'ai écris dans un message précédent il faut trouver une technique de hiérarchie spatiale peut-être avec des octrees.
Et donc oui pour les collisions, il faut utiliser des octrees mais pas que , il faut simplifier les box de collisions et utiliser des algo rapide (donc les acos/cos et compagnie faut oublier ).
et alors comment vous-faites pour repasser par la même boucle pourcompte=0 à nombre_objets_a_afficher pour afficher les objets ?Citation:
Envoyé par Kannagi
je conseille de télécharger le code source de Irrlicht 3d et de s'en inspirer.Citation:
Envoyé par KevinduC
C'est au mieux une technique d'optimisation (pour pas tout tout tester en Viewing frustum culling) , mais ça répond pas à la question : de comment on faire un rendu photo-réaliste.Citation:
Envoyé par Mat.M
Pas jusque là mais quelque chose qui s'approche, pour le moment soit j'utilise des véritables arbres en 3D et si j'en mets plus de 10 le programme devient une tortue, soit j'utilise des surfaces croisées mais bof quoi ...Citation:
Envoyé par Kannagi
Avant de vouloir faire un rendu-photoréaliste il faut d'abord régler le problème de la boucle qui permet d'afficher des objets ça fait 2 ou 3 jours que j'ai abordé le problème.Citation:
Envoyé par KevinduC
Un arbre en billboard c'est quoi deux polygones qui forment uin triangle donc ça coûte quasiment rien au GPU surtout s'il y a 10 arbres.
C'est pas un problème de matrices plutôt ?
On est d'accord que si je veux afficher plusieurs objets dans une boucle soit le GPU soit le CPU vont travailler forcément ?Citation:
Envoyé par Kannagi
Donc si on prend une boucle qui parcourt ne serait-ce que 1000 objets même si on utilise la technique du View Frustum Culling bref calculer si l'objet est contenu dans une zone en 3d ça fait tout de même une boucle.
Non je dis des trucs au pif :roll:Citation:
Envoyé par Mat.M
Pourquoi je parle pas vraiment d'octrees pour son rendu , parce que je doute qu'il a un open world a afficher même une grosse map , moi je répond pour son rendu , et que son rendu , même si tu dis "octree" , ben ça permettra pas faire des ombres , des effets de lumiere ,du PBR et j'y passe.Citation:
Envoyé par Mat.M
et pour répondre à :
Je pense que ça reste quand même un niveau technique très élevé,c'est très compliqué , y'a tres peu de boite qui est capable de faire un rendu 3D proche de UE4.Citation:
Pas jusque là mais quelque chose qui s'approche
(Et du coup si tu veux des collisions et un rendu proche de UE4 , ben je te conseille d'utiliser UE4 directement )
il faut que KevinduC nous donne plus de code sinon on peut pas résoudre le problèmeCitation:
Envoyé par Kannagi
Je me suis renseigné sur les billboards mais une question me tracasse : Apparemment il s'agit de modéliser une surface de sorte à ce qu'elle soit toujours face à la caméra, mais dans ce cas si je regarde l'arbre de dessus il aura le même aspect que si je le regardais de côté, à moins de changer de texture mais dans ce cas il faut prévoir une texture pour la vue de face, de derrière, de droite, de gauche, de haut, sans compter les intermédiaires ... Est-ce que je me trompe ?
Non , le billboards , il faut juste faire une surface (un rectangle par exemple) qui est toujours tourné vers la caméra.
Alors comment on gère la texture dans les billboards pour donner l'impression qu'on regarde l'arbre de face, de dessus ...
ça c'est pas possible , enfin si , mais je vois pas comment ça peut être correct visuellement , je suis étonné qu'on t'ai dit de faire ça pour un arbre complet , à la limite quelque feuille (faire un peu des deux 3D et billboars )
Ben alors je vois pas de solution face à ce problème ...
eeehhh on veut bien vous aider mais d'une part il faudrait comprendre les techniques de base et bien les appliquer sinon ce fil de discussion commence à tourner en rond,j'écris juste ça en passant :mrgreen:.Citation:
Envoyé par KevinduC
Le plus important c'est de procéder méthodiquement et pas-à-pas.
Avant de faire du rendu photo-réaliste si vous voulez afficher des billboards il faut appliquer la technique dont parle Kannagi c.a.d. calculer l'angle entre la caméra et l'objet pour qu'il soit orienté face à la caméra.
Oui mais ça ne servirait à rien car l'aspect de l'arbre serait le même quelque soit le point de vueCitation:
Envoyé par Mat.M
si l'aspect de l'arbre change c'est que vous avez un problème de dessiner un rectangle alors donc on en revient à la question du début on n'est pas plus avancé j'ai l'impression :mrgreen:
Je crois que je me fais mal comprendre : Quand on regarde un arbre de côté ou de haut il n'a pas le même aspect donc comment reproduire cela avec une image identique toujours face à la caméra ?Citation:
Envoyé par Mat.M
Avec une image identique , impossible.Citation:
Envoyé par KevinduC
Et puis c'est pas le but du billboars de faire ça , de représenter de la 3D (justement un billboars c'est de la 2D ) , si tu veux représenter un arbre en 3D , ben tu le fait en 3D :aie:
Alors pourquoi vous me parlez de billboards ? Ça sert à quoi ces billboards du coup ?
Laisse tomber les billboards. Affiche les arbres normalement, avec leur modèle 3d. Prend juste pas des arbres qui ont 10 millions de polygones et ce sera bon. https://www.turbosquid.com/3d-model/free/low-poly/trees
Si tu as une chute de performances en affichant 10 arbres, le problème n'est certainement pas dans OpenGL. :calim2:
Merci pour le lien. J'ai pensé à ma carte graphique et j'ai fait des tests avec Heaven Benchmark et résultat les animations sont fluides.Citation:
Envoyé par Bousk
Après je me rends compte que j'ai plus de fluidité lorsque je désactive l'anti-aliasing
J'ai du retard dans la discussion et tant pis pour les octree Mr Mat.M :D.
Pour l'histoire des billboards, c'est que la technique n'est pas celle qui vous convient, si vous pouvez passer la caméra au dessus d'eux. Il faut comprendre que chaque technique répond à une, ou au maximum deux problématiques mais que comme c'est de la triche, il y aura évidemment des limites qui se régleront en : on ne laisse pas la possibilité à l'utilisateur.
Autrement dit, si vous avez des billboards, ne laissez pas passer la caméra par dessus.
Du coup, je rejoins Bousk : dessinez des arbres en modèles 3D. En plus, avec la technique d'instanciation, vous pouvez en faire encore plus et avec quelques variations de rotation/taille et modèle, ça ne se verra même pas. C'est ce qui se fait dans les jeux vidéos et les experts (et les observateurs) peuvent voir que l'on répète en effet, plein de fois le même modèle.
Maintenant, j'aimerai revenir sur votre méthodologie. Pour faire le photo réaliste... il faut mettre ensemble pas mal de technique. Je ne vais pas toutes les cités (car je vais en oublier), mais en voici quelques unes :
- shadow mapping (pour les ombres) et par la suite, shadow mapping répaties sur plusieurs surfaces (j'ai oublié le nom de la technique, pour faire le shadow mapping du soleil) ;
- lens flare
- si effet de jour et de nuit, un shader de teintage du rendu ;
- instanciation (pour avoir plein de modèle dans la scène) ;
- ... maintenant je vais voir la vidéo
- god rays ;
- bloom (c'est un shader) ;
Et tout ça, ça repose notamment sur :
- les shaders ;
- les FBO ;
- l'instanciation ;
- le frustrum culling ;
- les billboards ;
- du level of detail ;
- les particules ;
- skybox
- multi texturing.
On voit clairement dans la vidéo la réutilisation du même modèle pour le palmier et le caillou.
Aussi, ils n'ont pas de physique à gérer ;).
Maintenant, il faut une bonne organisation. Je ne sais pas si c'est la meilleure que je vais proposer, mais vous pouvez par exemple essayer chacune des techniques dans un projet bac à sable, pour la prendre en main et comprendre comment elle fonctionne et par la suite, vous pouvez l'intégrer à votre moteur.
Mais pour réussir un moteur... il faut avoir raté un moteur :aie:. C'est comme pour réussir un jeu vidéo, il faut en avoir déjà raté un ou plusieurs :aie:. De chaque essai on apprend et à la prochaine itération, on construit mieux, on architecture mieux, afin que tous les éléments s'assemblent correctement.
Merci pour cette explication. J'en profite pour vous dire qu'il y a des moments où je me demande si OpenGL ne se fout pas de moi ... Exemple : J'ai modélisé des routes dans mon projet grâce à Blender, j'en ai deux et cela fait 467200 triangles et le programme est fluide, je viens d'en ajouter une et cela fait 473200 triangles et bien résultat : Le programme fonctionne en une image toutes les trois secondes ... Je la retire et copie une route déjà présente, cela fait 669200 triangles soit bien plus, et là le programme redevient fluide. Je garde que deux routes dont celle que je viens d'ajouter et c'est fluide également. Impossible de tirer des conclusions de cela, le problème ne semble pas venir du nombre de sommets, ni du nombre de textures qui ne dépasse pas 32, ni des textures elles-mêmes ...
C'est quoi ce bordel ...