Author Topic: Hyperion 1.0.2 dispo  (Read 4562 times)

0 Members and 1 Guest are viewing this topic.

JeGX

  • Global Moderator
  • Capo Crimine
  • *****
  • Posts: 2385
    • oZone3D.Net
Hyperion 1.0.2 dispo
« on: November 22, 2005, 04:57:11 PM »
Ciao a tutti!

La nouvelle version est dispo depuis aujourd'hui:
http://www.ozone3d.net/repository_hyperion_win32_installer.php

Au programme, les habituelles corrections de bugs dont la plus importante concernait le rendu des particules en mode point_sprite.

Pour mémoire, le mode point_sprite est une extension OpenGL qui permet d'accélerer le rendu des particules en diminuant le trafic vers le gpu: au lieu d'envoyer 4 vertices afin de dessiner un quad texturé pour chaque particule, le mode point_sprite nous permet de n'envoyer plus qu'un vertex par particule. C'est la carte graphique qui se charge de recréer le quad texturé et billboardé (et oui dans ce cas le billboarding est aussi géré par la carte).

Tout ceci pour dire qu'à la suite d'une des dernières phases d'optimisation du codepath standard des particules, le codepath point_sprite a été
quelque peu torpillé. Encore désolé :oops:

Maintenant passons aux nouveautés. La plupart d'entre elles ont été ajoutées pour permettre la réalisation de la demo Static AO.

FBO. Les FBO pour framebuffers objects sont une extension récente d'OpenGL qui permet un accès simplifié (et théoriquement plus rapide) aux buffers de la carte graphique: les color buffers des textures et les depth buffers pour les principaux. Les FBO sont principalement
utilisées avec des textures dynamiques (textures dont on modifie dynamiquement le contenu durant l'execution). Une des applications
importantes des textures dynamiques est le rendu dans texture plus connu sous l'acronyme de RTT (render to texture, à ce niveau l'anglais c'est quand même plus sympa!). Les RTT sont utilisés intensivement dans le moteur de reflexion d'oZone3D.

Le codepath standard de RTT est très rapide et théoriquement les FBO devraient encore l'accélérer. Mais il n'en est rien! Le codepath standart RTT est en moyenne 10% plus rapide que le codepath FBO. J'aurais préféré l'inverse. Je debusquerais le gremlins une prochaine fois à moins que ce ne soit un pb de drivers. J'ai effecté les tests de perf sur ma 7800gt avec les forceware 81.94. Peut etre que sur les radeons il en ira autrement. Si quelqu'un veut faire les tests ca serait cool.

Mais là ou les FBO sont interessants c'est dans les dimensions des textures qui peuvent être quelconque (mais tjs d'une puissance de 2).
Le codepath standard RTT utilisé dans les relfexions ne permet pas d'avoir des dimensions supérieures à la taille de la fenêtre 3D. Si une demo hyperion initialise la fenêtre en 1024x768, la texture de reflexion peut avoir une taille max de 1024x512. Le codepath FBO supprime
cette limitation et l'on peut donc avoir une texture de reflexion de 2048x2048 avec une fenêtre de 800x600 8)

Ambient occlusion et vertex attrib. Les données d'occlusion (bent-vector et facteur d'occlusion) peuvent être chargés dans
l'attribut de vertex de votre choix, ce choix étant dépendant des shaders GLSL utilisés dans votre demo.

Les attributs de vertex sont des données supplémentaires que l'on peut attacher à chaque vertex et qui sont utilisées dans les shaders GLSL (mot clé attribute dans le vertex shader). Pour un shader d'ambient occlusion avec bump mapping, les données d'occlusion doivent chargées dans le second attribut, le premier étant automatiquement utilisé par le moteur 3D pour y stocker le vecteur tangent indispensable au bump mapping.

Shadow volumes. Les ombres volumiques ne sont pas nouvelles mais la possibilité d'utiliser un gpu shader pour la passe ambiante si. Pour simplifier, le shadow volume engine fonctionne en 2 passes: une passe ambiante et une passe d'illumination.

La passe ambiante permet de dessiner la scène éclairée par la lumière ambiante globale. Ceci est en fait equivalent à rendre la scene complète dans l'ombre. La passe d'illumination permet quant à elle de dessiner toutes les zones non ombrées donc éclairées par les sources lumineuses.

Jusqu'à la version 1.0.0 d'hyperion, seul le shader glsl bindé au matériau était utilisé et seulement dans la passe d'illumination. Maintenant il est aussi possible de binder un shader glsl pour la passe ambiante. Celà a été nécessaire lors d'un test avec une scene rendue en ambient occlusion et ombres volumiques...

La dernière nouveauté est la possibilité de limiter, plus exactement d'interdire le fonctionnement d'une demo sur une des deux
plateformes actuelles: nvidia ou ati. Ceci surtout à cause des différences de fonctionnement des gpu nvidia et ati en GLSL. En effet sur la demo Static AO, j'ai été confronté au problème des plans de clipping utilisateur qui n'étaient pas pris en compte sur les gpu nvidia. Pour résoudre ce pb, la soluce est de mettre à jour la variable glsl gl_ClipVertex. Avec les gpu radeon, au contraire les user clipping planes sont directement pris en compte dans les shaders et la variable gl_ClipVertex provoque un beau plantage de la demo sur ATI! Du coup j'ai ajouté dans l'élément check_hardware_caps du noeud scene la possibilité de choisir une plateforme cible pour une demo.

Voilà, la présentation de la nouvelle release hyperionique. Et surtout ne vous privez pas d'utiliser le forum pour signaler tous les comportements étranges d'hyperion sur votre pc.