[Orion3d-dev] Displacement Maps

[<nik...@al...>]

Ah, juste un truc pour clore le chapitre sur l'utilisation
des ondelettes de subdivisions (qui visiblement ont un peu de mal à passer).

Pierre, ce que je veux compresser avec cet algo, c'est la displacement map,
dans le but d'optimiser le nombre de polys utilisés pour générer un mesh
aussi précis,
ou alors des textures de bump aussi précises mais moins volumineuses.

Quand je dis "nurbs==no future", c'est pas parcequ'ils sont lisses.
Effectivement, les subdivisions
de surface sont tout aussi lisses. Et ce qu'on veut, c'est rendre des
détails, des irrégularités.
A priori, tout le monde est d'accord que le bon moyen d'encoder ces détails,
c'est une displacement map.
Ce que je veux dire, c'est que le nurbs ne peut pas servir de *bonne*
paramétrisation pour une displacement map. Tout comme le fait d'utiliser
bettement les coordonnées UV
du mesh d'origine (même si c'est ce qu'on fait à l'heure actuel, dans doom3
et cie, je vous assure qu'il y a moyen
de définir des méthodes qui s'optimisent mieux).

Réfléchisser à ceci : vous voulez définir une displacement map sur une
sphere
(par exemple une ampoule dans Doom3 ... ;). Pour ça, votre graphiste
vous génère une map cylindrique, et vous la plaquer bettement sur la sphere,
avec du bump ou
bien des vetrex shader. Vous ne pensez pas qu'on peut faire mieux ?? Entre
autre, il est évident qu'il
y a la fois une grosse distortion et de l'info redondante sur les poles ...

