 | |  |
| toys | merci.
edit: je l'ai lu mais c'est lourd...l'auteur ne se met pas au niveau d'une personne ne connaissant pas ce que c'est.
il parle de static mesh sans dire ce que c'est, son intérêt...aucune image pour illustrer, etc..
je ne vois pas le rapport avec l'option dans mental ray car l'auteur écrit "BSP est un système utilisé par un Moteur de jeu pour calculer des espaces "pleins"et "vides""
bref, c'est un article un peu baclé...mais c'est mieux que rien
Message édité par toys le 02-08-2008 à 20:40:15
|
Malikarn - F1 - | salut
non en fait que ce soit bsp ou autre chose, tous les moteurs de rendu Raytracing (temps reel ou non) disposent d'une méthode d'accélération du raytracing. C'est à dire qu'en lancer de rayon un des problèmes c'est de trouver les intersections. Ou quel rayon rencontre quel poly. C'est d'autant plus un problème que le lancer de rayon est récursif. Un rayon rencontre une surface puis un autre rayon est émis (reflexion ?) puis un autre, puis un autre etc.
S'il fallait à chaque fois que chaque rayon teste tous les polygones de la scène pour savoir lequel il rencontre ça prendrait un temps fou. Donc "ils" ont mis au point une méthode d'accélération qui consiste a subdiviser la scène en boite de plus en plus petites (profondeur du bsp) jusqu'à ce que ces boites contiennent un nombre raisonnable de polygones (taille du bsp). Cela fait, le moteur de rendu recherche dans un premier temps seulement les intersections entre les rayons et ces boites. Dès lors le moteur n'a plus qu'a tester les intersections avec les polygones contenus dans les boites rencontrées. De fait il gagne un temps considérable en ignorant les intersections pour tous les objets que de toutes façons (pour un rayon donné) il ne rencontrera pas.
Et contrairement à ce que tu crois les réglages bsp peuvent faire varier les temps de rendu du simple au double voire plus sur des scènes très exigeantes en raytracing.
Et pour revenir au topic, il n'y a qu'un être humain qui puisse estimer la taille de l'arbre bsp. Parce que dans un jeu par définition une scène simple en apparence peut devenir un vrai bordel en quelques secondes se le joueur choisit de tout faire péter. Donc le défis j'imagine est de créer une méthode de calcul qui va estimer à chaque image la taille de l'arbre nécessaire et de faire en sorte que cette méthode de calcul ne prenne pas plus de temps que de calculer directement toutes les intersections.
++
+++ Message édité par Malikarn le 03-08-2008 à 13:21:48
|
DeiMortem
| De toute façon, peu importe la technique, ils y arriveront ! Et osons dire que le fossé entre le temps réel et le précalculé sera dès lors quasi inexistant, j en suis persuadé.
Personnellement, j'ai hâte... |
Malikarn - F1 - | A termes oui certainement... Mais le pré-calculé va devenir spectral donc c'est un éternel recommencement. |
nobrainnobrain pilier de bar de 3dvf
| |
toys | nobrain:
tu dois parler du larabee, la future CG d'intel.
C'est un multi-core (une centaine il me semble) x86 avec un core genre la puissance de l'atom.
elle doit sortir l'année prochaine.
il y aura la présentation officielle le 12 aout.
Malikarn: merci pour ton explication simple et courte
je me demandais avec quoi ils ont réalisé la vidéo en temps réel alors que les cartes n'existent pas?
pour les images calculées, il y a un plug de redway3d pour 3dsmax qui se sert de la CG pour calculer les reflections.
cela agit aussi sur le viewport.
cela réduit fortement le temps de rendu et me demande pourquoi cela n'est pas intégré d'office sur tous les softs.
http://www.redway3d.com/pages/index.php |
nobrainnobrain pilier de bar de 3dvf
| nan nan, c'était pas un papelard d'intel, c'était un labo public, mais je serais bien incapable de retrouver les références exactes  |
| |
| | |