home *** CD-ROM | disk | FTP | other *** search
/ Supremacy 1 / Supremacy-1.iso / DEMOS / S-T / TOXIC12.ZIP / PROGRAMS / ALGORITH.MES / ALGORITH.ZIP / 96_05_04.MIN < prev   
Encoding:
Text File  |  1996-05-03  |  7.6 KB  |  55 lines
  1. SV:sH③H④ B_②gT GOMessageL ⑧@du O2/O5/96 ⑨Aa 21:OODAMDS de ⑧SYNTAX pour ALGORITHMESEAB`②gGR⑨Bef:]E.T\ (3O/O4 ⑨Aa 22:3O)
  2. Hi! comme dit crac le fait que ce soit
  3. incline ne change pas grd chose.en effetune correction de 4,8 meme 16 pixels ne
  4. se remarque presque pas.
  5. maintenant libre a toi de corriger tous
  6. les pixels,mais la va falloir envisager
  7. la station silicon graphics...
  9. ps:euh,mon truc marche mais le clip pose des ptits probs...ben oui pour l'ins-
  10.  tant c 1 clip lineaire donc pas exact
  11.  sur l'interpolation des z...rh③Haa on
  12.  s'en sortira pas...VAB`②gT @AvancerGZ ] Suite  \Y @Son r⑨BepondeurGZ ] Envoi \Y T @RevenirG ③H] Retour \ ⑧@IntervenirG ]③HN#L     Envoi \ ♪♪♪①④ B_②gT GOMessageL ⑧@du O2/O5/96 ⑨Aa OO:O5DAMDS de ⑧CRACounet pour ALGORITHMESEAB`②gGR⑨Bef:]E.T\ (3O/O4 ⑨Aa 22:3O)
  14. Non, le pb ne vient pas du fait que la face est tr⑨Aes inclin⑨Bee, mais qu'elle est tr⑨Aes proche de l'utilisateur.
  15. Point de vue math⑨Bematique: tu pars de la fonction inverse (1/x). f(x)=1/x si a et b sont petits, tu trouveras une grande difference entre la droite qui va de (a,f(a)) ⑨Aa (b,f(b)) et la courbe entre a et b. Plus x est petit et moins la fonction inverse a tendance a se comporter comme une droite.
  16. Donc, le pb de "beaut⑨Be" du rendu reste toujours ⑨Aa fixer une ⑨Bech⑨Beance de recalcul en nb de lignes deja trac⑨Bees de la faceVAB`②gT @AvancerGZ ] Suite  \Y @Son r⑨BepondeurGZ ] Envoi \Y T @RevenirG ] Retour \ ⑧@IntervenirG ]N#L     Envoi \ ♪♪♪①④ B_②gT GOMessageL ⑧@du O1/O5/96 ⑨Aa 13:16DAMDS de ⑧Geek pour ALGORITHMESEAB`②gGR⑨Bef:]E.T\ (3O/O4 ⑨Aa 22:3O)
  18. tiens c pas con ca... enfin ca ferait unprod scalaire par face non ?VAB`②gT @AvancerGZ ] Suite  \Y @Son r⑨BepondeurGZ ] Envoi \Y T @RevenirG ] Retour \ ⑧@IntervenirG ]N#L     Envoi \ ♪♪♪①④ B_②gT GOMessageL ⑧@du 3O/O4/96 ⑨Aa 22:3ODAMDS de ⑧E.T pour ALGORITHMESEAB`②gGR⑨Bef:]syntax\ (28/O4 ⑨Aa 22:41)
  20. corriger tous les 4,8 ou 16 pixels c'estbien, mais ne serait il pas plus logiquede corriger plus souvent lorsque la faceest tres inclinee???VAB`②gT @AvancerGZ ] Suite  \Y @Son r⑨Bepondeu③HrGZ ] Envoi \Y T @RevenirG ] Retour \ ⑧@IntervenirG ]N#L     Envoi \ ♪♪♪①④ B_②gT GOMessageL ⑧@du 28/O4/96 ⑨Aa 22:41DAMDS de ⑧syntax pour ALGORITHMESEAB`②gGR⑨Bef:]LCa\ (23/O4 ⑨Aa 23:16)
  21. Hi! pour le mapping corrige j'ai cogite 1 certain tps et je crois ke j'ai trou-
  22. ve qqchose:
  23. on calcule notre pas sur une scanline non pas par rapport au poly mais par rap-
  24. port a la texture.On a donc 1 pas lineaire seulement ds le cas d'un poly de z 
  25. constant (jusque la j'me goure pas)
  26. et ben ensuite au niveau de l'interpola-tion on realise une inverse projection
  27. du pas pour l'increment x et y et hop!
  28. ca marche.DONC,pour 1 correction pour chaque pixel,ca fait 2 mul par pt.Pas mal
  29. je pense.On fait la meme c③Hhose sur les
  30. bords du poly donc 4 mul/scan en +.a+VAB`②gT @AvancerGZ ] Suite  \Y @Son r⑨BepondeurGZ ] Envoi \Y T @RevenirG ] Retour \ ⑧@IntervenirG ]N#L     Envoi \ ♪♪♪①④ B_②gT GOMessageL ⑧@du 28/O4/96 ⑨Aa 19:29DAMDS de ⑧Geek pour ALGORITHMESEAB`②gGR⑨Bef:]tiefighter\ (26/O4 ⑨Aa 23:13)
  32. le mapping ki suit la perspective suit des lignes de z constant, donc on fait une interpolation lineaire.ms comme tu le dis, ya de fortes ch③Hances d'avoir des trous ds ton polys.de + tu peux pas ecrire de words ds ton buffer , tu peux calculer ke ds bytes.ca risque de ramer...!!!
  34. pour le mapping corrige lca a dit qu'on corrigeait l increment ts les 4,8,16 pix(selon degre de precision).il suffit (je PENSE) d'interpoler u/z,v/z,1/z lineaires le long du polys et de faire (u/z)/(1/z) pour trouver u.mem chose pr v.../..VAB`②gT @AvancerGZ ] Suite  \Y @Son r⑨BepondeurGZ ] Envoi \Y T @RevenirG ] Retour \ ⑧@IntervenirG ]N#L     Envoi \ ♪♪♪①④ B_②gT GOMessageL ⑧@du 28/O4/96 ⑨Aa 19:33DAMDS de ⑧Geek pour ALGORITHMESEAB`②gGdonc on a les u et v corrects ts les n pixels... on a plus qu a interpoler lineairement entre chaque doublet de 2 pixelsen recalculant le delta_u et le delta_v ts les n pix.comme on corrige avec n puissance de 2, y suffit de faire u1-u2 shr 4 par ex.
  36. voila , je crois ke ca marche(pas encore essaye now ;) ), mais pour trouver u e③Htv a chaque cote du p③Holy , ca me ferait  2 divs!ca me semble SLOW...
  38. sinon y parait que quake precalcule ses effets de lumiere... de + ya pas d'ombres... into ze shadows ruleZ!VAB`②gT @AvancerGZ ] Suite  \Y @Son r⑨BepondeurGZ ] Envoi \Y T @RevenirG ] Retour \ ⑧@IntervenirG ]N#L     Envoi \ ♪♪♪①④ B_②gT GOMessageL ⑧@du 26/O4/96 ⑨Aa 23:13DAMDS de ⑧tiefighter pour ALGORITHMESEAB`②gGR⑨Bef:]LCa\ (23/O4 ⑨Aa 23:12)
  39.    J'ai lu dans pcgpe, une autre facon pour faire du mapping adapte a la perspective, il s agissait de remplir le polygone non pas suivant des horizontal, mais suivant les droites Z constantes .. (cela permet d'interpoler lineairement), 
  40. quelqu un a t il deja tente et cela vautt il le cout ? 
  41.  Certes cela pose certains pb (trous..) mais il y a egalement des avantages pex pour le Z_buffer ca devient tres simple. Sinon comment fait t on une correction lorsqu on intrpole lineairement horizontalement ... j ai un peu de mal a voir ..VAB`②gT @AvancerGZ ] Suite  \Y @Son r⑨BepondeurGZ ] Envoi \Y T @RevenirG ] Retour \ ⑧@IntervenirG ]N#L     Envoi \ ♪♪♪①④@AQ ⑧`]NGRLCTFEBLG\⑨.@Contact:GRICK
  42. @]⑧]N*L    Envoi
  43. ①④ B_②gT GOMessageL ⑧@du 23/O4/96 ⑨Aa 23:12DAMDS de ⑧LCa pour ALGORITHMESEAB`②gGR⑨Bef:]Geek\ (16/O4 ⑨Aa 18:22)
  44. ben si tu codes en mode 32 bits, faut JAMAIS utiliser les reg 16 bits; sinon, ca depend des besoins pour ma precision. par exemple, pour le mapping perspetive corrected, 8 bits de virgule suffisent puisqu'on recalcule l'increment tous les 16 pix. pou le reste, c'est en 16 bits de virgules, sauf quand il y a trop d'interpolant et donc pas assez de registres...
  45. sinon, si je peux oser(et j'ose), vos mapping sont degueulasses: en undersamplingles segments ne sont pas reguliers. Je dis ca, car dans toutes les demos, dans tous les jeux (sauf quake, duke 3d et VAB`②gT @AvancerGZ ] Suite  \Y @Son r⑨BepondeurGZ ] Envoi \Y T @RevenirG ] Retour \ ⑧@IntervenirG ]N#L     Envoi \ ♪♪♪①④ B_②gT GOMessageL ⑧@du 23/O4/96 ⑨Aa 23:16DAMDS de ⑧LCa pour ALGORITHMESEAB`②gGceux auxquels je participe) ont des irregularites sur les segments. C'est par exemple dans le cas ou un meme texel forme un carre a l'ecran; et bien son contourest irregulier, et c'est moche.
  47. je ne dis pas ca gratuitement, mais juste pour vous faire prendre conscience que la vitesse est une chose, mais il faut aussi penser a l'aspect esthetique, car c'est ca que l'utilisateur voit...
  48. lCaVAB`②gT @AvancerGZ ] Suite  \Y @Son r⑨BepondeurGZ ] Envoi \Y T @RevenirG ] Retour \ ⑧@IntervenirG ]N#L     Envoi \ ♪♪♪①④ B_②gT GOMessageL ⑧@du 23/O4/96 ⑨Aa 23:OODAMDS de ⑧LCa pour ALGORITHMESEAB`②gGR⑨Bef:]CRACounet\ (21/O4 ⑨Aa 9:O5)
  49. j'avoue n'avoir rien compris a ce que tu proposes...
  50. a ton avis, si (u,v)sont tes coord. dans la texture d'un point, dans l'espace, est-ce que (u,v) est lineaire sur l'ecran?
  55. reponse....VAB`②gT @AvancerGZ ] Suite  \Y @Son r⑨BepondeurGZ ] Envoi \Y T @RevenirG ] Retour \ ⑧@IntervenirG ]N#L     Envoi \ ♪♪♪①④ B_②gT GOMessageL ⑧@du 23/O4/96 ⑨Aa 23:O1DAMDS de ⑧LCa pour ALGORITHMESEAB`②gG(x,y) ne sont pas lineaires sur l'ecran, car Xecran est en 1/z et YEcran est aussi en 1/z; il en est dede