Et bien ce que j'affirme, c'est que pour faire des mesh/du bump très
régulier et optimiser sur *toute* la sphere
(et pas seulement sur l'équateur), il faut disposer d'une paramétrisation
*intrinseque* de la sphere. Et un algorithme
de subdivision fournit -grosso modo- une telle paramétrisation (puisque
toutes les faces ont environ la même aire).

Perso, je pense que ce genre de pbm est très intéressant, et je suis sur
qu'avec des pixel shader, il y a moyen de faire
du code hautement optimisé, tout aussi rapide que le bump ou tout autre
chose utilisé dans Q3, mais avec un rendu des détails
10x plus fin (un gain énorme en terme de distortion par rapport au mesh
ultime rendu sous 3DS).

Gabriel


----- Original Message -----
From: "Gabriel Peyré" <nik...@al...>
To: <ori...@li...>
Sent: Friday, November 29, 2002 5:11 PM
Subject: Re: Subdivision surfaces [was Re: [Orion3d-dev] Pour infos]


> Je me permet de remarquer que tu sous estime nettement les papier écrit au
> calltech
> (entre autre).
> Ca n'a vraiment rien a voir avec du displacement mapping, enfin, c'est
> vraiment le cran au dessus, que ce soit au niveau
> des performance, et aussi et surtout de la précision avec laquelle on peut
> rendre des *DETAILS* avec peu de poly
> (en gros, les algo en ondelettes sont optimaux pour pas mal de classes de
> fonctions).
>
> C'est comme dire que la théorie du filtrage s'est arrété le jour où l'on a
> découvert la FFT ...
>
>
> Gabriel
>
> ----- Original Message -----
> From: "Pierre Terdiman" <p.t...@wa...>
> To: <ori...@li...>
> Sent: Friday, November 29, 2002 1:37 PM
> Subject: Re: Subdivision surfaces [was Re: [Orion3d-dev] Pour infos]
>
>
> (Ca fait bizarre de lire GDA en français! :)
>
> > Déjà, je tiens à dire que ce que je dis n'engage que moi, à priori,
c'est
> > vraiment du délire intellectuel et
> > je n'ai bien sûr ni implémenté ni même testé de loin les algo cités ...
>
> Ok.
>
> > ailleurs, l'idée de la détection de collision à base d'ondelettes
n'engage
> > que Sanx, héhé ;)
>
> (à mon avis, bof, mais bon...)
>
> > [oups...y'a bien les NURBS, mais bon, moi
> > être sur que NURBS=no future]).
>
> En fait, je dirais même que NURBS ou subdivision surfaces, c'est le même
> problème : telles qu'elles, elles produisent beaucoup de "smoothness",
mais
> pas de *détails*. Et la smoothness on s'en fout :) (à quelques exceptions
> près : la peau des persos et les fringues). Je crois que smoothness = no
> future... Le réalisme passe par le détail, les irrégularités /
singularités,
> les imperfections, le fractal, le turbulent... Le bump, par exemple, va
dans
> ce sens. Mais les Nurbs et/ou subdivision surfaces vont en sens inverse,
> produisant de jolies surfaces bien lisses, mathématiquement propres, mais
> bien peu real-world :)
>
> Pour reprendre l'exemple de Doom3, ils n'ont pas des masses de polygônes,
> mais par contre ils foutent des normal maps partout pour capturer les
> détails.
>
> A priori le futur ce serait plutôt une combinaison des deux, genre les
> displaced subdivision surfaces (déjà utilisées dans Startopia d'ailleurs)
ou
> les "geometry images"...
>
> > En fait, peut être j'ai été un peu lapidaire ... il ne s'agit pas
> *vraiment*
> > d'ondelettes,
>
> J'me disais aussi :)
>
>
> > Petit interlude sur l'utilisation des ondelettes "classiques" ...
> > Pour cette applications (celle dont on avait parlé avec S/T/T donc), on
> > avait envisagé
> > des bètes (hum) ondelettes pour représenter un champ de scalaires, et
> faire
> > des opérations
> > dessus (smoothing, [snip]
>
> J'ai pas révisé mes ondelettes depuis un moment (mais j'ai lu le bouquin
de
> Barbara Burke H.), c'est sans doute pour ça que l'intérêt m'échappe. Pour
> prendre un exemple que je connais, quelle est la différence entre du
> smoothing avec et sans ondelettes ? Ca intervient où les ondelettes ? Pour
> smoother "plus" les endroits où les coeffs sont plus gros ?
>
> >check rapide pour collisions isosurfaces/objets à l'aide
> > de bounding box
> > autour des ondellettes de grandes amplitudes, etc.).
>
> Beuh....
>
> > En ce qui concerne ce que j'appellerais "ondelettes et subdivision", il
> > s'agit de construire des
> > ondelettes qui sont à valeur sur le mesh, et qui sont construite en
> > utilisant un procédé de subdivision
> > type catmull/loop/etc.
>
> Ok.
>
> > Je m'explique : on peut voir le mesh subdivisé à l'infini comme une
> surface
> > "lisse" (manifold en english).
>
> Voui. Même si dans le monde réel, tu exportes de MAX et vlam, des
> non-manifold meshes partout :)
>
> > Les différentes étapes de subdivisions donnent donc des versions de plus
> en
> > plus raffinée, un LOD
> > qui part de 0 (mesh), puis 1, puis 2, etc.
> > Jusqu'à là, rien de révolutionnaire, comme le dit Pierre, c'est du old
> > school ;-)
> > Je ne suis pas dans le milieu du jeu vidéo (un jour ?), mais je suppose
> que
> > de nombreux jeux utilisent
> > ce genre de technique pour générer leur LOD (du moins, puisque 3DSMax
sait
> > le faire, de nombreux
> > graphistes utilisent *implicitement* cette technique).
>
> Pas forcément ! :)
>
> Ca, c'est pratique pour faire low-poly => high-poly automatiquement. Dans
> MAX, ce serait le "mesh smooth". C'est utilisé, mais surtout pendant
> l'édition, pour créer le mesh "high poly", pas trop pour faire les LODs.
Par
> ailleurs c'est rarement utilisé tout seul, en général le gars subdivise le
> mesh et bouge les faces à la pogne derrière.
>
> D'habitude les algos de LOD (je veux dire, ceux qui sont vraiment utilisés
> dans les jeux) font l'inverse: ils prennent le mesh de MAX comme mesh
"high
> poly", et le réduisent à coups de progressive meshes (a.k.a. VIPM et
tout).
>
> > Mais que veut donc représenter en ondelettes ? Je (hum hum, enfin,
"ils")
> > propose
> > d'utiliser un normal mesh
> > http://www.multires.caltech.edu/pubs/kompress.pdf
> > Notre CMesh_k est définit de la facçon :
> > CMesh_k = Mesh_k + VMesh_k*normales
> > c.a.d. on peut voir notre mesh comme une "fonction" définie sur le
> manifold
> > Mesh_k.
>
> Certes, m'enfin c'est du bon vieux displacement mapping :) J'imagine que
les
> LODs y sont gérés automatiquement en mip-mappant les displacement maps
(dans
> DX9). Non ?
>
> > Mais quelles différences par rapport à une bête subdivision du mesh ?
> PLEINS
> > !
> > En fait, cette procédure est ultra continue : on va pouvoir obtenir
pleins
> > de lods intermédiaires.
>
> Je me demande ce que ça fait du trilinear filtering sur des displacement
> maps ? Quelqu'un a pu tester ça ?? (j'ai pas de Parhelia et encore moins
> DX9).
>
> > Et en plus, il seront vachement plus optimisés que le mesh subdivisé (-
de
> > vertex aux endroits
> > où on n'en a pas besoin).
>
> Je suis d'accord, mais malheureusement on ne crée pas les LODs juste en
> subdivisant un mesh ! Y'a eu des essais, mais c'est casse gueule
(notamment
> à cause des non-manifold meshes et des
>
déformations-de-texture-quand-on-subdivise-les-UVs-que-de-toute-manière-y'a-
> une-patent-de-Pixar-on-a-pas-le-droit :). Et surtout, ça n'apporte pas
grand
> chose à part la smoothness évoquée plus haut....
>
> > Comme vous pouvez le constater, cet algo est vraiment proche d'un algo
> > optimal de compression avec perte
> > d'un mesh.
>
> Par contre pour de la compression, ouais, ok....
>
> Pierre
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Get the new Palm Tungsten T
> handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
> _______________________________________________
> Orion3d-dev mailing list
> Ori...@li...
> https://lists.sourceforge.net/lists/listinfo/orion3d-dev
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Get the new Palm Tungsten T
> handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
> _______________________________________________
> Orion3d-dev mailing list
> Ori...@li...
> https://lists.sourceforge.net/lists/listinfo/orion3d-dev