Annonces Google
Serveur IRC
Serveur : irc.portlane.se
Canal : #AmigaNG
Activité du Site

Pages vues depuis 25/07/2007 : 25 369 966

  • Nb. de membres 187
  • Nb. d'articles 1 271
  • Nb. de forums 19
  • Nb. de sujets 20
  • Nb. de critiques 24

Top 10  Statistiques

Index du forum »»  Création-Développement »» Oui on peut faire du bump mapping avec Warp3D/Os4

Oui on peut faire du bump mapping avec Warp3D/Os4#1414

6Contributeur(s)
thellierAmiDARKCrisotElwoodK-LYesCop
3 Modérateur(s)
K-LElwoodcorto
thellier thelliericon_post
Bonsoir encore

je comprends pas que tu ait un probleme: tu n a pas du lire mes messages = relis les = je te dis que j utilise les vertex normales de la face donc le bien le plan courant de CETTE face qui fait un dotproduct avec cette normal-map et je n ai pas ton probleme = charge microbe3d et la vache et vois comme st thomas....

ensuite je te remercie pour les formules de matrices mais je crois que j utilise les memes : je dois juste avoir une faute de frappe qque part = je chercherai

Alain
Crisot Crisoticon_post
J'ai lu les messages ainsi que les messages qui me disaient de relire les messages. :-)

Ta vache ne peut tout simplement pas mettre en avant le problème car la normal map est déjà construite en tenant compte de l'orientation des polygones de tout l'objet.

Pour mettre en avant le problème:

-prends un plan bidon (2 triangles) et affecte lui une normal map.
-a l'aide de matrices, affiche 6 fois ce plan de manière à former une skybox (pour être dans le cube).
-les 6 faces de ce cubes, bien qu'orientées différement, partagerons donc la même normal map.
-déplace toi dans la skybox, et constate, bien impuissant, combien tes vertex normales, bien que tenant compte de l'orientation de chaque face, sont bien impuissants face à tous les problèmes de bump qui surgissent... :-)

EDIT: J'ai dis une grosse bétise. Je viens de télécharger ton archive et de regarder bump2.bmp: Ce n'est pas une normal map calculée, désolé. Mais les flancs de ta vache, lorsqu'on la regarde de face, sont illuminés à l'inverse l'un de l'autre -> C'est exactement le problème que je décris, sauf que sur un objet ça choque pas trop. Sur un monde en revanche, ça n'aurait rien à voir
--
AmigaOne X1000 - 2 Go DDR2 - Sapphire R9 280x Toxic - Crucial MX200 500 Go - Alim/Cooling BeQuiet

Message édité par : Crisot / 25-11-2012 23:38
AmiDARK AmiDARKicon_post
Je viens de trouver des exemples d'OpenGL 2.0 qui permettent une sorte de bump mapping en double texturing, je vais essayer de les décortiquer et voire ce que cela pourrait donner avec l'AmiDARK Engine :p
D'ailleurs il y a d'autres effets qui sont possibles apparement car les commandes existent dans MiniGL :p
Je vais testouiller tout ça ... merci à vous deux car votre travail sur votre "pseudo" bump mapping m'a un peu fait farfouiller le net en quête de docs et d'informations :p
J'y ai trouvé plus que ce que j'avais besoin pour le bump ... mais ce plus sera aussi utile pour l'AmiDARK Engine :p

@+
Crisot Crisoticon_post
Juste précision hein: Ce n'est pas du "pseudo" bump mapping. C'est la vrai méthode telle qu'elle était employée avant les shaders, tout comme les exemples OpenGL 2.0 que tu as trouvé. Et le terme "normal mapping" convient bien mieux.

-Le bump mapping est un effet de relief statique non orientable, fait à l'aide d'une texture greyscale statique. En clair, une light map.


En petit une bump map, en gros le rendu. On voit sur le visage que quelque soit la provenance de la lumière, les reliefs sont toujours orientés dans la même direction.

-Le normal mapping est fait à l'aide d'une normal map RVB, laquelle est convertie en temps réelle et dynamiquement par le GPU en texture greyscale.


En petit une normal map, en gros le rendu. Cette fois ci les reliefs sont orientés vers le spot lumineux sur le mur.

Mais la langue veut qu'on appelle couramment tout ça "bump mapping".
--
AmigaOne X1000 - 2 Go DDR2 - Sapphire R9 280x Toxic - Crucial MX200 500 Go - Alim/Cooling BeQuiet

Message édité par : Crisot / 25-11-2012 23:40
AmiDARK AmiDARKicon_post
eh!eh!
J'aime bien "chatouiller" un peu Crisot, il démarre au quart de tour ;)

