Journal cherche doc Z-buffer

Posté par yaya le 08 août 2005 à 13:25.

Étiquettes : aucune

août

2005

Bonjournal,

j'ai craqué: j'ai fini par implémenter les surfaces dans mon package java dont tu n'as que faire...

Cela dit c'est particulièrement pas beau sans le Z-buffer:
http://jmathtools.sourceforge.net/GridPlotsExample.png(...)

Alors voilou, je voudrais bien implémenter le Z-buffer mais comme je suis une bille en algo et une feignasse de surcroit, je cherche un pseudo code ou qlq chose comme ça qui serait bien optimisé...

A vot' bon coeur...

Merci.

PS: non, Google n'est pas mon ami, et d'ailleurs j'ai pas d'amis.

# Wikipédia ?

Posté par Krunch (site web personnel) le 08 août 2005 à 14:32. Évalué à 4.

Alors peut-être que Wikipédia sera plus amical.
http://en.wikipedia.org/wiki/Z-buffering(...)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
- [^] # Re: Wikipédia ?
  
  Posté par Prae le 08 août 2005 à 18:38. Évalué à 3.
  
  In French: http://fr.wikipedia.org/wiki/Z-buffer(...)
  (mais moins complet :(
# Approche pas si naive que cela ...

Posté par Mouns (site web personnel) le 08 août 2005 à 14:35. Évalué à 4.

pour commencer, quand tu fais un rendu 3D sur une surface 2D, tu fais diverses opérations qui sont dans l'ordre :

1. tu poses les éléments

2. tu change de referentiel pour que l'origine soit dans l'oeil o de l'observateur et que l'axe oz soit la profondeur, et que les axes ox et oy correspondent à l'horizontale et la verticale de l'ecran

3. tu ne colories que les pixels calculées ayant l'ordonnées sur l'axe oz la plus petite

normalement avec ça tu ne sera pas loin du Z-buffer ;)

PS :
http://www.google.com/search?client=safari&rls=fr&q=Z+buffe(...)
# Java 3D ?

Posté par pierthi le 08 août 2005 à 14:50. Évalué à 1.

Refaire toi même un algo de z-buffer n'est pas vraiment une bonne idée :
* Ça n'utiliseras jamais d'accélération matérielle.
* Code ultra bloat pour une fonctionnalité annexe.
* Sans compter tous les bugs.

J'ai jamais utilisé Java 3D, mais ça sera à mon avis bien plus joli et optimisé que le meilleur algo que tu puisses trouver ...
- [^] # Re: Java 3D ?
  
  Posté par vrm (site web personnel) le 08 août 2005 à 15:03. Évalué à 2.
  
  Java3D c'est vraiment une grosse merde, vaut mieux le faire à la main ou utiliser LWJGL http://www.lwjgl.org(...) , Jogl, Xith http://xith.org(...) ou JMe http://jmonkeyengine.com(...)
- [^] # Re: Java 3D ?
  
  Posté par GuieA_7 (site web personnel) le 08 août 2005 à 15:19. Évalué à 1.
  
  Le problème c'est que je présume que son programme sert à créer des images qu'on va pouvoir enregistrer etc..., et pas seulemnt à les afficher. Alors bien sûr, tu peux faire un screenshot de ton résultat, mais on peut imaginer que le résultat va être différent selon la carte graphique que l'on a (cf les différentes précisions des flottants en interne par exemple). Alors dans un cas aussi simple que 4 lignes qui se courent aprés ça ne se verra peut être pas, mais c'est théoriquement génant. Voilà pourquoi je suis content que The Gimp utilise mon CPU pour faire des flous, et n'utilise pas OpenGL (malgré tout mon amour pour OpenGL).
  Et en plus il s'épargnera une dépendance à Java3d, on pourra générer des graphiques en ligne de commandes sans que rien ne s'affiche etc....
# bsp?

Posté par kra le 08 août 2005 à 15:18. Évalué à 2.

essaye d'implementer un arbre Binary Space Partition, comme ca meme pas besoin de Z-buffer.

en gros, c'est une structure d'arbre qui te classe tes facettes selon un ordre "devant/derriere", qui fait que tu n'as pas besoin de Z buffer.
tu parcours ton arbre dans le sens arriere/avant et tu affiches chaque facette sans te preoccuper de sa profondeur, vu que tout est trie.
Ca boost pas mal les perfs en plus.

une pitite recherche sur le web te donnera un mine d'info la dessus (c'est assez casse couille a faire quand meme, mais quand ca marche, bah ca fait plaiz').
- [^] # Re: bsp?
  
  Posté par GuieA_7 (site web personnel) le 08 août 2005 à 15:26. Évalué à 2.
  
  Houla comme tu y vas !! :)
  Un BSP c'est quand même un poil bourrin : c'est ce qui est au coeur d'un Quake 3 par exemple, parce que c'est l'algo typique pour les moteurs 3D en intérieur. Mais ça sert surtout à savoir quels triangles il faut afficher et lesquels vont être cacher par d'autres (et donc ne pas les envoyer inutilement dans la carte graphique).
  Mais pour un affichange precis au pixel prés, ça ne dispense pas d'utiliser le z-buffer (Quake 3 ne s'en prive pas sauf erreur grossière de ma part).
  - [^] # Re: bsp?
    
    Posté par Antoine le 08 août 2005 à 15:46. Évalué à 3.
    
    Mais pour un affichange precis au pixel prés, ça ne dispense pas d'utiliser le z-buffer
    
    Oui, car certaines faces peuvent être en intersection (exactement le cas sur le screenshot du monsieur d'ailleurs).
    Sans compter que les textures semi- transparentes obligent à tracer aussi les faces qui sont derrière : les structures de détection d'occlusion (comme le BSP) ne sont qu'une heuristique.
    
    Sinon un z-buffer, c'est très simple, mais ça nécessite d'écrire soi-même la routine qui va écrire les pixels individuels : peut-être pas super en Java ?
    - [^] # Re: bsp?
      
      Posté par GuieA_7 (site web personnel) le 08 août 2005 à 16:13. Évalué à 2.
      
      Sinon un z-buffer, c'est très simple, mais ça nécessite d'écrire soi-même la routine qui va écrire les pixels individuels : peut-être pas super en Java ?
      
      On est bien d'accord qu'il ne va pas obtenir le truc le plus rapide du monde. Mais :
      - même si personnellement, je n'utiliserai java que lorsqu'on aura au moins une jvm libre mature (attention je ne critique absolument pas le travail de ceux qui bossent sur les jvm libres), il faut reconnaitre que le java ça peut être quand même raisonnablement rapide (mais très gourmand en RAM en revanche).
      - Comme je le dit dans un post plus haut, je ne suis pas fan de l'utilisation de OpenGL dans ce cas.
      - Il peut se faire un module en C qui fait ça, mais bon contrairement au reste de l'appli il faut le compiler pour chaque archi, et c'est peut être pas ce qu'il veut.
      
      Après c'est sûr que le z-buffer c'est la solution facile et bourrine et qu'on doit pouvoir trouver mieux dans son cas. Il peut par exemple partir du postulat qu'il n'a que des segments de droites dans 2 plan orthogonaux et trouver un algo adapté à ce cas. Mais je présume qu'après il voudra aussi faire des surfaces pleines, et que le z-buffer sera encore la solution facile qui marche tout le temps.
  - [^] # Re: bsp?
    
    Posté par kra le 08 août 2005 à 15:57. Évalué à 2.
    
    ah?
    ben au temps pour moi alors, on nous avait parle de ca lors de mes cours d'infographie a la fac, et on nous avait presente ca comme la solution miracle face au Z buffer.
    
    par contre, le prof nous l'avait fait implementer sur une scene en exterieur (le rendu du campus d'orsay paris XI).
    - [^] # Re: bsp?
      
      Posté par Krunch (site web personnel) le 08 août 2005 à 22:24. Évalué à 3.
      
      D'après Wikipédia, dans les jeux vidéos 3D on a tendance à utiliser du BSP pour les trucs fixes et du Z-buffer pour les objets dynamiques.
      http://en.wikipedia.org/wiki/Binary_space_partitioning(...)
      Sinon pour les algorithmes et structures de données en général, il y a le "Dictionary of Algorithms and Data Structures" qui recence pas mal de trucs avec des liens vers des exemples d'implémentations mais évidemment le z-buffer n'est pas dedans.
      http://www.nist.gov/dads/(...)
      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# performances...

