Menu
▾
▴
orion3d-dev — mailling list des développeurs d'Orion3D
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
(123) |
Dec
(64) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(163) |
Feb
(162) |
Mar
(64) |
Apr
(132) |
May
(174) |
Jun
(138) |
Jul
(89) |
Aug
(174) |
Sep
(63) |
Oct
(164) |
Nov
(97) |
Dec
(48) |
| 2002 |
Jan
(21) |
Feb
(32) |
Mar
(19) |
Apr
(14) |
May
(14) |
Jun
(12) |
Jul
(8) |
Aug
(5) |
Sep
(22) |
Oct
(16) |
Nov
(69) |
Dec
(20) |
| 2003 |
Jan
(2) |
Feb
|
Mar
(5) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2004 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(17) |
| 2007 |
Jan
(5) |
Feb
(5) |
Mar
(2) |
Apr
(4) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2008 |
Jan
|
Feb
(2) |
Mar
(2) |
Apr
(4) |
May
(2) |
Jun
(1) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(13) |
| 2009 |
Jan
(25) |
Feb
(7) |
Mar
(17) |
Apr
(33) |
May
(88) |
Jun
(93) |
Jul
(33) |
Aug
(25) |
Sep
(29) |
Oct
(45) |
Nov
(4) |
Dec
(2) |
| 2010 |
Jan
(1) |
Feb
|
Mar
(31) |
Apr
(59) |
May
(74) |
Jun
(71) |
Jul
(39) |
Aug
(52) |
Sep
(18) |
Oct
(1) |
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
(2) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Antoche <an...@al...> - 2002-12-26 14:41:46
|
>Dans le genre, y'a aussi BoundsChecker qui est vachement bien. Ouais y parait qu'il est bien mais j'ai jamais pu l'essayer. L=E0 j'ai un= e vieille version de Purify et elle commence =E0 montrer ses limites. Elle = est pu compatible avec VC6SP5 et me balance des erreurs internes. Je voulais m'en servir pour d=E9bugger un autre projet, mais elle veut rien savoir. = Je testerais avec une nouvelle version =E0 la rentr=E9e. >Sinon pour les memory leaks y'a aussi =E7a : >http://www.flipcode.com/cgi-bin/msg.cgi?showThread=3DTip-MemoryLeaksInVC= &foru m=3Dtotd&id=3D-1 >...un peu limit=E9, mais bon... Oui j'ai d=E9j=E0 essay=E9 un peu les fonctions CRT debug mais c vraiment= quasi inutilisable. J'avais aussi commenc=E9 =E0 faire un petit outil de d=E9te= ction de mem leaks pendant mon dernier stage, en overridant les new/delete et compagnie, mais bon c'est quand m=EAme bcp moins puissant que les logicie= ls d=E9di=E9s. Antoche ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Orion3d-dev mailing list Ori...@li... https://lists.sourceforge.net/lists/listinfo/orion3d-dev |
|
From: Pierre T. <p.t...@wa...> - 2002-12-26 10:55:54
|
>Hier j'ai install=E9 Rational Purify et j'ai jou=E9 un peu avec, c'est
vachement
>pratique parce que ca te dit non seulement quand tu fais des memory leak=
s
ou
>que tu =E9cris =E0 des endroits pas autoris=E9s, mais =E7a t'informe aus=
si de ces
>UMC ("uninitalized memory copy"). Comme =E7a j'ai pu corriger qq mem lea=
ks
>(par exemple dans le Shell Kernel qui delete pas les fonctions =E0 la fi=
n).
>C'est vraiment super sympathique quand tu sais t'en servir et que =E7a p=
lante
>pas. Je vais m'en servir sur tous les samples pour cleaner bien le code.
Dans le genre, y'a aussi BoundsChecker qui est vachement bien.
Sinon pour les memory leaks y'a aussi =E7a :
http://www.flipcode.com/cgi-bin/msg.cgi?showThread=3DTip-MemoryLeaksInVC&=
forum
=3Dtotd&id=3D-1
...un peu limit=E9, mais bon...
|
|
From: Antoche <an...@al...> - 2002-12-25 22:48:42
|
>ok, que de bonnes id=E9es :) > >pour les "wait", tu boules sur tout ceux qui attendent (enfin, avec un n= br >d'it=E9rations limit=E9s peut etre) >en attendant que les diff=E9rents conflits se r=E8glent ? Ouais voil=E0. Je te conseille vivement de regarder le truc de Paul Nettle : http://www.flipcode.com/cgi-bin/msg.cgi?showThread=3D12-05-2002&forum=3Di= otd&id=3D -1 son IOTD http://www.openarchitect3d.org/ le site =E0 propos de sa chose http://www.flipcode.com/cgi-bin/msg.cgi?showThread=3D00001536&forum=3Dran= dombits &id=3D-1 la discussion sur flipcode =E0 propos de ca Y'a s=FBrement pas mal de bonnes id=E9es =E0 glaner sur le fonctionnement= d'une architecture 3D =E0 base de plug-ins (et chuis s=FBr que Sanx aussi a ple= in de suggestions =E0 nous donner ;)). >pour les plugins empil=E9, =E0 priori, oui, c comme =E7a que je comptais= coder les >diff=E9rentes passes (faut juste que je rajoute >des callback pour apr=E8s le rendu, et c'est une id=E9e naturelle de les >d=E9rouler dans le sens inverse). ok cool a+ Antoche >ciao > >Gabriel ----- Original Message ----- From: "Antoche" <an...@al...> To: <ori...@li...> Sent: Tuesday, December 24, 2002 2:54 PM Subject: [Orion3d-dev] RE: [Orion3d-dev] Re: [Orion3d-dev] Bug release r=E9= gl=E9 Je suppose que les dll de la libc de debug font un peu de "pr=E9vention", genre quand t'alloues qq chose =E7a remplis la m=E9moire avec des trucs e= t ca alloue un peu avant et apr=E8s en cas de d=E9bordement (il me semble avoi= r lu =E7a dans le MSDN), tandis qu'en release =E7a fait rien du tout du coup la val= eur n'est pas la m=EAme... Je viens de corriger le m=EAme genre de probl=E8me dans les Track : j'ava= is rajout=E9 une cache de la derni=E8re valeur calcul=E9e (et du temps assoc= i=E9) pour que, quand l'anim est en pause, le track ne recalcule pas =E0 chaque fois= la valeur. Manque de bol, j'avais oubli=E9 d'initialiser le temps de cette derni=E8re valeur dans un des constructeur. Hier j'ai install=E9 Rational Purify et j'ai jou=E9 un peu avec, c'est va= chement pratique parce que ca te dit non seulement quand tu fais des memory leaks= ou que tu =E9cris =E0 des endroits pas autoris=E9s, mais =E7a t'informe auss= i de ces UMC ("uninitalized memory copy"). Comme =E7a j'ai pu corriger qq mem leak= s (par exemple dans le Shell Kernel qui delete pas les fonctions =E0 la fin= ). C'est vraiment super sympathique quand tu sais t'en servir et que =E7a pl= ante pas. Je vais m'en servir sur tous les samples pour cleaner bien le code. Pour le syst=E8me de plug-in, je pensais que ce serais pratique de les aj= outer sous forme de "pile" : l'utilisateur ajoute les plug-ins un =E0 un. Le renderer appelle d'abord une premi=E8re fonction "StartRender" pour chaqu= e plug-in dans l'ordre d'ajout, puis "EndRender" dans l'ordre inverse. Comm= e =E7a, imagine qu'on ait un plug-in "motion blur" : celui-ci doit faire de= s trucs avant tout le dessin et apr=E8s tout le dessin. Donc l'utilisateur ajoute d'abord le plug-in "motion blur", puis le plug-in "hierarchy tree"= , etc, et comme =E7a =E7a peut fonctionner. Autre id=E9e, plut=F4t =E0 propos de la serialization, qui pourrait =E9li= miner les post-export pass reloues : quand le serializer a fini de lire un serializable, il appelle une fonction (genre SerialInit) qui renvoit soit "OK", soit "Fail", soit "Wait". Dans le 3e cas, le serializer rappellera cette fonction =E0 la fin quand il aura charg=E9 le reste. Ainsi, si un serializable d=E9pend d'un autre qui n'a pas encore =E9t=E9 load=E9 parce= qu'il est plus apr=E8s dans le fichier, il attend que cet bidule soit charg=E9 pour r=E9pondre "OK". Ca r=E9soud tr=E8s simplement les d=E9pendances entre ob= jets. Paul Nettle (ak Midnight, un gourou de flipcode) utilise ce syst=E8me pour un = de ses projets massivement bas=E9 sur les plug-ins, et ca m'a l'air tr=E8s pratique. Voil=E0, =E0 part =E7a, ben joyeux no=EBl ! :) Antoche -----Message d'origine----- De : ori...@li... [mailto:ori...@li...]De la part de Gabriel Peyr=E9 Envoy=E9 : lundi 23 d=E9cembre 2002 17:11 =C0 : ori...@li... Objet : [Orion3d-dev] Re: [Orion3d-dev] Bug release r=E9gl=E9 ok cool ... mais pourquoi =E7a marchait en debug ?? d=E9s que j'ai le temps (c'est les vacances :), je clean le code d'orion3= d avec la s=E9rie de plugin promis, ce qui devrait all=E9ger le code. si Toche tu as des id=E9es pour am=E9liorer les plugins (et/ou en faire p= our les bsp/q3), ne te g=E8ne pas ! et pis j'essaierais de recompiler le plugin sous max5 gabriel ----- Original Message ----- From: "Antoche" <an...@al...> To: "Orion3D-dev" <ori...@li...> Sent: Monday, December 23, 2002 4:23 PM Subject: [Orion3d-dev] Bug release r=E9gl=E9 Il y avait un probl=E8me (parmi d'autres) lorsqu'on lan=E7ait un exe util= isant Orion3D hors du debugger, particuli=E8rement horripilant, qui faisait qu'= en fait on ne voyait rien de rien, la fen=EAtre restait d=E9sesp=E9r=E9ment = noire... Je viens enfin de localiser et d'=E9radiquer cette petite saloperie. Je vous= la donne en mille rien que pour le plaisir : l'attribut IsActive de OR_Viewp= ort n'=E9tait pas initialis=E9 dans le constructeur, du coup le debugger le m= ettait =E0 1 et quand on le lan=E7ait en dehors du debugger il valait 0... Donc voil=E0, maintenant on voit la m=EAme chose dans tous les modes (c'e= st gabi qui va =EAtre content), je met le fix sur le CVS bient=F4t. Antoche ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Orion3d-dev mailing list Ori...@li... https://lists.sourceforge.net/lists/listinfo/orion3d-dev ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Orion3d-dev mailing list Ori...@li... https://lists.sourceforge.net/lists/listinfo/orion3d-dev ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Orion3d-dev mailing list Ori...@li... https://lists.sourceforge.net/lists/listinfo/orion3d-dev ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Orion3d-dev mailing list Ori...@li... https://lists.sourceforge.net/lists/listinfo/orion3d-dev |
|
From: <nik...@al...> - 2002-12-24 15:00:44
|
ok, que de bonnes idées :)
pour les "wait", tu boules sur tout ceux qui attendent (enfin, avec un nbr
d'itérations limités peut etre)
en attendant que les différents conflits se règlent ?
pour les plugins empilé, à priori, oui, c comme ça que je comptais coder les
différentes passes (faut juste que je rajoute
des callback pour après le rendu, et c'est une idée naturelle de les
dérouler dans le sens inverse).
ciao
Gabriel
----- Original Message -----
From: "Antoche" <an...@al...>
To: <ori...@li...>
Sent: Tuesday, December 24, 2002 2:54 PM
Subject: [Orion3d-dev] RE: [Orion3d-dev] Re: [Orion3d-dev] Bug release réglé
Je suppose que les dll de la libc de debug font un peu de "prévention",
genre quand t'alloues qq chose ça remplis la mémoire avec des trucs et ca
alloue un peu avant et après en cas de débordement (il me semble avoir lu ça
dans le MSDN), tandis qu'en release ça fait rien du tout du coup la valeur
n'est pas la même...
Je viens de corriger le même genre de problème dans les Track : j'avais
rajouté une cache de la dernière valeur calculée (et du temps associé) pour
que, quand l'anim est en pause, le track ne recalcule pas à chaque fois la
valeur. Manque de bol, j'avais oublié d'initialiser le temps de cette
dernière valeur dans un des constructeur.
Hier j'ai installé Rational Purify et j'ai joué un peu avec, c'est vachement
pratique parce que ca te dit non seulement quand tu fais des memory leaks ou
que tu écris à des endroits pas autorisés, mais ça t'informe aussi de ces
UMC ("uninitalized memory copy"). Comme ça j'ai pu corriger qq mem leaks
(par exemple dans le Shell Kernel qui delete pas les fonctions à la fin).
C'est vraiment super sympathique quand tu sais t'en servir et que ça plante
pas. Je vais m'en servir sur tous les samples pour cleaner bien le code.
Pour le système de plug-in, je pensais que ce serais pratique de les ajouter
sous forme de "pile" : l'utilisateur ajoute les plug-ins un à un. Le
renderer appelle d'abord une première fonction "StartRender" pour chaque
plug-in dans l'ordre d'ajout, puis "EndRender" dans l'ordre inverse. Comme
ça, imagine qu'on ait un plug-in "motion blur" : celui-ci doit faire des
trucs avant tout le dessin et après tout le dessin. Donc l'utilisateur
ajoute d'abord le plug-in "motion blur", puis le plug-in "hierarchy tree",
etc, et comme ça ça peut fonctionner.
Autre idée, plutôt à propos de la serialization, qui pourrait éliminer les
post-export pass reloues : quand le serializer a fini de lire un
serializable, il appelle une fonction (genre SerialInit) qui renvoit soit
"OK", soit "Fail", soit "Wait". Dans le 3e cas, le serializer rappellera
cette fonction à la fin quand il aura chargé le reste. Ainsi, si un
serializable dépend d'un autre qui n'a pas encore été loadé parce qu'il est
plus après dans le fichier, il attend que cet bidule soit chargé pour
répondre "OK". Ca résoud très simplement les dépendances entre objets. Paul
Nettle (ak Midnight, un gourou de flipcode) utilise ce système pour un de
ses projets massivement basé sur les plug-ins, et ca m'a l'air très
pratique.
Voilà, à part ça, ben joyeux noël ! :)
Antoche
-----Message d'origine-----
De : ori...@li...
[mailto:ori...@li...]De la part de Gabriel
Peyré
Envoyé : lundi 23 décembre 2002 17:11
À : ori...@li...
Objet : [Orion3d-dev] Re: [Orion3d-dev] Bug release réglé
ok cool ...
mais pourquoi ça marchait en debug ??
dés que j'ai le temps (c'est les vacances :), je clean le code d'orion3d
avec la série de plugin promis, ce qui devrait alléger le code.
si Toche tu as des idées pour améliorer les plugins (et/ou en faire pour les
bsp/q3), ne te gène pas !
et pis j'essaierais de recompiler le plugin sous max5
gabriel
----- Original Message -----
From: "Antoche" <an...@al...>
To: "Orion3D-dev" <ori...@li...>
Sent: Monday, December 23, 2002 4:23 PM
Subject: [Orion3d-dev] Bug release réglé
Il y avait un problème (parmi d'autres) lorsqu'on lançait un exe utilisant
Orion3D hors du debugger, particulièrement horripilant, qui faisait qu'en
fait on ne voyait rien de rien, la fenêtre restait désespérément noire... Je
viens enfin de localiser et d'éradiquer cette petite saloperie. Je vous la
donne en mille rien que pour le plaisir : l'attribut IsActive de OR_Viewport
n'était pas initialisé dans le constructeur, du coup le debugger le mettait
à 1 et quand on le lançait en dehors du debugger il valait 0...
Donc voilà, maintenant on voit la même chose dans tous les modes (c'est gabi
qui va être content), je met le fix sur le CVS bientôt.
Antoche
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Orion3d-dev mailing list
Ori...@li...
https://lists.sourceforge.net/lists/listinfo/orion3d-dev
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Orion3d-dev mailing list
Ori...@li...
https://lists.sourceforge.net/lists/listinfo/orion3d-dev
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Orion3d-dev mailing list
Ori...@li...
https://lists.sourceforge.net/lists/listinfo/orion3d-dev
|
|
From: Antoche <an...@al...> - 2002-12-24 13:47:51
|
Je suppose que les dll de la libc de debug font un peu de "pr=E9vention",
genre quand t'alloues qq chose =E7a remplis la m=E9moire avec des trucs e=
t ca
alloue un peu avant et apr=E8s en cas de d=E9bordement (il me semble avoi=
r lu =E7a
dans le MSDN), tandis qu'en release =E7a fait rien du tout du coup la val=
eur
n'est pas la m=EAme...
Je viens de corriger le m=EAme genre de probl=E8me dans les Track : j'ava=
is
rajout=E9 une cache de la derni=E8re valeur calcul=E9e (et du temps assoc=
i=E9) pour
que, quand l'anim est en pause, le track ne recalcule pas =E0 chaque fois=
la
valeur. Manque de bol, j'avais oubli=E9 d'initialiser le temps de cette
derni=E8re valeur dans un des constructeur.
Hier j'ai install=E9 Rational Purify et j'ai jou=E9 un peu avec, c'est va=
chement
pratique parce que ca te dit non seulement quand tu fais des memory leaks=
ou
que tu =E9cris =E0 des endroits pas autoris=E9s, mais =E7a t'informe auss=
i de ces
UMC ("uninitalized memory copy"). Comme =E7a j'ai pu corriger qq mem leak=
s
(par exemple dans le Shell Kernel qui delete pas les fonctions =E0 la fin=
).
C'est vraiment super sympathique quand tu sais t'en servir et que =E7a pl=
ante
pas. Je vais m'en servir sur tous les samples pour cleaner bien le code.
Pour le syst=E8me de plug-in, je pensais que ce serais pratique de les aj=
outer
sous forme de "pile" : l'utilisateur ajoute les plug-ins un =E0 un. Le
renderer appelle d'abord une premi=E8re fonction "StartRender" pour chaqu=
e
plug-in dans l'ordre d'ajout, puis "EndRender" dans l'ordre inverse. Comm=
e
=E7a, imagine qu'on ait un plug-in "motion blur" : celui-ci doit faire de=
s
trucs avant tout le dessin et apr=E8s tout le dessin. Donc l'utilisateur
ajoute d'abord le plug-in "motion blur", puis le plug-in "hierarchy tree"=
,
etc, et comme =E7a =E7a peut fonctionner.
Autre id=E9e, plut=F4t =E0 propos de la serialization, qui pourrait =E9li=
miner les
post-export pass reloues : quand le serializer a fini de lire un
serializable, il appelle une fonction (genre SerialInit) qui renvoit soit
"OK", soit "Fail", soit "Wait". Dans le 3e cas, le serializer rappellera
cette fonction =E0 la fin quand il aura charg=E9 le reste. Ainsi, si un
serializable d=E9pend d'un autre qui n'a pas encore =E9t=E9 load=E9 parce=
qu'il est
plus apr=E8s dans le fichier, il attend que cet bidule soit charg=E9 pour
r=E9pondre "OK". Ca r=E9soud tr=E8s simplement les d=E9pendances entre ob=
jets. Paul
Nettle (ak Midnight, un gourou de flipcode) utilise ce syst=E8me pour un =
de
ses projets massivement bas=E9 sur les plug-ins, et ca m'a l'air tr=E8s
pratique.
Voil=E0, =E0 part =E7a, ben joyeux no=EBl ! :)
Antoche
-----Message d'origine-----
De : ori...@li...
[mailto:ori...@li...]De la part de Gabriel
Peyr=E9
Envoy=E9 : lundi 23 d=E9cembre 2002 17:11
=C0 : ori...@li...
Objet : [Orion3d-dev] Re: [Orion3d-dev] Bug release r=E9gl=E9
ok cool ...
mais pourquoi =E7a marchait en debug ??
d=E9s que j'ai le temps (c'est les vacances :), je clean le code d'orion3=
d
avec la s=E9rie de plugin promis, ce qui devrait all=E9ger le code.
si Toche tu as des id=E9es pour am=E9liorer les plugins (et/ou en faire p=
our les
bsp/q3), ne te g=E8ne pas !
et pis j'essaierais de recompiler le plugin sous max5
gabriel
----- Original Message -----
From: "Antoche" <an...@al...>
To: "Orion3D-dev" <ori...@li...>
Sent: Monday, December 23, 2002 4:23 PM
Subject: [Orion3d-dev] Bug release r=E9gl=E9
Il y avait un probl=E8me (parmi d'autres) lorsqu'on lan=E7ait un exe util=
isant
Orion3D hors du debugger, particuli=E8rement horripilant, qui faisait qu'=
en
fait on ne voyait rien de rien, la fen=EAtre restait d=E9sesp=E9r=E9ment =
noire... Je
viens enfin de localiser et d'=E9radiquer cette petite saloperie. Je vous=
la
donne en mille rien que pour le plaisir : l'attribut IsActive de OR_Viewp=
ort
n'=E9tait pas initialis=E9 dans le constructeur, du coup le debugger le m=
ettait
=E0 1 et quand on le lan=E7ait en dehors du debugger il valait 0...
Donc voil=E0, maintenant on voit la m=EAme chose dans tous les modes (c'e=
st gabi
qui va =EAtre content), je met le fix sur le CVS bient=F4t.
Antoche
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Orion3d-dev mailing list
Ori...@li...
https://lists.sourceforge.net/lists/listinfo/orion3d-dev
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Orion3d-dev mailing list
Ori...@li...
https://lists.sourceforge.net/lists/listinfo/orion3d-dev
|
|
From: <nik...@al...> - 2002-12-23 16:11:55
|
ok cool ... mais pourquoi ça marchait en debug ?? dés que j'ai le temps (c'est les vacances :), je clean le code d'orion3d avec la série de plugin promis, ce qui devrait alléger le code. si Toche tu as des idées pour améliorer les plugins (et/ou en faire pour les bsp/q3), ne te gène pas ! et pis j'essaierais de recompiler le plugin sous max5 gabriel ----- Original Message ----- From: "Antoche" <an...@al...> To: "Orion3D-dev" <ori...@li...> Sent: Monday, December 23, 2002 4:23 PM Subject: [Orion3d-dev] Bug release réglé Il y avait un problème (parmi d'autres) lorsqu'on lançait un exe utilisant Orion3D hors du debugger, particulièrement horripilant, qui faisait qu'en fait on ne voyait rien de rien, la fenêtre restait désespérément noire... Je viens enfin de localiser et d'éradiquer cette petite saloperie. Je vous la donne en mille rien que pour le plaisir : l'attribut IsActive de OR_Viewport n'était pas initialisé dans le constructeur, du coup le debugger le mettait à 1 et quand on le lançait en dehors du debugger il valait 0... Donc voilà, maintenant on voit la même chose dans tous les modes (c'est gabi qui va être content), je met le fix sur le CVS bientôt. Antoche ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Orion3d-dev mailing list Ori...@li... https://lists.sourceforge.net/lists/listinfo/orion3d-dev |
|
From: Antoche <an...@al...> - 2002-12-23 15:16:50
|
Il y avait un probl=E8me (parmi d'autres) lorsqu'on lan=E7ait un exe util= isant Orion3D hors du debugger, particuli=E8rement horripilant, qui faisait qu'= en fait on ne voyait rien de rien, la fen=EAtre restait d=E9sesp=E9r=E9ment = noire... Je viens enfin de localiser et d'=E9radiquer cette petite saloperie. Je vous= la donne en mille rien que pour le plaisir : l'attribut IsActive de OR_Viewp= ort n'=E9tait pas initialis=E9 dans le constructeur, du coup le debugger le m= ettait =E0 1 et quand on le lan=E7ait en dehors du debugger il valait 0... Donc voil=E0, maintenant on voit la m=EAme chose dans tous les modes (c'e= st gabi qui va =EAtre content), je met le fix sur le CVS bient=F4t. Antoche |
|
From: <wis...@ya...> - 2002-12-06 18:55:10
|
> Un point important : la démo 3D n'est pas > représentative du projet, le coeur > du moteur consiste > en un codeur (compresseur) et une lib avec un panel > de transformations en > ondelette. oui biensur, qd je pensais a ramer je ne pensais pas en terme de la demo 3d, > A priori, la compression est très rapide (<< une > seconde), je pense que > c'est nettement suffisant pour ne plus > s'intéresser qu'aux taux de compression. > Les graphs de PSNR sont bons, pas exceptionnels par > rapport à ce qui se fait > en compression d'image. Mais comme > c'est de la compression sphérique, c'est > difficilement comparable. > > En ce qui concerne la suite du projet, ça va > dépendre des échos que j'aurais > dans le monde industriel, voir de la recherche, qui > sait ... > En tout cas, je pense que c'est pas du tout > révolutionnaire, mais les idées > qui font leur chemin à l'heure actuellle y sont > présente. > > D'un point de vu plus pragmatique, disons que ça > devrait me permettre de > présenter des résultats concluant pour inciter > à signer pour 3 ans de thèse (j'ai un RDV next week, > donc il faut que j'ai de beau graph avec moi) ... ok, ma question etait principalement oriente vers le futur de cette lib en tant que "projet" communautaire. Mais tu as repondu a ma question, apparement tu as une vue plus oriente "utilite pragmatique" et utilisation recherche/indus (+these). Tu vas te servir de cette appli pour appuyer ta demande de these ? (En tant que preliminaire a l'orientation principale de ta these) > Si tu connais des gens potentiellement intéréssés, > n'hésite pas à forwarder > l'adresse. Je ne pense pas mais qui sait ... Alex ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com |
|
From: <nik...@al...> - 2002-12-06 15:29:18
|
Un point important : la démo 3D n'est pas représentative du projet, le coeur du moteur consiste en un codeur (compresseur) et une lib avec un panel de transformations en ondelette. A priori, la compression est très rapide (<< une seconde), je pense que c'est nettement suffisant pour ne plus s'intéresser qu'aux taux de compression. Les graphs de PSNR sont bons, pas exceptionnels par rapport à ce qui se fait en compression d'image. Mais comme c'est de la compression sphérique, c'est difficilement comparable. En ce qui concerne la suite du projet, ça va dépendre des échos que j'aurais dans le monde industriel, voir de la recherche, qui sait ... En tout cas, je pense que c'est pas du tout révolutionnaire, mais les idées qui font leur chemin à l'heure actuellle y sont présente. D'un point de vu plus pragmatique, disons que ça devrait me permettre de présenter des résultats concluant pour inciter à signer pour 3 ans de thèse (j'ai un RDV next week, donc il faut que j'ai de beau graph avec moi) ... Si tu connais des gens potentiellement intéréssés, n'hésite pas à forwarder l'adresse. Gabriel ----- Original Message ----- From: "Alex ABREU" <wis...@ya...> To: "Gabriel_Peyré" <nik...@al...>; <ori...@li...>; <ori...@li...> Sent: Friday, December 06, 2002 4:10 PM Subject: Re: [Orion3d-maths] il est pas frais mon poisson ? > > Non mais il ne faut pas s'arréter au titre ;-) > > Normalement, ça compresse vraiment, et pas que du > > poisson ... [ok, c pourri > > ...]. > > > > Si vous remarquez des pbm d'incompatibilités (autres > > que "ça rame sur ma > > machine"), ça serait cool > > de me les signaler. > > Ca fonctionne chez moi, pour dire que "ca rame" il > faudrait un quelconque point de comparaison. > > Quelles evolutions prevues pour ce projet ? (ajouts, > bindings, participation exterieur, ...) > > -- > Alexandre Abreu > > > > ___________________________________________________________ > Soyez solidaire soutenez l'action du Téléthon avec Yahoo! France. > http://www1.telethon.fr/030-Espace-Relais-Dons/webtirelire1.asp?hebergeur_id =1309 |
|
From: <wis...@ya...> - 2002-12-06 15:10:22
|
> Non mais il ne faut pas s'arréter au titre ;-) > Normalement, ça compresse vraiment, et pas que du > poisson ... [ok, c pourri > ...]. > > Si vous remarquez des pbm d'incompatibilités (autres > que "ça rame sur ma > machine"), ça serait cool > de me les signaler. Ca fonctionne chez moi, pour dire que "ca rame" il faudrait un quelconque point de comparaison. Quelles evolutions prevues pour ce projet ? (ajouts, bindings, participation exterieur, ...) -- Alexandre Abreu ___________________________________________________________ Soyez solidaire soutenez laction du Téléthon avec Yahoo! France. http://www1.telethon.fr/030-Espace-Relais-Dons/webtirelire1.asp?hebergeur_id=1309 |
|
From: <nik...@al...> - 2002-12-06 14:21:01
|
Non mais il ne faut pas s'arréter au titre ;-) Normalement, ça compresse vraiment, et pas que du poisson ... [ok, c pourri ...]. Si vous remarquez des pbm d'incompatibilités (autres que "ça rame sur ma machine"), ça serait cool de me les signaler. Gabriel ----- Original Message ----- From: "Alex ABREU" <wis...@ya...> To: "Gabriel_Peyré" <nik...@al...>; <ori...@li...>; <ori...@li...> Sent: Friday, December 06, 2002 2:45 PM Subject: [Orion3d-dev] Re: [Orion3d-maths] il est pas frais mon poisson ? > > Voilà, j'ai fait une démo toute jolie pour mes > > petites ondelettes > > sphériques, j'espère que ça vous plaira, même > > si le maniement n'est pas hyper intuitif ... > > > > http://nikopol0.alrj.org/fsw/ > > Rien que le titre deja ca vaut la peine ... > > -- > Alexandre abreu > > > ___________________________________________________________ > Soyez solidaire soutenez l'action du Téléthon avec Yahoo! France. > http://www1.telethon.fr/030-Espace-Relais-Dons/webtirelire1.asp?hebergeur_id =1309 > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Orion3d-dev mailing list > Ori...@li... > https://lists.sourceforge.net/lists/listinfo/orion3d-dev |
|
From: <wis...@ya...> - 2002-12-06 13:45:12
|
> Voilà, j'ai fait une démo toute jolie pour mes > petites ondelettes > sphériques, j'espère que ça vous plaira, même > si le maniement n'est pas hyper intuitif ... > > http://nikopol0.alrj.org/fsw/ Rien que le titre deja ca vaut la peine ... -- Alexandre abreu ___________________________________________________________ Soyez solidaire soutenez laction du Téléthon avec Yahoo! France. http://www1.telethon.fr/030-Espace-Relais-Dons/webtirelire1.asp?hebergeur_id=1309 |
|
From: <nik...@al...> - 2002-12-06 11:47:54
|
Voilà, j'ai fait une démo toute jolie pour mes petites ondelettes sphériques, j'espère que ça vous plaira, même si le maniement n'est pas hyper intuitif ... http://nikopol0.alrj.org/fsw/ Si vous avez 5 minutes à me consacrer pour me dire ce que vous pensez de la démo (bugs ? améliorations ?), du site, des résultats, ça serait cool. Sinon, pour Pierre : normalement, je risque de faire une thèse qui rejoint (de loin) la discussion qu'on a eu sur la ML, donc je vais pouvoir te convaincre de l'utilité des ondelettes pour le design de meshs low polys ;-) [prévois 2/3 ans sur ton emploi du temps ...] Gabriel. |
|
From: <nik...@al...> - 2002-12-03 22:52:51
|
J'ai mis sur pied la page web du projet sur les ondelettes sphériques : http://nikopol0.alrj.org/fsw Malheureusement, j'ai qq problèmes pour faire la release de la démo technique ... Disons que mon appli tourne parfaitement en mode release sous visual, mais dés que je la lance depuis l'explorer windows, écran noir (tout marche nikel, seul le rendu foire). Je vais essayer de fixer ce bug au plus vite. En attendant, vous pouvez toujours matter les qq screenshots. Gabriel. |
|
From: Laurent M. <lau...@fx...> - 2002-12-01 15:05:30
|
[Gab:] > Tu pourrais d=E9crire un peu en d=E9tail de tool d'ATI ? > Je suis un peu fl=E9mard, peut =EAtre j'irais regarder ... Bien ca s'utilise super simplement, par contre il n'y a pas le code du processing. Pour les graphistes j'ai =E9crit 2 lignes pour faire une FAQ : Q: Comment utiliser le normal mapping ? A: En attendant une documentation compl=E9mentaire, ou une int=E9gration tr= ansparente, voil=E0 comment proceder, pour l'installation :=20 * R=E9ccuperer l'utilitaire d'ATI - Normal Mapper (http://www.ati.com/deve= loper/normalmapper.zip) * Installer le plugin pour MAX 4.x pour exporter en MNF : MAXExportNMF.dle.=20 A l'utilisation : pour creer ca normal map, faire 2 scenes 3dsmax (attention le plugin ne distingue pas les objets cach=E9s)=20 * Scene 1 : La sc=E8ne en high poly.=20 * Scene 2 : La sc=E8ne en low poly. La sc=E8ne 2 doit posseder des coordonn=E9es UV unwrapp=E9e, pour que l'outil puisse g=E9n=E9rer la normal map avec ces coordonn=E9es de texture.=20 * Exporter chacune des sc=E8nes en fichier .NMF (il est conseill=E9 d'utiliser <scene>_high.nmf pour le high poly, et <scene>_low.nmf, pour le low poly).=20 * Utiliser en ligne de commande :=20 NormalMapper <scene>_low.nmf <scene>_high.nmf 1024 1024 <scene>_normals.tga Le calcul peut =EAtre assez long, il est conseill=E9 d'utiliser une r=E9sol= ution plus petite pour la texture tant qu'il s'agit de tests.=20 * Pour exporter la Normal Map, et la mettre dans le slot Bump du Material de 3dsmax.=20 * Ensuite exporter la sc=E8ne.=20 > Si =E7a fait chier tout le monde, on peut poursuivre cette discussion off= list > ... Non, c'est cool, mais c'est un peu dur =E0 suivre comme ca. [Gab:] > D=E9j=E0, une id=E9e comme =E7a : pourquoi ne pas se retrouver tous les g= ens motiv=E9 > un soir > autour d'une bonne bouffe ? Genre IGDA mais en moins nombriliste, plus > Computer Graphics > (yeah !), et plus conceptuel ? > Donc je lance un appel : qui est sur paris, et qui est motiv=E9 ? Tu dois t'en douter, ca me motive ;) Sanx, |
|
From: <nik...@al...> - 2002-11-29 22:00:11
|
Effectivement, je me suis pas pris la tête pour rechercher ce que tu appelles les "patch" sur la sphere (à quoi bon dans le cas de la sphere ?). Ceci dit, je t'assure qu'il y a des techniques bien avancées pour paramétrer des mesh quelconques (cf. l'article déjà mentionné au 1er mail). Ca devrait répondre à tes besoins, même si bien sûr, je doute que l'implémentation soit aussi simple qu'utiliser les UV du mesh de base (bouh). Pour les ondelettes sur des mesh, j'ai un peu l'impression que tu prends ça comme une mode passagère, je pense que c'est le contraire, c'est vraiment une nouvelle façon de concevoir à la fois les ondelettes / les schémas multiresolutions pour des meshs (on a montrer qu'avec cette technique on pouvait construire toutes les ondelettes "classiques"). Maintenant, c'est sûr que si c'est juste pour faire du mip map, c sans doute sortir le marteau pilon pour écraser une mouche ... Mais essaie de penser à des trucs qui ne se font pas encore dans le jeu vidéo à l'heure actuelle. Typiquement, c'est le genre de techniques qui permetrait de faire de la radiosité temps réel, où de la physique des fluides temps réel ... En tout cas, je poste le lien vers une démo de ma lib de compression de normal mesh sphériques bientot ... Gabriel ----- Original Message ----- From: "Pierre Terdiman" <p.t...@wa...> To: <ori...@li...> Sent: Friday, November 29, 2002 8:21 PM Subject: Re: Geometric signal processing [was : Re: [Orion3d-dev] Displacement Maps] > Déjà, une idée comme ça : pourquoi ne pas se retrouver tous les gens motivé > un soir > autour d'une bonne bouffe ? Genre IGDA mais en moins nombriliste, plus > Computer Graphics > (yeah !), et plus conceptuel ? > Donc je lance un appel : qui est sur paris, et qui est motivé ? Ben moi j'suis à Lyon. Mais je monte à Paris demain :) > En ce qui concerne les displacement mapping, je pense qu'on est sur la même > longueur > d'onde. Oui, en fin de compte oui. >Simplement, je pense avoir nettement moins pratiqué que toi (et > Sanx), Pas forcément.... J'ai pas vraiment pratiqué les ondelettes... (J'ai juste fait des subdivisions surfaces de Loop/Butterfly et de la compression de mesh). > Pour le rapprochement que tu fais entre ondelettes sur un Mesh <--> mipmap, > dans l'idée c'est vraiment ça. Ok... > Disons que tes coeffs en ondelettes (qui représente en qq sorte les détail > du mesh high poly classer > d'une façon hyper ingénieuse) te permettent (en choisissant soit les plus > grands, soit ceux qui sont dans une > zone du mesh que tu privilégie, soit en fonction de la distance, etc.) de > reconstruire le mesh de plus en plus précisément, > selon tes désires. Tu peux peut être voir ça comme de la décompression hyper > adaptative. Les propriétés de localité > des coefficients (grand coef localisés dans les zones de discontinuité) + la > décroissance rapide dans les zones > lisse te permettent de sélectionner les coefs à décompresser de façon > intuitive. Ouais, je crois que je vois bien... > De plus, tout ceci te permet de faire facilement du morphing de mesh (bien > que une fois que tes mesh sont > paramétrisé d'une bonne façon, ce problème devient trivial), du lissage, de > l''enchancing", du débruitage de mesh, etc. J'ai cru voir passer les articles à ce sujet, ouais. "Topological noise removal" ou qqch comme ça. C'est intéressant, c'est clair. L'intérêt dans les jeux, bon.... faut voir..... > Mais il me semble > tu oublies deux choses qui font que les ondelettes est la killer techno pour > la compression (donc le mip map) : Ben j'ai dit que j'étais d'accord sur la compression :) > - Les ondelettes n'encodent pas que le mip map (i.e. des "coarse level" > successifs), à chaque subdivision, on > a les détails + le coarse level (qui est re-subvisié). Donc c'est plus > précis (dans le sens : c'est une transformation > exacte, on peut revenir en arrière). En plus, ça te permet de faire de la > "lossless" décompression/mipmap en n'utilisant > pas de mémoire supplémentaire. Tout-à-fait. >En quelque sorte, c'est mieux que le mip map > classique qui lui, à chaque level va encoder > de l'info redondante (puisque le level n+1 est "contenu" dans le level n). C'est là où ça coince :) "C'est plus précis", oui. Mais à quoi bon ? L'intérêt du mipmap, c'est de choisir la bonne quantité d'information en fonction de l'aire visible du triangle, mettons. A quoi bon avoir de l'information plus précise ou exacte quand ton triangle fait de toute manière 3 * 3 pixels sur l'écran ? C'est exactement ce qui s'est passé pour le LOD.... Quand c'est apparu, on a vu un tas de techniques toutes plus high-tech les unes que les autres se battre en duel pour obtenir les "meilleurs" LODs : du vertex clustering à base d'octree, du progressive mesh normal, évolué genre q-slim, du view-dependent, du view-independent, etc, etc. Et on a finalement vu à la fin (!) que de toute manière les différences d'une méthode à l'autre étaient parfaitement invisibles. Car la règle numéro 1 du LOD, c'est... que ça doit pas se voir ! Si on voit le passage d'un LOD à l'autre, en général c'est que le critère de sélection du LOD est foireux :) Ceci étant dit, est-ce que ce n'est pas la même histoire qui se répète ? Je suis pas sûr qu'on puisse dire, là tout de suite, "c'est mieux que le mipmap".... En théorie, oui, peut-être. Sûrement. En pratique, j'attends de voir... Pas m'en vouloir non plus, mais bon, les subdivision surfaces aussi c'était "the next big thing" quand on en parlait dans l'avion en allant au Devcon2K ! Résultat, uh.... Bref, on verra bien quand tu l'auras fait :) > Je pense que de toute façon, c'est une constatation évidente que pour faire > du mip map sur des normal map, il ne faut pas faire > ça bourin en mipmapant en 2D les maps. Oui, ça c'est vrai - ça marche pas! Vaut mieux éviter le DXTC aussi.......... > De plus, ce type de 'mipmapping" intelligent à pleins d'autres applications. > Par exemple, rien qu'avec ce principe appliqué > sur une sphère, ça permet de faire du cube-mapping de haute qualité (sans > artfact sur les bords, contrairement à ce qui se passe > quand on subsample chaque face du cube), Hmmm, quels artefacts ? Tu confonds pas avec le sphere-mapping ? Le cubemap c'était justement pour virer les singularités du spheremap... > En ce qui concerne les pbm de paramétrisation, je pense que c'est un > problème difficile, :) > En fait, je me suis contenter de résoudre le pbm sur la sphère, ce qui est > plutôt trivial en utilisant une subdivision bourrine à partir d'un octaèdre. Aaaaaah, mais ça change tout.... ok. Je croyais que tu partais d'une sphère.... Mais si le mesh de base est un octaèdre, ça donne direct les "patchs" si pénibles à trouver sur les meshs normaux. Ok.... >C'est pour ça que je parlais de vertex shader, Nope, pixel shaders, c'est pour ça que c'était zarb. Vertex, c'est un peu plus clair, pour calculer des UVs. > Et maintenant, peut être le champ du "geometric signal processing", qu'on > pourrait résumé en "computer graphics analysis (c) 2002 Gabriel Peyré (je > déconnnne)" semble utiliser des outils de représentation des données de plus > en plus moderne, s'inspirant à la fois des représentation hierarchique > (quadtree), des LOD et subdivision, et bien sûr des ondellettes classiques. Ca reste un peu flou pour moi (j'ai pas vraiment expérimenté ce genre de choses), mais okee. "Geometric signal processing", ça rappelle le "signal-specialized parametrization" de Hugues Hoppe .... Bon ben dites moi quand y'a une démo. 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 |
|
From: Pierre T. <p.t...@wa...> - 2002-11-29 19:23:33
|
> D=E9j=E0, une id=E9e comme =E7a : pourquoi ne pas se retrouver tous les= gens motiv=E9 > un soir > autour d'une bonne bouffe ? Genre IGDA mais en moins nombriliste, plus > Computer Graphics > (yeah !), et plus conceptuel ? > Donc je lance un appel : qui est sur paris, et qui est motiv=E9 ? Ben moi j'suis =E0 Lyon. Mais je monte =E0 Paris demain :) > En ce qui concerne les displacement mapping, je pense qu'on est sur la m=EAme > longueur > d'onde. Oui, en fin de compte oui. >Simplement, je pense avoir nettement moins pratiqu=E9 que toi (et > Sanx), Pas forc=E9ment.... J'ai pas vraiment pratiqu=E9 les ondelettes... (J'ai = juste fait des subdivisions surfaces de Loop/Butterfly et de la compression de mesh). > Pour le rapprochement que tu fais entre ondelettes sur un Mesh <--> mipmap, > dans l'id=E9e c'est vraiment =E7a. Ok... > Disons que tes coeffs en ondelettes (qui repr=E9sente en qq sorte les d= =E9tail > du mesh high poly classer > d'une fa=E7on hyper ing=E9nieuse) te permettent (en choisissant soit le= s plus > grands, soit ceux qui sont dans une > zone du mesh que tu privil=E9gie, soit en fonction de la distance, etc.= ) de > reconstruire le mesh de plus en plus pr=E9cis=E9ment, > selon tes d=E9sires. Tu peux peut =EAtre voir =E7a comme de la d=E9comp= ression hyper > adaptative. Les propri=E9t=E9s de localit=E9 > des coefficients (grand coef localis=E9s dans les zones de discontinuit= =E9) + la > d=E9croissance rapide dans les zones > lisse te permettent de s=E9lectionner les coefs =E0 d=E9compresser de f= a=E7on > intuitive. Ouais, je crois que je vois bien... > De plus, tout ceci te permet de faire facilement du morphing de mesh (b= ien > que une fois que tes mesh sont > param=E9tris=E9 d'une bonne fa=E7on, ce probl=E8me devient trivial), du= lissage, de > l''enchancing", du d=E9bruitage de mesh, etc. J'ai cru voir passer les articles =E0 ce sujet, ouais. "Topological noise removal" ou qqch comme =E7a. C'est int=E9ressant, c'est clair. L'int=E9r=EA= t dans les jeux, bon.... faut voir..... > Mais il me semble > tu oublies deux choses qui font que les ondelettes est la killer techno pour > la compression (donc le mip map) : Ben j'ai dit que j'=E9tais d'accord sur la compression :) > - Les ondelettes n'encodent pas que le mip map (i.e. des "coarse level" > successifs), =E0 chaque subdivision, on > a les d=E9tails + le coarse level (qui est re-subvisi=E9). Donc c'est p= lus > pr=E9cis (dans le sens : c'est une transformation > exacte, on peut revenir en arri=E8re). En plus, =E7a te permet de faire= de la > "lossless" d=E9compression/mipmap en n'utilisant > pas de m=E9moire suppl=E9mentaire. Tout-=E0-fait. >En quelque sorte, c'est mieux que le mip map > classique qui lui, =E0 chaque level va encoder > de l'info redondante (puisque le level n+1 est "contenu" dans le level = n). C'est l=E0 o=F9 =E7a coince :) "C'est plus pr=E9cis", oui. Mais =E0 quoi bon ? L'int=E9r=EAt du mipmap, = c'est de choisir la bonne quantit=E9 d'information en fonction de l'aire visible d= u triangle, mettons. A quoi bon avoir de l'information plus pr=E9cise ou ex= acte quand ton triangle fait de toute mani=E8re 3 * 3 pixels sur l'=E9cran ? C'est exactement ce qui s'est pass=E9 pour le LOD.... Quand c'est apparu,= on a vu un tas de techniques toutes plus high-tech les unes que les autres se battre en duel pour obtenir les "meilleurs" LODs : du vertex clustering =E0 base d'octree, du progressive mesh normal, =E9volu=E9 genre q-slim, du view-dependent, du view-independent, etc, etc. Et on a finalement vu =E0 = la fin (!) que de toute mani=E8re les diff=E9rences d'une m=E9thode =E0 l'au= tre =E9taient parfaitement invisibles. Car la r=E8gle num=E9ro 1 du LOD, c'est... que =E7= a doit pas se voir ! Si on voit le passage d'un LOD =E0 l'autre, en g=E9n=E9ral = c'est que le crit=E8re de s=E9lection du LOD est foireux :) Ceci =E9tant dit, est-ce que ce n'est pas la m=EAme histoire qui se r=E9p= =E8te ? Je suis pas s=FBr qu'on puisse dire, l=E0 tout de suite, "c'est mieux que le mipmap".... En th=E9orie, oui, peut-=EAtre. S=FBrement. En pratique, j'at= tends de voir... Pas m'en vouloir non plus, mais bon, les subdivision surfaces aussi c'=E9= tait "the next big thing" quand on en parlait dans l'avion en allant au Devcon= 2K ! R=E9sultat, uh.... Bref, on verra bien quand tu l'auras fait :) > Je pense que de toute fa=E7on, c'est une constatation =E9vidente que po= ur faire > du mip map sur des normal map, il ne faut pas faire > =E7a bourin en mipmapant en 2D les maps. Oui, =E7a c'est vrai - =E7a marche pas! Vaut mieux =E9viter le DXTC aussi.......... > De plus, ce type de 'mipmapping" intelligent =E0 pleins d'autres applications. > Par exemple, rien qu'avec ce principe appliqu=E9 > sur une sph=E8re, =E7a permet de faire du cube-mapping de haute qualit=E9= (sans > artfact sur les bords, contrairement =E0 ce qui se passe > quand on subsample chaque face du cube), Hmmm, quels artefacts ? Tu confonds pas avec le sphere-mapping ? Le cubem= ap c'=E9tait justement pour virer les singularit=E9s du spheremap... > En ce qui concerne les pbm de param=E9trisation, je pense que c'est un > probl=E8me difficile, :) > En fait, je me suis contenter de r=E9soudre le pbm sur la sph=E8re, ce = qui est > plut=F4t trivial en utilisant une subdivision bourrine =E0 partir d'un octa=E8dre. Aaaaaah, mais =E7a change tout.... ok. Je croyais que tu partais d'une sph=E8re.... Mais si le mesh de base est un octa=E8dre, =E7a donne direct= les "patchs" si p=E9nibles =E0 trouver sur les meshs normaux. Ok.... >C'est pour =E7a que je parlais de vertex shader, Nope, pixel shaders, c'est pour =E7a que c'=E9tait zarb. Vertex, c'est un= peu plus clair, pour calculer des UVs. > Et maintenant, peut =EAtre le champ du "geometric signal processing", q= u'on > pourrait r=E9sum=E9 en "computer graphics analysis (c) 2002 Gabriel Pey= r=E9 (je > d=E9connnne)" semble utiliser des outils de repr=E9sentation des donn=E9= es de plus > en plus moderne, s'inspirant =E0 la fois des repr=E9sentation hierarchi= que > (quadtree), des LOD et subdivision, et bien s=FBr des ondellettes classiques. Ca reste un peu flou pour moi (j'ai pas vraiment exp=E9riment=E9 ce genre= de choses), mais okee. "Geometric signal processing", =E7a rappelle le "signal-specialized parametrization" de Hugues Hoppe .... Bon ben dites moi quand y'a une d=E9mo. Pierre |
|
From: <nik...@al...> - 2002-11-29 18:20:49
|
Déjà, une idée comme ça : pourquoi ne pas se retrouver tous les gens motivé un soir autour d'une bonne bouffe ? Genre IGDA mais en moins nombriliste, plus Computer Graphics (yeah !), et plus conceptuel ? Donc je lance un appel : qui est sur paris, et qui est motivé ? En ce qui concerne les displacement mapping, je pense qu'on est sur la même longueur d'onde. Simplement, je pense avoir nettement moins pratiqué que toi (et Sanx), donc je lance parfois des petits Trolls (du genre le coup de la FFT ... fo pas m'en vouloir ;-). Cependant, avant de fournir une réponse définitive sur le sujet (je déconne ...), je vais potasser un peu ce qui se fait à l'heure actuelle sur les normal maps. Pour le rapprochement que tu fais entre ondelettes sur un Mesh <--> mipmap, dans l'idée c'est vraiment ça. Si tu as le courage de lire plus base, je vais essayer de préciser un peu. Disons que tes coeffs en ondelettes (qui représente en qq sorte les détail du mesh high poly classer d'une façon hyper ingénieuse) te permettent (en choisissant soit les plus grands, soit ceux qui sont dans une zone du mesh que tu privilégie, soit en fonction de la distance, etc.) de reconstruire le mesh de plus en plus précisément, selon tes désires. Tu peux peut être voir ça comme de la décompression hyper adaptative. Les propriétés de localité des coefficients (grand coef localisés dans les zones de discontinuité) + la décroissance rapide dans les zones lisse te permettent de sélectionner les coefs à décompresser de façon intuitive. De plus, tout ceci te permet de faire facilement du morphing de mesh (bien que une fois que tes mesh sont paramétrisé d'une bonne façon, ce problème devient trivial), du lissage, de l''enchancing", du débruitage de mesh, etc. Mais il me semble tu oublies deux choses qui font que les ondelettes est la killer techno pour la compression (donc le mip map) : - Les ondelettes n'encodent pas que le mip map (i.e. des "coarse level" successifs), à chaque subdivision, on a les détails + le coarse level (qui est re-subvisié). Donc c'est plus précis (dans le sens : c'est une transformation exacte, on peut revenir en arrière). En plus, ça te permet de faire de la "lossless" décompression/mipmap en n'utilisant pas de mémoire supplémentaire. En quelque sorte, c'est mieux que le mip map classique qui lui, à chaque level va encoder de l'info redondante (puisque le level n+1 est "contenu" dans le level n). - Le partage ne se fait pas par un bête sub-sampling. L'article "Building your own wavelet at home" qui est un tutorial sur le lifting scheme explique ça très bien. C'est un sub sampling hyper raffiné, qui garde les bonnes propriétés du signal (à la fois insiste sur les discontinuité et est rapide là où le mesh/signal est smooth). Et c'est pour ça que je dis qu'avec du sampling type lifting scheme (i.e. ondelettes sur des mesh), tu obtiens une convergence de l'erreur d'approximation de tes mesh successifs excellente, infiniment meilleure qu'avec du mip map "had hoc". Je pense que de toute façon, c'est une constatation évidente que pour faire du mip map sur des normal map, il ne faut pas faire ça bourin en mipmapant en 2D les maps. Il faut bien sûr tenir compte de la topologie du mesh, pour mettre le paquet dans les zones peu lisse. Et bien c'est cette philosophie que le lifting d'ondelette applique de façon automatique. De plus, ce type de 'mipmapping" intelligent à pleins d'autres applications. Par exemple, rien qu'avec ce principe appliqué sur une sphère, ça permet de faire du cube-mapping de haute qualité (sans artfact sur les bords, contrairement à ce qui se passe quand on subsample chaque face du cube), de faire de la compression de BRDF pour la radiosité/raytracing, etc. La seule contrainte est d'avoir une "paramétrisation" de la surface la plus neutre possible (ce qui n'est pas le cas quand tu mip mapes bourinement une normal map). D'où l'idée d'utiliser des subdivisions surface, qui possède une propriété agréable, de générer une grille plutôt régulière (les faces sont bien calibrées, de même aire). En ce qui concerne les pbm de paramétrisation, je pense que c'est un problème difficile, je t'en dirais plus quand j'aurais potasser les articles de shroder et cie... En fait, je me suis contenter de résoudre le pbm sur la sphère, ce qui est plutôt trivial en utilisant une subdivision bourrine à partir d'un octaèdre. Le truc, c'est que si je veux considérer mon mesh comme "paramétrisé" par une subdivision assez précise, je ne dispose pas d'UV explicite. La structure de donnée qui contient la texture ne peut pas être une bête image 2D, mais plutot un arbre (quadtree en général) qui reflète mon schéma. Ca peut paraître bourin, mais en fait, je suis sûr à 100% que c'est pas plus coûteux en place mémoire. Par exemple, à précision égale, il faut, dans le cas de la sphère subdivisée, un point pour chaque pôle, alors qu'avec une texture cylindrique, des milliards de pixels se voient projetés sur le même pôle. Ensuite, il vient le problème du processing de toute cette info, et c'est clair que pour l'instant, manipuler des quadtree, ça doit être bof pour les perf dans un jeu. C'est pour ça que je parlais de vertex shader, pour créer un moteur de rendu qui utiliserait cette techno de "mipmap" issue d'une paramétrisation de subdivision, mais qui process ça rapidement. Ok, je suis en pleins délire, mais bientôt, le GPU pourra décoder des MP3 de britney spears, donc je garde espoir ... Bien sûr, inutile d'espere processer autant de vertex/pixels que si on utilisait des array float[N][N], mais d'un côté, le fait que les mip maps soient mieux "pensées" peut peut être faire gagner un ordre de grandeur dans le nombre de données à traiter. Disons que je pense que ça serait une évolution logique. D'abord, il y a eu le traitement du signal qui s'est posé le premier la question "Comment représenté de façon efficace mes données pour les traiter en O(Nlog(N)) voir en O(N)". Les ondelettes et les bancs de filtres on donnés une bonne réponse pour les images 2D simples. Ensuite, il y a eu le monde des EDP, par exemple pour la résolution de la radiosité, qui a bénéficier des bases d'ondelettes pour résoudre rapidement les équations. Et maintenant, peut être le champ du "geometric signal processing", qu'on pourrait résumé en "computer graphics analysis (c) 2002 Gabriel Peyré (je déconnnne)" semble utiliser des outils de représentation des données de plus en plus moderne, s'inspirant à la fois des représentation hierarchique (quadtree), des LOD et subdivision, et bien sûr des ondellettes classiques. Gabriel Gabriel ----- Original Message ----- From: "Pierre Terdiman" <p.t...@wa...> To: <ori...@li...> Sent: Friday, November 29, 2002 6:02 PM Subject: Re: [Orion3d-dev] Displacement Maps > 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. Ok, ok, si c'est juste pour compresser une map, ça me parle. Ca ferait un peu comme du mipmap qui ne dépendrait pas de la distance, mais des irrégularités de la texture, non ? (ex: si y'a un bloc de 64*64 pixels unicolore dans une texture 256*256, y'a pas besoin de se trimballer tous les mipmaps pour cette partie là, on peut directement utiliser le dernier 1*1 - en théorie)(c'est peut-être pas très clair :) > A priori, tout le monde est d'accord que le bon moyen d'encoder ces détails, > c'est une displacement map. ...Ah, bon, ça a quand même un peu un rapport finalement :) > 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). Attends, si on parle de paramétrisation de mesh, je suis bien d'accord ! Les UVs explicites, pas bien (mais facile à faire, et donc en pratique, c'est ce qu'on utilise). Bruno Levy et les conformal maps, yeaaah, top, nickel. Mais quel rapport avec les ondelettes ? (confused) > > 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. Jusque là, 100% ok. > Et un algorithme > de subdivision fournit -grosso modo- une telle paramétrisation (puisque > toutes les faces ont environ la même aire). Mais alors là, je vois pas. Tu as une sphère, tu veux une paramétrisation implicite parfaite, en quoi subdiviser la sphère va aider ? Sans déconner ça m'intéresse, hein. J'ai du me taper un normal mapper genre ATI pour une boîte de jeux récemment, et on a fini par utiliser des UVs explicites parce que générer la version implicite c'était top chiant (et ça marchait pas, pas le temps). > 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). ...ben je vois pas trop le lien entre le paragraphe précédent et les pixel shaders, mais bon... :) 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 |
|
From: Pierre T. <p.t...@wa...> - 2002-11-29 17:05:34
|
> Tu pourrais d=E9crire un peu en d=E9tail de tool d'ATI ? > Je suis un peu fl=E9mard, peut =EAtre j'irais regarder ... (Sinon y'a aussi PolyBump de Crytek, et Magica, le tool d'Ignacio Castano= ). Pierre |
|
From: Pierre T. <p.t...@wa...> - 2002-11-29 17:03:48
|
> Pierre, ce que je veux compresser avec cet algo, c'est la displacement map, > dans le but d'optimiser le nombre de polys utilis=E9s pour g=E9n=E9rer = un mesh > aussi pr=E9cis, > ou alors des textures de bump aussi pr=E9cises mais moins volumineuses. Ok, ok, si c'est juste pour compresser une map, =E7a me parle. Ca ferait = un peu comme du mipmap qui ne d=E9pendrait pas de la distance, mais des irr=E9gularit=E9s de la texture, non ? (ex: si y'a un bloc de 64*64 pixel= s unicolore dans une texture 256*256, y'a pas besoin de se trimballer tous = les mipmaps pour cette partie l=E0, on peut directement utiliser le dernier 1= *1 - en th=E9orie)(c'est peut-=EAtre pas tr=E8s clair :) > A priori, tout le monde est d'accord que le bon moyen d'encoder ces d=E9tails, > c'est une displacement map. ...Ah, bon, =E7a a quand m=EAme un peu un rapport finalement :) > Ce que je veux dire, c'est que le nurbs ne peut pas servir de *bonne* > param=E9trisation pour une displacement map. Tout comme le fait d'utili= ser > bettement les coordonn=E9es UV > du mesh d'origine (m=EAme si c'est ce qu'on fait =E0 l'heure actuel, da= ns doom3 > et cie, je vous assure qu'il y a moyen > de d=E9finir des m=E9thodes qui s'optimisent mieux). Attends, si on parle de param=E9trisation de mesh, je suis bien d'accord = ! Les UVs explicites, pas bien (mais facile =E0 faire, et donc en pratique, c'e= st ce qu'on utilise). Bruno Levy et les conformal maps, yeaaah, top, nickel. Ma= is quel rapport avec les ondelettes ? (confused) > > R=E9fl=E9chisser =E0 ceci : vous voulez d=E9finir une displacement map = sur une > sphere > (par exemple une ampoule dans Doom3 ... ;). Pour =E7a, votre graphiste > vous g=E9n=E8re une map cylindrique, et vous la plaquer bettement sur l= a sphere, > avec du bump ou > bien des vetrex shader. Vous ne pensez pas qu'on peut faire mieux ?? En= tre > autre, il est =E9vident 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=E8s > r=E9gulier et optimiser sur *toute* la sphere > (et pas seulement sur l'=E9quateur), il faut disposer d'une param=E9tri= sation > *intrinseque* de la sphere. Jusque l=E0, 100% ok. > Et un algorithme > de subdivision fournit -grosso modo- une telle param=E9trisation (puisq= ue > toutes les faces ont environ la m=EAme aire). Mais alors l=E0, je vois pas. Tu as une sph=E8re, tu veux une param=E9tri= sation implicite parfaite, en quoi subdiviser la sph=E8re va aider ? Sans d=E9co= nner =E7a m'int=E9resse, hein. J'ai du me taper un normal mapper genre ATI pour une bo=EEte de jeux r=E9cemment, et on a fini par utiliser des UVs explicites= parce que g=E9n=E9rer la version implicite c'=E9tait top chiant (et =E7a marcha= it pas, pas le temps). > Perso, je pense que ce genre de pbm est tr=E8s int=E9ressant, et je sui= s sur > qu'avec des pixel shader, il y a moyen de faire > du code hautement optimis=E9, tout aussi rapide que le bump ou tout aut= re > chose utilis=E9 dans Q3, mais avec un rendu des d=E9tails > 10x plus fin (un gain =E9norme en terme de distortion par rapport au me= sh > ultime rendu sous 3DS). ...ben je vois pas trop le lien entre le paragraphe pr=E9c=E9dent et les = pixel shaders, mais bon... :) Pierre |
|
From: Pierre T. <p.t...@wa...> - 2002-11-29 16:49:39
|
> Je me permet de remarquer que tu sous estime nettement les papier =E9cr= it au > calltech > (entre autre). C'est que je me suis mal exprim=E9, alors. Au contraire, je trouve qu'ils= vont bien au-del=E0 de ce dont on a besoin =E0 l'heure actuelle dans les jeux (puisque c'=E9tait le but initial). > Ca n'a vraiment rien a voir avec du displacement mapping, Beuh.... pour le coder na=EFf que je suis, les normal meshs c'est quand m= =EAme bien imit=E9 :) > enfin, c'est > vraiment le cran au dessus, que ce soit au niveau > des performance, et aussi et surtout de la pr=E9cision 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). Ben explique ! Je comprends pas, sorry. Notamment : - pour les perfs, je vois mal comment =E7a peut =EAtre "un cran au dessus= " du displacement mapping, cabl=E9 en hard. Ou alors on parle pas des m=EAmes = perfs (?). - je ne vois pas d'o=F9 viennent les d=E9tails dans cette histoire ! Tu p= eux jouer des mois avec des subdivision surfaces et des ondelettes, c'est pas= =E7a qui va g=E9n=E9rer le d=E9tail (ou alors j'ai loup=E9 un =E9pisode, ce qu= i est possible...) Certes, tu vas pouvoir les r=E9pr=E9senter avec, mais l=E0 e= ncore =E7a rejoint la description de l'information / compression de donn=E9es - auqu= el cas on est d'accord, comme j'disais. > C'est comme dire que la th=E9orie du filtrage s'est arr=E9t=E9 le jour = o=F9 l'on a > d=E9couvert la FFT ... (shrug) J'ai pas dit =E7a. J'ai juste dit que l'int=E9r=EAt pratique de la chose me semblait bof-bof= pour les jeux (mais je ne demande qu'=E0 =EAtre convaincu). Pierre |
|
From: <nik...@al...> - 2002-11-29 16:36:12
|
Tu pourrais décrire un peu en détail de tool d'ATI ? Je suis un peu flémard, peut être j'irais regarder ... Ca pourait donner des idées, genre j'aimerais trouver un bon framework pour générer des displacements map, mais le reprendre en codant les coordonnées par subdivision, et voir si on obtient le même rendu. Ensuite, si ça marche, ça pourrait être un tremplin pour intégrer mon moteur de compression de mesh, et hop, en ajoutant un pipeline de rendu à l'aide de vertex/pixel shader, ça peut faire un moteur de rendu de mesh bumpé bien sympa :) Si ça fait chier tout le monde, on peut poursuivre cette discussion offlist ... Gabriel ----- Original Message ----- From: "Laurent Mascherpa" <lau...@fx...> To: <ori...@li...> Sent: Friday, November 29, 2002 5:27 PM Subject: Re: Subdivision surfaces [was Re: [Orion3d-dev] Pour infos] > >Effectivement, mais à quel prix, les graphistes font du super high-poly, > >pour finir par simplifier. A mon avis les level mappers doivent encore > >s'arracher les cheveux, à mois que l'éditeur fasse tout sans détail, > >et génère les détails suivant beaucoup des règles lors de la > >compilation (matériaux, lumières, etc.). > > > >Bref je sais pas comment il fait, ca doit prendre un temps fou de > >faire des niveau Doom3, si t'as des infos là dessus. > > Pas des masses, non. > > Le procédé est "vieux" et utilisé dans d'autres prods que Doom3, ceci dit. > Le coup des deux meshs et du normal shooting (traduc ?) vient justement des > displaced subdivision surfaces (2000), mais dans mes souvenirs le premier > article qui en parle date de 95. > > En théorie, y'a pas vraiment à mapper quoi que ce soit : les UVs du mesh > low-poly sont générés, et le mesh high poly n'est pas texturé ! C'est > carrément des vertex colors, capturées elles aussi par le shooting. En > pratique, y'a des variantes par rapport à la théorie, c'est clair (notamment > dans les tools d'ATI et/ou Polybump, le mesh low poly doit être paramétrisé > à la main si je me souviens bien). J'utilise le tool de shooting d'ATI (qui ne prend pas les couleurs) dans mon moteur. Le problème est que les graphistes ne peuvent pas faire des scènes immenses en High-poly, car on monte très rapidement à beaucoup, et c'est pas possible de travailler autant dans le détail sur autant de données qu'il y a pour faire un niveau de doom 3, j'imaginait qu'il avait un truc, genre pas faire de détail, et généré le détail (mais je rêve, pauvres graphistes ;). > Je crois me souvenir que pour D3 ils génèrent 5 maps comme ça. (Une normal > map, une diffuse, une specular, une gloss, et une autre qui m'échappe > j'avoue! Lightmap peut-être.). Mais j'ai pas vu la trace de tout ça dans la > démo leakée (pardon, la démonstration-qui-fuit, héhé). Peut-être juste des > rumeurs... Héhé, ouais, effectivement il grille un bon paquet de TextureStages, il me semble 7 en fait. Doit y avoir une "normalisation map" dans l'histoire, si je me trompe pas dans le terme. C'est passé sur la DXML il y a un moment. Sanx, ------------------------------------------------------- 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 |
|
From: <nik...@al...> - 2002-11-29 16:30:27
|
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 |
|
From: Laurent M. <lau...@fx...> - 2002-11-29 16:27:30
|
> >Effectivement, mais =E0 quel prix, les graphistes font du super high-pol= y, > >pour finir par simplifier. A mon avis les level mappers doivent encore > >s'arracher les cheveux, =E0 mois que l'=E9diteur fasse tout sans d=E9tai= l, > >et g=E9n=E8re les d=E9tails suivant beaucoup des r=E8gles lors de la > >compilation (mat=E9riaux, lumi=E8res, etc.). > > > >Bref je sais pas comment il fait, ca doit prendre un temps fou de > >faire des niveau Doom3, si t'as des infos l=E0 dessus. >=20 > Pas des masses, non. >=20 > Le proc=E9d=E9 est "vieux" et utilis=E9 dans d'autres prods que Doom3, ce= ci dit. > Le coup des deux meshs et du normal shooting (traduc ?) vient justement d= es > displaced subdivision surfaces (2000), mais dans mes souvenirs le premier > article qui en parle date de 95. >=20 > En th=E9orie, y'a pas vraiment =E0 mapper quoi que ce soit : les UVs du m= esh > low-poly sont g=E9n=E9r=E9s, et le mesh high poly n'est pas textur=E9 ! C= 'est > carr=E9ment des vertex colors, captur=E9es elles aussi par le shooting. E= n > pratique, y'a des variantes par rapport =E0 la th=E9orie, c'est clair (no= tamment > dans les tools d'ATI et/ou Polybump, le mesh low poly doit =EAtre param= =E9tris=E9 > =E0 la main si je me souviens bien). J'utilise le tool de shooting d'ATI (qui ne prend pas les couleurs) dans mon moteur. Le probl=E8me est que les graphistes ne peuvent pas faire des sc=E8nes immenses en High-poly, car on monte tr=E8s rapidement = =E0 beaucoup, et c'est pas possible de travailler autant dans le d=E9tail sur autant de donn=E9es qu'il y a pour faire un niveau de doom 3, j'imaginait qu'il avait un truc, genre pas faire de d=E9tail, et g=E9n=E9r= =E9 le d=E9tail (mais je r=EAve, pauvres graphistes ;). > Je crois me souvenir que pour D3 ils g=E9n=E8rent 5 maps comme =E7a. (Une= normal > map, une diffuse, une specular, une gloss, et une autre qui m'=E9chappe > j'avoue! Lightmap peut-=EAtre.). Mais j'ai pas vu la trace de tout =E7a d= ans la > d=E9mo leak=E9e (pardon, la d=E9monstration-qui-fuit, h=E9h=E9). Peut-=EA= tre juste des > rumeurs... H=E9h=E9, ouais, effectivement il grille un bon paquet de TextureStages, il me semble 7 en fait. Doit y avoir une "normalisation map" dans l'histoire, si je me trompe pas dans le terme. C'est pass=E9 sur la DXML il y a un moment. Sanx, |
|
From: <nik...@al...> - 2002-11-29 16:16:20
|
Cool, va faloir envoyer les propositions au Larousse, héhé ;) Gabriel ----- Original Message ----- From: "Pierre Terdiman" <p.t...@wa...> To: <ori...@li...> Sent: Friday, November 29, 2002 2:43 PM Subject: Re: Subdivision surfaces [was Re: [Orion3d-dev] Pour infos] >Ca se voit, 80% des termes techniques sont en anglais ;) :) Voyons voir : - "surfaces subdivisées déplacées" (displaced subdivision surfaces) - "carte de normales" (normal maps) - "images géométriques" (?) (geometry images) - "filtrage trilinéaire" (trilinear filtering) - "douceur" (argh!) (smoothness) - "maillages progressifs" (?) (progressive meshes) - (j'essaie même pas) (NURBS) ....bon ben on va rester en anglais hein! :) >Effectivement, mais à quel prix, les graphistes font du super high-poly, >pour finir par simplifier. A mon avis les level mappers doivent encore >s'arracher les cheveux, à mois que l'éditeur fasse tout sans détail, >et génère les détails suivant beaucoup des règles lors de la >compilation (matériaux, lumières, etc.). > >Bref je sais pas comment il fait, ca doit prendre un temps fou de >faire des niveau Doom3, si t'as des infos là dessus. Pas des masses, non. Le procédé est "vieux" et utilisé dans d'autres prods que Doom3, ceci dit. Le coup des deux meshs et du normal shooting (traduc ?) vient justement des displaced subdivision surfaces (2000), mais dans mes souvenirs le premier article qui en parle date de 95. En théorie, y'a pas vraiment à mapper quoi que ce soit : les UVs du mesh low-poly sont générés, et le mesh high poly n'est pas texturé ! C'est carrément des vertex colors, capturées elles aussi par le shooting. En pratique, y'a des variantes par rapport à la théorie, c'est clair (notamment dans les tools d'ATI et/ou Polybump, le mesh low poly doit être paramétrisé à la main si je me souviens bien). Je crois me souvenir que pour D3 ils génèrent 5 maps comme ça. (Une normal map, une diffuse, une specular, une gloss, et une autre qui m'échappe j'avoue! Lightmap peut-être.). Mais j'ai pas vu la trace de tout ça dans la démo leakée (pardon, la démonstration-qui-fuit, héhé). Peut-être juste des rumeurs... 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 |
790 messages has been excluded from this view by a project administrator.