Version imprimable
ça dépend , les calcul de vertex , c'est assez rapide , et si ton objet est loin , il va ignorer pas mal de vertex et de pixel à draw.
Par contre si tu es proche et que ton shader est lent , alors oui ça sera long et ça se verra , mais on peut pas savoir par rapport au info que tu nous donne .
Bon en fait c'est cette gravité apparemment qui pose problème, sans doute à cause du acos(), je suis entrain de tester.
Edit : C'est bien acos() le coupable
Je t'ai pourtant bien dit d'oublier acos...Citation:
Envoyé par KevinduC
Le second point que tu devra apprendre (pour éviter de perdre du temps à tout le monde) , c'est que tu apprends à debugger ton code d'un point de vue des performance et donc savoir ce qui doit être optimisé ou pas.
Quand tu aura fait ce taff ,tu reviendra nous voir.
Ah désolé pour la perte de temps ...
bonjour Kevin vous devez mal utiliser Open GL sans doute les matrices de transformation.
Voilà le résulat que j'obtiens avec Visual Studio + Direct X9 pas de shaders pas de code GPU juste un rendu basique le brouillard est activé,aucune optimisation.
Il y a 1200 billboards dans ma scène, deux "meshes" le sol et le ciel dans le fon c'est juste deux tuiles, c'est assez fluide et en fenêtré.
La végétation c'est création perso.
En plein écran évidemment ça bombarde et je peux monter certainement à plus de 2000 billboards j'ai pas testé encore :mouarf:
sinon LittleWhite mentionne le multitexturing ça c'est un truc primordial si on veut avoir un bon rendu photo-réaliste.
Au besoin c'est limite être contraint d'utiliser un truc comme Substance Painter évidemment un outil payant.
Pièce jointe 607957
autre exemple
Pièce jointe 607958
J'utilise déjà le multitexturing, j'ai par exemple deux textures dans le cas des arbres : Une pour l'écorce et une pour les feuilles. Mais je pense que le problème vient du modèle d'arbres qui était trop lourd : Sans m'en rendre compte il y avait plusieurs milliers de sommets pour un exemplaire d'arbres alors instanciation ou pas je pense que ça devient lourd pour le GPU au bout d'un moment. Sinon je n'ai pas le code à portée de main mais voici comment je procède pour générer les arbres :
Avant le rendu :
- Initialisation des coordonnés de sommets, de texture, normales et autres attributs
- Chargement des textures
- Chargement du shader
- Création VAO
- Allocation mémoire vidéo avec glBufferData()
- Mise en mémoire vidéo avec glBufferSubData()
- Initialisation attributs avec glVertexAttribPointer()
- Activation attributs avec glEnableVertexAttribArray()
- Config instanciation avec glVertexAttribDivisor()
Pendant le rendu :
- Activation shader avec glUseProgram()
- Bindage textures et multitexturing avec glActiveTexture() et glBindTexture()
- Envoi textures, matrices et autres éventuels paramètres avec glUniform*()
- Bindage VAO avec glBindVertexArray()
- Rendu avec glDrawArraysInstanced()
Pour le moment j'ai un peu mis les arbres de côté car ce n'est pas la priorité de mon projet, je me concentre plutôt sur les routes et en particulier sur la notion de octrees pour avoir une gravité optimisée car il y a plusieurs centaines de milliers de triangles composant ces routes et ça donne une boucle avec autant d'itérations par frame donc c'est assez lourd.
Pour les routes ... hum ... je pense que d'habitude, on n'utilise pas un modèle 3D pour ça. J'aurais cru que c'était juste une texture sur le sol (sauf si vous faites des routes aériennes/futuristes à la F-ZERO GX). Bref, pour moi, une route, comme dans les jeux de rally, c'est juste du modelage du terrain sur lequel on "trace" une texture de route et les fossés sur le côté en faisant un creux.
J'ai pensé à cette méthode mais il faudrait stocker des données comme le tracé des routes et trouver un moyen d'envoyer ces données au fragment shader. J'aimerais procéder de cette manière car je m'aperçois qu'il y a un problème de précision entre Blender et mon programme :Citation:
Envoyé par LittleWhite
Pièce jointe 607991
(Blender)
Pièce jointe 607992
(Programme)
Je crois que c'est parce que j'ai des valeurs comme -16969.662109 dans mon fichier .obj qui deviennent -16969.7 par exemple
bonsoir Kevin si vous voulez qu'un véhicule suive une route, une astuce un peu basique c'est de placer des objets un peu au-dessus de la route par exemple de bêtes cubes qui ne seront pas affichés.
Ensuite le véhicule pour suivre la route devra passer par chacun de ces cubes, il suffit de parcourir une liste qui mémorise ces cubes.
Pour la trajectoire du véhicule, il faut encore une fois calculer l'angle entre le cube suivant et le véhicule,le véhicule étant orienté selon cet angle.
Après la trajectoire du véhicule sera calculée avec positionX=cos(angle)+position_precedenteX et positionY=sin(angle)+position_precedenteY
Oh le joli z-fighting ! (Pas étonnant, avec les nombres que tu donnes)Citation:
Envoyé par KevinduC
Il faut savoir que le depth buffer a une précision limitée, du coup il faut ruser (scaling de la scène, ajustement des near/far planes de ta caméra, notamment)
As-tu comparé les valeurs binaires, pour affirmer ça, ou tu as juste affiché sans te soucier de la précision lors de l'affichage ? (ça se configure, que ce soit avec printf ou std::iostream)Citation:
Envoyé par KevinduC
Non ce n'est pas un conflit de profondeur car quelque que soit l'angle sous lequel on observe la scène on voit que la route est bien sous le sol :
Pièce jointe 608116
Effectivement il n'y a apparemment pas d'erreur de précision dans la lecture du fichier car si je fixe la précision de std::cout à 6 chiffres après la virgule j'obtiens bien les mêmes valeurs donc je ne vois pas d'où vient cette erreur dans le rendu. Mais c'est pas grave, je vais tricher et aplanir le terrain