Posté par yaya le 08 août 2005 à 16:36. Évalué à 1.

Merci à tous pour ces idées.
Un petit complément d'info : le plot 3d en question est interactif et doit pouvoir assumer la rotation par déplacement de la souris.

exemple:
http://jmathtools.sourceforge.net/plot3dapplet.php(...)

m'enfin si l'algo choisi ne donne pas suffisamment de rapidité, je repasse en mode filaire le temps de la rotation et je fais le Z-buffer une fois la position figée...

Autre chose : Je ne souhaite pas avoir recours à du code ou du matériel natif... en clair 100% java.

Encore merci.

(z'êtes mes amis hein ?)
- [^] # Re: performances...
  
  Posté par Jylam / jylam.lnxsce (site web personnel) le 08 août 2005 à 17:35. Évalué à 2.
  
  Allez je me lance.
  
  Donc assez simplement, un zbuffer, c'est tout bete. Quand tu rasterizes tes triangles (ou tes ce-que-tu-veux d'ailleur), tu interpoles les valeurs x et y de tes vertices. de V1 vers V2, de V1 vers V3 (moitié du haut), et de V2 vers v3 et V1 vers V3 (moitié du bas). Ca, je suppose que tu as deja fais.
  Le zbuffer, c'est la meme chose, sachant que tu vas passer a ton rasterizer les valeurs Z des 3 vertices sus-nommés.
  
  Tu vas alors interpoler tes 3 valeurs de la meme maniere, et n'afficher le pixel QUE si la valeur est inferieure a celle deja ecrire dans ton buffer. Si tel est le cas, tu inscris dans ton buffer cette nouvelle valeur Z, et tu passes au pixel suivant.
  
  Avantage, tu as donc une precision de profondeur au pixel.
  Desavantages, deja tu peux avoir un probleme de precision suivant la profondeur du buffer (on utilise en general les valeurs de 1/Z, de facon a etre plus precis pres de la camera, et moins au fond). Ensuite, cela t'oblige a reserver de la memoire de la meme taille X*Y que ton buffer d'affichage, multiplié par la precision (2 pour 16bits, 4 pour 32, etc).
  Dernier probleme, les faces translucides poseront probleme si tu ne fait pas de cas particulier. (trier les faces translucides et les afficher APRES tout le reste, de facon a ne pas oublier d'afficher ce qui se trouve derriere).
  
  Voila, ce n'est surement pas tres clair, mais tu peux voir que c'est quand meme extremement simple pour qui a deja realisé un rasterizer.
  
  (oui et j'utilise plein de mots anglais)
  - [^] # Re: performances...
    
    Posté par yaya le 08 août 2005 à 18:08. Évalué à 1.
    
    Je vois que ça va bouffer pas mal de CPU tout ça...
    déjà que mon moteur 3D est gourmand, ça va être coton.
    (CF l'applet cité dans mon post précédent)
    
    Je me demande si on ne pourrais pas optimiser ce comportement pour des objets plus spécifiques que des points ?
    par exemple on pourrait considérer l'objet "segment de droite" dont le valeur à mettre en Zbuffer serait le Zbuffer du centre....
    idem pour des triangles.
    pour les points c'est plus simple.
    
    Bien sûr cela serait assez inexact localement, mais si les objets sont suffisamment petits (taille des segments), ça pourrait être économique en CPU ?
    - [^] # Re: performances...
      
      Posté par Antoine le 08 août 2005 à 21:17. Évalué à 5.
      
      Bien sûr cela serait assez inexact localement, mais si les objets sont suffisamment petits (taille des segments), ça pourrait être économique en CPU ?
      
      Dans ce cas pas besoin de se faire chier à utiliser un Zbuffer.
      Tu peux utiliser l'algorithme du peintre, c'est-à-dire trier les primitives à afficher (polygones, etc...) de la plus lointaine à la plus proche en considérant par exemple le Z du barycentre de chaque primitive. Ensuite, tu traces les primitives dans l'ordre obtenu.
      Mais le résultat en cas d'intersection risque d'être bien moche.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.