@+
YesCop YesCopicon_post
Merci Alain pour tes explications.
Je comprends beaucoup mieux.
En ce qui concerne les matrices, je te dirais deux choses.
Je ne sais plus si gcc le permet, il existe des librairies optimisées C++ (faisant partie de la définition officielle) pour la multiplication de matrices (par exemple en utilisant la notion de vecteurs). C'est une optimisation sur le temps de calcul.

Après tes explications il y a quelques temps sur les triangles et la composition, j'avais fait des recherches sur les coordonnées homogènes. Comme tu le sais sûrement, ce sont des matrices 4x4 représentant l'espace. Avec une seule matrice tu peux faire une translation et une rotation en une fois.
Voci un lien pour les examples
http://fr.wikipedia.org/wiki/Coordonnées_homogènes

Message édité par : Creols / 26-11-2012 09:29
Crisot Crisoticon_post
Ouais ouais... :-P Vazy, fais ton bump avec MiniGland, et dés que t'as un résultat pas trop catastrophique, poste un screen ici, on t'aidera à corriger :-P

Fallait pas m'chercher... xD
--
AmigaOne X1000 - 2 Go DDR2 - Sapphire R9 280x Toxic - Crucial MX200 500 Go - Alim/Cooling BeQuiet
thellier thelliericon_post
@Amidark
>-Le bump mapping est un effet de relief statique non orientable, fait à l'aide d'une texture greyscale statique. En clair, une light map.
Je suis d'accord avec Crisot il vaut mieux réserver à cet effet statique le nom de "light map"
Par contre mon exemple c'est vraiment le même effet qu'un shader

@Crisot
J'ai compris ton problème Crisot effectivement (hier soir j'étais trop crevé pour capter) tu utilise une lampe LOCALE POSITIONNELLE donc sa direction change avec chaque mur: elle est à gauche du mur droit ,à droite du mur gauche,etc..

mur mur
| --> Lampe <--|

J'avais cru comprendre que tu disais que ma "technique de bumpmap ne pouvait pas rendre les normales qui sont pas face à la lampe" (cad pas parallele au plan de l'écran) mais on voit bien sur les cotés de la vache que si ... mais avec une lampe directionnelle pas locale (ici située à l'observateur) dont la direction reste constante en tout point de la scene.

Ayant compris ton problème j'ai pas de solution simple à proposer: le plus radical et bourrin ,comme c'est des murs, serait de tourner toutes les normales de chaque bloc objet "mur" dans la direction courante du mur (cad de la normale du plan du mur)

@YesCop
>il existe des librairies optimisées C++
Merci, mais j'en suis pas au point de vraiment optimiser : j'ai défini les specs de Microbe3D (voir l'archive) et je voudrais juste que sa marche comme prévu sans bugger. Par la suite je regarderai les optims sévéres...

>Après tes explications il y a quelques temps sur les triangles et la composition, j'avais fait des recherches sur les coordonnées homogènes
J'ai lu ça aussi mais je te conseille de trouver un livre sur la programmation 3D car le jargon matheux, surtout français, est abscon pour le programmeur: l'idéal c'est les bouquins des années 80, avant opengl, où tout était fait par programmation donc accessible à la comprehension
En fait mes matrices rotations,translation,etc marchent vaiment bien mais c'est juste quand je veut faire une "hierarchie" d'objets que ça merde genre une vache qui tient une vache chacune avec sa rotation,position il doit juste y avoir une faute de frappe qque part mais ça me gave...


Alain

Message édité par : thellier / 26-11-2012 09:52
Crisot Crisoticon_post
La solution est de calculer un repère tangent pour chaque polygone, ce repère étant donné par une tangente, une binormale, et une normale. La normale ne change pas, en revanche la tangeante et la binormale sont obtenues à la fois par la géométrie du polygone mais aussi par ses déplacements UV, qui pour le coup s'appelleront vecteur S et vecteur T.

Ensuite, il faut transformer notre vecteur vertex->lumière par la matrice obtenue (3 vecteurs N T B de 3 dimensions = une matrice 3x3).

Si un jour pour X ou Y raison tu as besoin de ça.

http://www710.univ-lyon1.fr/~jciehl/Public/educ/GAMA/2007/TP_repere_tangent.html

Voir "construction guidée par texture".

Ca m'a pris le choux 2 jours...
--
AmigaOne X1000 - 2 Go DDR2 - Sapphire R9 280x Toxic - Crucial MX200 500 Go - Alim/Cooling BeQuiet
AmiDARK AmiDARKicon_post
@Crisot : Ce sera fait :)
Mais va falloir attendre quelques jours ... je dois d'abord finir la release 0.7 de la version 2D only de l'AmiDARK Engine ;)
Petites Annonces

0 annonce(s) publiée(s)

Consulter

AmigaOS 4.1

Laissez-vous tenter par
AmigaOS 4.1
AmiTheme

AmiTheme