Moi je l'ai déjà vu :DCitation:
Envoyé par Heptaeon
Sinon, ce cher Bafman nous offre même les sources d'un de ces premiers essais de moteur sur son site : http://michel.deverdelhan.free.fr/ (il faut aller voir poutrage de loutres :lol: )
Version imprimable
Moi je l'ai déjà vu :DCitation:
Envoyé par Heptaeon
Sinon, ce cher Bafman nous offre même les sources d'un de ces premiers essais de moteur sur son site : http://michel.deverdelhan.free.fr/ (il faut aller voir poutrage de loutres :lol: )
Hey bonjour Les gens!!!!
(pour info je suis le deuxième codeur qui travalle avec Bafman)
Très interessant se topic!!!! Sa m'a donner envie de posté(sa fesait trop longtemp).
bientot il y aura des screens de notre dernier moteur sur mon site ki devrait arrivé dans 2~3semaine(pr info, j'ai mon écran a pété donc jpeu pas le continué pour l'instant).
Notre dernier moteur est assez exitant, surtout quand on pense a ce qu'on peut faire avec!!!!
Petit complément sur le spéculaire : Bafman a décrit ici la méthode de Blinn qui utilise le halfAngle qui est beaucoup plus facil pour faire du spéculaire sur des carte ne supportant pas les FP. Sinon, il existe le méthode Phong qui utilise le vecteur refléchit pour le calul du DOT3 avant le mise a la puissance.
Voili voilou!
Lol les louttres sont des annimaux protégé ici :D.
Sinon pour la question de bases, Un bon moteur doit pouvoir utiliser le bon algo au bon moment ^^. Comme tout bon programme en faite ^^.
Vouloir trouver l'unique Algo universel pour tout les cas de scene 3D, je pense, pour ma part, que c'est une utopie ^^.
exactement, surtout que tout algo a besoin de reposer sur une structure de donnée, et que la structure de donnée ultime n'existe pas :wink:
VRML ??? Lol bon j'arrete mes blagues foireuses
*Est méchant avec le VRML*
Bonjout tout le monde et désolé pour ce retard.
Ces derniers jours, j'ai pu cravacher comme un malade sur mon moteur (2D pour l'instant) et j'ai fait d'énormes avances, je prévois la première version comlètement fonctionnèlle dans 2, 3 semaines.
Et pour y arriver, j'ai du procéder en marche arrière : çàd j'ai défini mes classes et leurs intérfaces, j'ai tout fixé quoi, et ensuite, j'ai commencé à coder la chose, et la ca a marché.
Je confirme, c'est trés difficile de developper un moteur géneraliste, qui résout le conflit israélo-paléstinien, le conflit irakien, les ouragons, les tremblements de terre et la famine ... si c'est pas pour un jeu, il faut poser ce qu'on va faire et ce qu'on ne va pas faire dans le moteur pour pouvoir le terminer.
Et pour résumer ce qu'on a dit sur l'éclairage, je dirais que le mieux serait d'utiliser des lightmaps, qui sont calculés par des vertex et fragment shaders en plusieures passes. C'est bien ça ? dommage que j'ai pas de fragment shader sur ma carte, je devrais le faire sur le CPU.
Heu... On ne doit pas avoir la même vision du développement :?Citation:
Envoyé par Modjo
Pour moi, tu as plutôt procédé en "marche avant".
Définir les classes et interfaces avec de commencer à coder, c'est pour moi une obligation (au moins pour les classes principales).
Je pense qu'il voulait dire qu'il avait du revenir en arrière pour définir ses classes et interfaces, enfin je pense :roll:
tu peut tres bien faire de l'eclairage par pixel sans fragment program sur le GPU, c'est d'ailleur pour ca qu'a été inventé l'extension DOT3... par contre tu sera plus limité dans les possibilité de crée de l'eclairage speculaire et autre mais ce n'est pas non plus impossible... en utilisant quelques feintes de sioux (attenuation + "cube map de normales" dans une seule texture 3D ou autre) on peut atteindre des resultats impressionnant même avec du vieux materiel genre GF4 :wink:
En effet, notre moteur permet de rendre des lumière omni directionnel avec différent rayon sur l'axe X,Y ou Z et orientable ; des spot light avec angle d'ouverture réglable et des cube light. Tout ces lumière on un couleur et sont correctement atténuer.
Sur GF4, j'utilise les combiner et je rend tout ces lumière en 2passes par lumière : 1 pour la composante diffuse et une autre pour la composante émissive et le tout bumpMappé grace au DOT3.
La texture3D est une très bonne idée d'optimisation pour l'atténuation(1 texture au lieu de 2) et permet de simplifier les calcul de lumière oval grace au matrice. Par contre l'optimisation que j'ai utilisé qui consiste a mettre les normal dans la composante RGB de la texture3D a aussi certaine limite : problème de la normal au centre indéfini 8O (mais il faut que la lumière se confond presque avec la surface et qu'elle soit géantre pour que le problème se voit) et à cause de problème de précision(et une petit feinte de ma part pour rendre le cubelight et spotlight speculaire en 1 pass) dans le vertex_program, le spéculaire semble étiré vers la caméra.
Pas pour les omnilight qui n'utilise pas cette feinte.
PS : bientot des screen :!:
sebh ou comment parler pour que personne ne nous comprennent :lol:
Binjour.
Ce que je voulais dire par marcher arrière, c'est que j'avais fixé les prototypes des fonctions finales que va utiliser le client final, pour ce faire, j'ai fais le brouillon d'un programme final qui utilise le moteur.
Ce n'est qu'à la fin que j'ai commencé à implementer ces interfaces.
Je ne sais pas pour vous, mais d'habitude, je ne fais pas ça, je commence à résoudre des petits problèmes, sans avoir une vision d'ensemble sur le projet, et je peaufine l'interface finale au fur et à mesur, mais ca c'est averé catastrophique dans un grand projet.
ha... donc en fait c'est avant que tu marchais à l'envers...
generalement dans tout projet autre que de la bidouille on commence toujours par fixer l'interface (au sens programmation pas GUI :wink: ), et une fois qu'on a des beau diagramme avec juste des signature de methode (on parle même parfois juste de service pour bien montrer qu'on ne sait pas ce qu'il y a derniere), on implemente. ainsi on peut utiliser sans probleme dans du code des methode qui n'on pas encore été implementée...
Oui, et je l'ai appris à la dure.
Sinon, pour revenir à l'éclairage, tu as parlé d'utiliser le DOT3, mais il faut comme même calculer la texture d'éclairage à chaque frame pour avoir un éclairage dynamique, et sans fragment shader, je ne vois pas comment calculer cette (maudite) texture sur le GPU pour plus de performances.
qu'est ce que tu appel texture d'eclairage ? la texture d'attenuation ? si c'est ca, une bete texture 3D en forme de sphere fait tres bien l'affaire...
Je ne suis pas sur de bien comprendre.
Si ce n'est pas trop demander, pourrais tu eclaircir un peu STP ? un lien vers un tuoriel traitant de ce sujet peut être ...
en gros pour ton eclairage tu a besoin de pouvoir dire
ce pixel la est eclairé, celui la l'est moins (car plus loins de la lumiere) et celui la est completement noir car trop loins de la lumiere. c'est cela l'attenuation, plus un pixel est loins de la lumiere, moins il est eclairé, et pour cela on utilise une texture 3D en niveau de gris dont le centre vaut 1 et les bordure vallent 0, ce qui permet de dire "plus je suis proche du centre de la lumiere, plus je suis eclairé".
oui, merci, je le sais ça, c'est une sorte de lightmap, mais je n'arrive pas à comprendre la notion d'une texture 3D ... comment la stocker dans un fichier par exemple, sous forme de plusieures couches ?
ca c'est un autre probleme :lol:
on peut en effet la stocker en plusieurs textures, mais il faut que celles ci soit toutes de la même taille...
en fait la texture 3D est plus un outils qu'on utilise en interne d'un moteur et dont les artiste n'on pas à se preoccuper. En effet generalement les textures 3D sont crée directement dans le programme avec une petite fonction qui va bien et non pas stocker dans des fichier.
a part quelques demo de Nvidia, je n'ai jamais vu de moteur 3D qui chargeait une texture 3D depuis des fichier, tout simplement parcequ'il n'existe pas de format officiel pour les stocker et parcequ'il n'existe pas d'outils pour les crée 8) bref les Texture 3D c'est encore un truc de developpeurs :lol: