Ouch, il y en a qui maitrisent…
ca donne envie de jouer avec assez severe
Ouaip, finalement Glop, t’es pas si bon que ça
J’en profite pour faire ma pub si c’est ca et refiler le lien vers le raytracer en C# que ni Tzim ni moi n’avons touche depuis des lustres Mais si ca interesse qqn… faites vous plaisir.
http://sourceforge.net/projects/gloprender/
et quelques autres liens:
http://www.kalme.de
http://www.codeproject.com/cs/media/mdx_tutorial1.asp
http://www.codeproject.com/cs/media/mdxtutorial2.asp
http://staff.develop.com/candera/weblog2/a…irectX/Direct3D
Ce message a été édité par GloP le 23/06/2003
[quote]Ouch, il y en a qui maitrisent…
ca donne envie de jouer avec assez severe
Je ne sais pas comment font certains pour oser toucher a C# mais bon apparemment il est quand meme possible d’obtenir un bon truc au final…
Glop tu pourrai quand meme le finir ton moteur raytracer depuis le temps que j’attend de voir tourner ce genre de tekno en temps réel (et vu que je suis une quiche en maths c pas moi qui vait le faire) Tien d’ailleurs c’est mon prof d’imagerie numérique qui disant qu’il n’était pas possible de faire du raytracing avec les bécanes actuelles, mais je ne m’abuse il est sorti une demo il y a peu utilisant aussi cette technologie. Enfin tout ça pour dire : oubliez vos cartes graphiques toutes basées sur le z-buffer, vive le raytracing!
[quote]Je ne sais pas comment font certains pour oser toucher a C# mais bon apparemment il est quand meme possible d’obtenir un bon truc au final…[/quote]Va falloir que tu te dechires de mieux que ca pour pas passer pour un gros troll parceque dans le meme genre on peut y aller franco. Exemple: “franchement je sais pas comment font certains pour oser toucher a du C++/Perl/PHP/C/Cobol/Fortran/Java/Pascal… ha ouai voila c’est ca. Je sais pas comment on peut oser faire autre chose que du C#”. Ouah! C’etait facile.
J’adore le “il est quand meme possible d’obtenir un bon truc au final”.
C’est minable. Surtout que personellement C# est de loin le langage avec lequel je m’eclate le plus (de loin) jusqu’a present.
Quand au raytracing j’ai jamais parle de faire ca en temps reel dans mon programme puisqu’il a toujours ete question de faire du “vrai” raytracing complet pour illuminer la scene. Pas juste approximer les ombres… J’ai pas non plus l’intention de bosser plus dessus a court ou moyen terme. Et ton prof a raison. Le “pseudo raytracing” compte pas.
Ce message a été édité par GloP le 25/06/2003
Euh, oui, outre le très GROS morceau de troll (putain il y a eu une livraison ou quoi aujourd’hui ?!?) le raytracer temps réel, on en reparlera quand les poules auront des dents dans 20 ans, peut-être…
GloP, tu vas jamais le croire : il se pourrait que je fasse ENFIN ce que j’ai promis… l’an dernier humhum. Car je vois enfin une éclaircie dans mes projets persos. Euh et dans mon emploi du temps aussi
Bon, j’y connais vraiment rien en programmation, en fait ça doit être la première fois que je met les pieds ici mais la discussion sur le raytrace m’intéresse…
Dans les vidéos de HL2, lorsque l’on regarde à travers une vitre transparente “bumpée” on a de la réfraction, ou tout simplement lorsque l’on regarde un (vrai) reflet d’une eau non plate on a le reflet déformé en temps réel, c’est pas le principe du raytrace qui est utilisé ici ?
Enfin, en parlant comme ça je me réfère surtout aux fonctions de 3Ds par exemple, ou on doit justement utiliser le raytace pour simuler de vrais reflets, de la réfraction ou même des ombres très précises… tout comme HL justement (pas sûr pour les ombres ).
Si ce n’est pas du raytrace qui est utilisé, alors à quoi sert-il ? qu’apporte-t-il de plus (si c’est apparement impossible à l’utiliser en tps réel de nos jour ) ?
Ce message a été édité par mateo le 25/06/2003
Les reflections de ce genre en general dans les jeux consistent souvent a rendre une version de la scene en plus basse resolution “vue de l’eau” et a la mapper comme une texture. Les ruses pour calculer les ombres ou faire du pixel shading etc sont nombreuses pour s’eviter de faire “du vrai” raytracing precis et tout. Faudrait demander a un specialiste du rendu temps reel genre Count0
[quote]ca donne envie de jouer avec assez severe
Mais jusqu’où ira-t-il ? ;p
Oui, ce genre de procédé est par exemple utilisé dans Morrowind justement, plutot que de dire à l’eau “réfléchis l’environnement” on lui dira “tu prend cette map et tu la réfléchis” ce qui donnera dans le jeu des tons marrons prés de la terre et plutot du bleu pour simuler une réflection du ciel. Donc illusion.
Même truc pour les vaguelettes quand on se déplace, ce n’est que du bump. Les vaguelettes n’affectent que la réflection, pas le sol.
Mais le problème c’est que justement, dans Half Life c’est bien du “réfléchis l’environnement” qui est utilisé. Bon j’ai plus la grosse vidéo de 500 mo pour vérifier mais on peu voir lorsque le soldat se faire choper par les tentacules bleues on voit son reflet sur l’eau (qui si je me souviens bien ondule en plus) qui est conforme à ce que l’on voit “en vrai”, enfin c’est le vrai reflet quoi.
En plus de ça, quant on voit plein de panneau qui tournent sur eux-même, il y a un panneau transparent qui a une surface rugueuse et on voit que la lumière qui passe à travers la surface est altérée, tout en respectant ce que l’on devrait voir “normalement”. Même exemple avec les vaguelettes donc, en plus d’affecter la réflection de l’eau, ces dernières modifient la perception du sol (qui est sous l’eau ) ce qui voudrait dire que là c’est plus du bump, ce sont de vraies ondulation, avec des faces et tout (ça me paraît quand même chaud là, faut que je rechoppe la vidéo en fait).
Ce qui voudrait dire au final que en plus de gérer la réflection en temps réel, ce moteur gère aussi la réfraction, le con
Ca nous ferait pas deux exclusivité dans un jeux vidéo ça ?
ps : Allez Count0, on t’attend là
Ce message a été édité par mateo le 25/06/2003
Bon, je me lances sur mon ptit speech. Ca fera grimper mes stats Dolphin
Pour ce qui est du raytracing temps réel, mon prof d’archigraph était plus optimiste (5 à 10 ans), et personellement, je dis pourquoi pas, car si le raytracing et très gourmant en calcul, il l’est largement moins que le Z-Buffer en Bande passante mémoire, ce qui a tendance a freiner aujourd’hui l’évolution des Cartes Graphiques.
Pour ceux qui n’y connaissent rien, il existe deux méthodes (parmis beaucoup d’autres) de rendu très couremment utilisées. Rendu Z-Buffer, utilisé en temps réel, et le raytracing, utilisé uniqement pour les animations précalculées (animations, films …).
La première méthode est basée sur un principe purement géométrique. Notre scène contient une floppée de polygones (et je dirais même plus, de triangles, car il est possible de tout subdiviser en triangles, la seule primitive gérée par la carte graphique). Le Z-Buffer est une technique qui consiste a afficher la projection centrale de ces polygones sur le plan-écran, en affichant uniquement le polygone le plus proche de l’écran.
Le Raytracing a pour vocation de simuler le trajet de la lumière. En réalité, il effectue son trajet inverse. On va donc lancer des rayons depuis la caméra et voir où ils s’aretent, puis lancer a partir de ce point d’autres rayons afin de d’éterminer l’éclairage de ce point par telle ou telle lumière, ou pour déterminée l’image réflechie ou réfractée si l’objet possède une réflexion ou une réfraction.
Aaaah, le raytracing… Ca me rappelle mon cours de rendu et le prof qui nous avait demandé de programmer un lancé de photons en 15 jours .
Tout le monde a réussi à programmer la partie raytracing de l’affaire mais la partie photon avait juste été ébauchée. Je m’étais promis de finir le tout après la fin des cours mais je m’y suis jamais remis.
D’ailleurs, si il y en a qui sont intéressés par des cours de rendu réaliste (non temps réel), mon prof les a mis sur son site:http://www.irit.fr/~Mathias.Paulin/index.html
C’est dans la rubrique enseignement.
Ce message a été édité par Gundarf le 25/06/2003
[quote]…lorsque le soldat se faire choper par les tentacules bleues on voit son reflet sur l’eau (qui si je me souviens bien ondule en plus) qui est conforme à ce que l’on voit “en vrai”, enfin c’est le vrai reflet quoi.
En plus de ça, quant on voit plein de panneau qui tournent sur eux-même, il y a un panneau transparent qui a une surface rugueuse et on voit que la lumière qui passe à travers la surface est altérée, tout en respectant ce que l’on devrait voir “normalement”. Même exemple avec les vaguelettes donc, en plus d’affecter la réflection de l’eau, ces dernières modifient la perception du sol (qui est sous l’eau ) ce qui voudrait dire que là c’est plus du bump, ce sont de vraies ondulation, avec des faces et tout (ça me paraît quand même chaud là, faut que je rechoppe la vidéo en fait).
Ce qui voudrait dire au final que en plus de gérer la réflection en temps réel, ce moteur gère aussi la réfraction, le con
Ca nous ferait pas deux exclusivité dans un jeux vidéo ça ?[/quote]Bon, les techniques ne sont pas si compliquées que ca, et je vais tenter de donner un début de réponse.
Pour les effets de lumières (notre soldat qui modifie l’éclairage environant), bon, l’éclairage dynamique, ca fait longtemps que cela existe, mais en même temps, nos chers Pixels shaders apportent ici un élément de raytracing, en permettant de prendre compte des obstacles à la lumière lors du rendu.
Pour ce qui est des reflexion, cela n’est guère plus compliqué, une réflexion n’étant autre que la même scène mais vue sous un angle différent. On calcule donc ce point de vue et on l’applique ou il faut. Soit en utilisant un masque (Stencil Buffer), soit en rendant dans une texture, qui sera appliquée a notre surface réflechisante (oui , on a donc 2 rendus/ scène, d’ou deux fois plus de calculs).
Bon, pour la réfraction, même principe…
OUuinn ils m’ont cassé toutes mes dents en me traitant de troller
Bon oki je suis peut etre une quiche mais moi j’ai pas adheré
Bon sur ce, back to Visual C++
P.S: non mais des fois, moi un troller, j’aurai tout entendu.
EDIT: bon si c’est comme ça je vais m’y remettre tien à C#
Tien et je demandais aussi en rejouant à Tomb Raider premier du nom, avec ses gentils bugs d’apparitions/dispartiions de polygones, si des fois les programmeurs n’avaient pas utilisés l’algorithme du peintre.
Ensuite une autre question, Le pixel shading si je me rappelle bien consiste justement à calculer la lumière sur les pixels et non pas sur une surface? Mes cours sont loins, et on surtout vu tout ce qui tournait autour du rendu hardware sans tater à ce genre d’options donc maintenant je me pose quelques questions.
Quelques notes aussi sur le z-buffer: si mes souvenirs sont bons, le principe est de tester les pixels sur une zone donnée, et de mettre à jouer le Z-buffer dès que l’on croise un pixel plus haut. Et ensuite il faut appliquer une transformation pour obtenir le screen space (pyramide de vision tout ça). Je dois avouer que j’ai beau coder avec DirectX9 depuis un an, je ne me suis jamais réellement intéressé à tous les algos cachés derrières par manque de temps, donc j’essaye de rattraper mon retard.
Ce message a été édité par BodySplash le 25/06/2003
[quote]OUuinn ils m’ont cassé toutes mes dents en me traitant de troller
Ce message a été édité par Tzim le 26/06/2003
C’est bien les gars, vzetes bons la, continuez sans moi, hein ? je regarde
bon maintenant, je vais me faire un prof…
sur la theorie de ton prof sur le raytracing par rapport au zbuffer, la bande passante…
d’abord, comment ca marche le z buffer ?
si un moteur doit rendre un triangle, il va transformer les 3 points de son triangle dans l’espace dit de la camera, puis va les projete sur l’ecran, donc en 2d, et apres, la carte va remplir le triangle en interpolant entre les 3 points, pour obtenir les bonnes valeurs… la carte va donc interpoler les couleurs, mais aussi les coordonnes de texture, et surtout le Z (ou plutot, en vrais, le 1.0f/Z, mais ca c’est un detail d’implementation), et puis pour chaque point du triangle il ecrit un pixel a l’ecran…
et la, cris d’horreur dans la foulle : et si je trace un triangle qui est derriere celui que je viens de trace? hey bah c’est la merde…
2 choix : trier les triangles (mais ca marche pas a tout les coups, des fois ils se croisent, les cons…) ou bien “trier les pixels”
C’est la que le Z buffer Entre en jeux, plutot que de juste stocker Rouge, Vert, Bleu et Alpha, la carte 3d stocke le Z en plus, et permet au programmeur malin, de choisir que faire du Z : si le Z du pixel que j’ecrit est <plus petit|plus grand|egal|plus grand ou egal|on s’en fout> alors ecrit le pixel.
Et sondain c’est plus la merde !
(bon y a aussi d’autre methode, mais c’est pas le debat la)
donc resumont, pour rendre une scene avec le Z buffer, je prends mes triangles, je les envois, et oui, la carte video a besoin d’un peu plus de bande passante car elle a besoin d’ecrire, en plus de la couleur, le Z et de le comparer (et le stencil il est gratos, ptet ?) avant de pouvoir faire son taf, donc en gros, si on a un ecran en 32bit, on stock le Z sur un autre 32bit, on double grosso modo les besoins en memoires et en bande passante…
Maintenant, prenont le raytracing, pour chaque pixels, je dois lance une ligne et parcourrir la scene pour voir comment ma ligne va se comporter (reflection, couleurs, lumiere tout ca…), puis j’ecris un bo pixel RGBA 32bit.
C’est vrais, ca fait deux fois moins d’acces memoire en ecriture video, mais maintenant, en lecture, ca en fait un peu plus, en moyenne 30% (il vient de nul part le chiffre, je l’imagine ) de la scene a besoin d’etre lue pour calcule la couleur d’un pixel, ca veut donc lire beaucoup beaucoup de donner PAR pixel, en plus, il faut que la totalite de la scene soit accessible a la carte video, donc en memoire video, et ca, avec nos jeux de maintenant, meme avec PLEIN de memoire, ca tiendra plus non plus…
Donc a l’arrive, on a bien divise la bande passante en ecriture par 2, mais on a rajoute une tonne d’autre truc a transfere et a lire… et ca c’est pas gratuit non plus !
(et de toute facons, sur les console BIEN FAITES, la bande passante et le fill rate ne sont pas un probleme, maintenant, sur les consoles grosses et vertes, c’est moins bien fait )
Vala.
Et un petit exercice pour la route :
“le rendu polygonal, c’est du raytracing avec un cache”
expliquez et commentez
nanan, c’est un vieux fantasme…
[j’ai fait un peu de lecture pendant le dejeuner]
[quote]tzim a dit :
Bon, et puis : une CG, comment ca marche [/quote]heu, on peut le corriger le document, parce que globalement il est tres bien, mais il y encore deux trois erreur mineurs dedans…
(et tu peux dire tout haut “ha, le lourd”)
Ce message a été édité par c0unt0 le 26/06/2003