🚀 go-pugleaf

> Poszukuje stronek z ladnymi opisami cieniowania gourauda (najchetniej z
> jakimis dzialajacymi kodami), z-bufora, itd. Najchetniej nie strony w 
> stylu
> np:OpenGL, bo niestety nie moge korzystac z takich dobrodziejstw i musze
> wszystko robic w software.
> Z gory dziekuje za wszelka pomoc
>
> ps Zostalem tu odeslany wiec mam nadzieje ze ktos mi pomoze:)

no przeciez oba algorytmy sa banalne,
ale poszukaj na starym archiwum horneta [wpisz w googlach hornet archive]
tam bylo do tego mnóstwo srckow (w pascalu, c i asmie - do wyboru, do 
koloru)

-- 
mx 

Ktos napisał(a):
> Poszukuje stronek z ladnymi opisami cieniowania gourauda (najchetniej z
> jakimis dzialajacymi kodami), z-bufora, itd. Najchetniej nie strony w stylu
> np:OpenGL, bo niestety nie moge korzystac z takich dobrodziejstw i musze
> wszystko robic w software.

Tak sobie pomyślałem że kiedyś chodziły między ludźmi texty Toma 
Hammersleya w których opisywał różne efekty.  Wrzuciłem w gógla no i 
proszę, to jeszcze leży w sieci:

http://tfpsly.planet-d.net/Docs/TomHammersley/

-- 
Jaytee

* It's 5:50am. do you know where your stack pointer is?

Ktos wrote:

> Poszukuje stronek z ladnymi opisami cieniowania gourauda (najchetniej z
> jakimis dzialajacymi kodami), z-bufora, itd. Najchetniej nie strony w  
> stylu
> np:OpenGL, bo niestety nie moge korzystac z takich dobrodziejstw i musze
> wszystko robic w software.

Alez prosze:
http://www.devmaster.net/articles.php

Caly dzial Software Rendering, a zwlaszcza "Part IV: Shading and Filling".  
O z-buforze jest "How ZBuffering Works".

-- 
_red ____ _ ____ ____ __ _

garath@ARWFDSSDAEFWwp.pl news:cti9ik$15h$1@inews.gazeta.pl

> np:OpenGL, bo niestety nie moge korzystac z takich dobrodziejstw i musze
> wszystko robic w software.

Kod zrodlowy allegro.cc 

-- 
~~~~=~~~~l_;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   _|\___J  \____,  Pozdrawiam, moje www, C++, kontakt, itd.:
X-(     ssn256    ) Rafal Maj Raf256 - http://www.raf256.com/me-news/
  ,"-------------"  (strona w budowie)

cieniowanie gourauda to syf!!
nie powinienes sie tego uczyc bo ci to tylko wypaczy charakter.
cieniowanie gourauda nie nadaje sie w zasadzie do niczego,
a w szczegolnosci do z-bufora.
ile to razy slyszalem 'zrobilem z-bufor i jak mi sie 2 obiekty przecinaja
to zamiast prostej linii przeciecia mam postrzepione jak cholera'

nalezy zapomniec o tym algorytmie a wszystkie ksiazki spalic
nie jest ani szybki, ani dokladny.
a juz wogole sie nie nadaje przy 3d.

> cieniowanie gourauda to syf!!
> nie powinienes sie tego uczyc bo ci to tylko wypaczy charakter.
> cieniowanie gourauda nie nadaje sie w zasadzie do niczego,
> a w szczegolnosci do z-bufora.
> ile to razy slyszalem 'zrobilem z-bufor i jak mi sie 2 obiekty przecinaja
> to zamiast prostej linii przeciecia mam postrzepione jak cholera'
>
> nalezy zapomniec o tym algorytmie a wszystkie ksiazki spalic
> nie jest ani szybki, ani dokladny.
> a juz wogole sie nie nadaje przy 3d.

z checia sie zgodze, ale projekt i tak musze zrobic, wiec nie mam wyjscia. 

Biki co paliles ? :> Powiedz to tez sobie pociagne :] ...

Pozdr.
   st3tc

nic nie palilem (jesli nie liczyc czarownic)

biki, dobry zart...



-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

biki@viper.pl news:95EF65BA7bikikillerradomnet@193.110.122.97

> ile to razy slyszalem 'zrobilem z-bufor i jak mi sie 2 obiekty przecinaja
> to zamiast prostej linii przeciecia mam postrzepione jak cholera'

Precyzja obliczen

-- 
~~~~=~~~~l_;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   _|\___J  \____,  Pozdrawiam, moje www, C++, kontakt, itd.:
X-(     ssn256    ) Rafal Maj Raf256 - http://www.raf256.com/me-news/
  ,"-------------"  (strona w budowie)

>Precyzja obliczen
no wlasnie ze NIE
wtedy bylo by to zbyt proste
po prostu cieniowanie gourauda jest niepoprawne

biki wrote:

> po prostu cieniowanie gourauda jest niepoprawne

wporzo, tylko co w zamian? phong i 2 fps na nowym dziforsie? :)

-- 
_red ____ _ ____ ____ __ _

nie. w zamian uczciwa interpolacja liniowa.

biki wrote:

> nie. w zamian uczciwa interpolacja liniowa.

a gouard to niby co jest?

-- 
_red ____ _ ____ ____ __ _

>a gouard to niby co jest?

a gouraud to jest chujoza ktora interpoluje po krawedziach wielokata a 
potem po poziomych segmentach, nie liczac sie zupelnie ze liczone wartosci 
sa zupelnie w innym miejscu niz powinny.
teoretycznie mozna przerobic gourauda tak zeby byl poprawny ale wtedy 
bedzie kosztowal 3x tyle co zwykla liniowa interpolacja.

biki wrote:

> a gouraud to jest chujoza ktora interpoluje po krawedziach wielokata a
> potem po poziomych segmentach, nie liczac sie zupelnie ze liczone  
> wartosci sa zupelnie w innym miejscu niz powinny.

no wlasnie na tym ma polegac gouraud :) nie daje idealnych rezultatow, ale  
nie nadaje sie tez do oswietlania duzych jednolitych powierzchni - tam sie  
zarzuca lightmapy. no i gouraud to jest interpolacja liniowa :)

> teoretycznie mozna przerobic gourauda tak zeby byl poprawny ale wtedy
> bedzie kosztowal 3x tyle co zwykla liniowa interpolacja.

a jaka ty masz wizje oswietlenia? co to jest ta zwykla liniowa  
interpolacja?

-- 
_red ____ _ ____ ____ __ _

jesli nie wiesz czym sie rozni interpolacja gourauda od liniowej to ja cie 
uczyc nie bede , sprobuj google.

biki wrote:

> jesli nie wiesz czym sie rozni interpolacja gourauda od liniowej to ja  
> cie uczyc nie bede , sprobuj google.

byćże bardziej precyzyjny. może dwuliniowa na całej powierzchni? bo  
liniowa to jest w 1d.

-- 
_red ____ _ ____ ____ __ _

liniowa to liniowa. w tym konkretnym przypadku
v=A*x+B*y+C

biki wrote:

> liniowa to liniowa. w tym konkretnym przypadku
> v=A*x+B*y+C

No to nie liniowa tylko afiniczna de facto...

Ale nieważne, biki, powiedz, bo i ja chyba jestem jakiś słaby na umyśle...
Czym to się różni [poza precyzją obliczeń oczywiście] od zwykłego Gourada?

Może jednak rzuciłbyś linkiem do jakiegoś kawałka kodu, który implementuje
to o czym mówisz...

-- 
michal.'creed'.szostakiewicz............................coder.of.ultimaa...
.creed@tarchomin.pl .......................................................
.ms201103@zodiac.mimuw.edu.pl .............................................
.icq.2482112 ...........................iMMersE.your.soUL.in.lOVE......<><.

On 2005-02-11, creed <tarchomin@SWAPcreed.pl> wrote:
> Ale nieważne, biki, powiedz, bo i ja chyba jestem jakiś słaby na umyśle...
> Czym to się różni [poza precyzją obliczeń oczywiście] od zwykłego Gourada?

Hmm, chyba niczym? Jeżeli najpierw pointerpolujemy liniowo kolor na
brzegach, a potem w każdej scanline, to chyba wyjdze na to samo...
(z dokładnością do precyzji obliczeń :)

Ale problem z Gouraudem był inny: zachowanie się na styku dwóch
różnych trójkątów. Nawet miało to jakąś naukową nazwę :)

                                                                Daniel
-- 
\ Daniel Rychcik     INTEGRAL Science Data Centre, Versoix/Geneve, CH
 \--------------------------------------------------------------------
  \  GCM/CS/MU/M d- s++:+ a- C+++$ US+++$ P+>++ L+++$ E--- W++ N++ K-
   \ w- O- M PS+ PE Y+ PGP t+ 5 X- R tv b+ D++ G+ e+++ h--- r+++ y+++ 

Daniel Rychcik wrote:

> On 2005-02-11, creed <tarchomin@SWAPcreed.pl> wrote:
>> Ale nieważne, biki, powiedz, bo i ja chyba jestem jakiś słaby na
>> umyśle... Czym to się różni [poza precyzją obliczeń oczywiście] od
>> zwykłego Gourada?
> 
> Hmm, chyba niczym? Jeżeli najpierw pointerpolujemy liniowo kolor na
> brzegach, a potem w każdej scanline, to chyba wyjdze na to samo...
> (z dokładnością do precyzji obliczeń :)

Biki pewnie jak zwykle będzie twierdził inaczej.

Chyba, że chodzi o ten sam problem jak przy z-bufforze - pamiętam, że
czytając to dawno temu nie do końca zrozumiałem, ale chyba ból polega na
tym, że rzutowanie sprawia, że nie można z interpolować po prostu liniowo
we współrzędnych zrzutowanych [tzn. to rzeczywiście nie jest dokładne].
Można za to interpolować 1/z [czasem nazywane "w" :-), stąd w-bufor], co
zresztą robią chyba współczesne akceleratory [czy nie?].

Ale jeśli tak to problem nie leży w tym JAK interpolujemy tylko CO
interpolujemy...

Proszę mnie poprawić jeśli plotę jakieś straszne androny.

Tak czy siak bardzo mnie interesuje o co tak naprawdę chodziło Bikiemu.
 
> Ale problem z Gouraudem był inny: zachowanie się na styku dwóch
> różnych trójkątów. Nawet miało to jakąś naukową nazwę :)

Tzn. o jakie dokładnie zachowanie na styku Ci chodzi :)))? Hmm... chyba nie
aliasing?

Nie wiem, ja, całkiem zresztą niedawno, miałem z tego egzamin u Kiciaka i
jedyne czego ode mnie wymagał to było to, że jak masz np. rozbłysk np. w
wierzchołku, w którym schodzą się 3 trójkąty to ten rozbłysk będzie
trójkątny [no bo interpolacja jest liniowa :-)]. O to chodziło czy nie
bardzo?

-- 
michal.'creed'.szostakiewicz............................coder.of.ultimaa...
.creed@tarchomin.pl .......................................................
.ms201103@zodiac.mimuw.edu.pl .............................................
.icq.2482112 ...........................iMMersE.your.soUL.in.lOVE......<><.

On 2005-02-12, creed <tarchomin@SWAPcreed.pl> wrote:
> Chyba, że chodzi o ten sam problem jak przy z-bufforze - 

Nie, jest dokładnie tak jak napisałeś - w z-buforze po przejściu do 
interpolacji 1/z mamy wszystko ślicznie liniowe.

>> Ale problem z Gouraudem był inny: zachowanie się na styku dwóch
>> różnych trójkątów. Nawet miało to jakąś naukową nazwę :)
> Tzn. o jakie dokładnie zachowanie na styku Ci chodzi :)))? Hmm... chyba nie
> aliasing?

To jest tak: masz jeden trójkąt, ładnie liniowo, afinicznie, czy jak tam
kto woli, interpolowany. Obok niego masz drugi, stykający się z nim jedną
krawędzią. Oczywiście na tej krawędzi kolory są dokładnie takie same (no
bo to liniowa interpolacja między dwoma wierzchołkami o tym samym kolorze)
Tyle, że jak tylko odejdzie się od krawędzi, to gradient zmian koloru jest
różny z każdej strony... no kurcze, to jest ciężko opisać - ale to po 
prostu widać :) Coś mi świta, że nazywało się to pasma Macha, ale mogę
się mylić - to są zabawy, którymi zajmowałem się jakieś 8-10 lat temu :-)
Ale pamiętam, że było to opisane z przykładami w "Elementach Grafiki 
Komputerowej".

> jak masz np. rozbłysk np. w wierzchołku, w którym schodzą się 3 trójkąty 
> to ten rozbłysk będzie trójkątny [no bo interpolacja jest liniowa :-)]. 
> O to chodziło czy nie bardzo?

Nie bardzo :)
                                                                Daniel
-- 
\ Daniel Rychcik     INTEGRAL Science Data Centre, Versoix/Geneve, CH
 \--------------------------------------------------------------------
  \  GCM/CS/MU/M d- s++:+ a- C+++$ US+++$ P+>++ L+++$ E--- W++ N++ K-
   \ w- O- M PS+ PE Y+ PGP t+ 5 X- R tv b+ D++ G+ e+++ h--- r+++ y+++ 

roznica jest zasadnicza.
przy interpolacji liniowej masz poprawny wynik.
tzn dla dowolnego punktu dostajesz poprawnie interpolowana wartosc
a przy gouraudzie dostajesz bledy:
gouraud interpoluje najpierw na krawedziach
to znaczy dla kazdej linii ekranu przecinanej przez krawedz oblicza
wartosc interpolowana a potem majac wartosci na dwoch koncach poziomej 
linii interpoluje poziomo.
bledy wynikaja z tego ze w momencie interpolowania krawedzi wielokata 
kolejne interpolowane wartosci sa poprawne dla punktu NA KRAWEDZI ktory 
choc wspolrzedna Y ma taka sama jak pierwszy piksel ktory bedziesz potem 
rysowal, to wsp X jest zwykle inna. W rezultacie dostajesz niepoprawne 
wartosci (o jakis niewielki ulamek ale przy z-buforze bardzo znaczace)

In pl.comp.demoscena, biki wrote:
> bledy wynikaja z tego ze w momencie interpolowania krawedzi wielokata 
> kolejne interpolowane wartosci sa poprawne dla punktu NA KRAWEDZI ktory 
> choc wspolrzedna Y ma taka sama jak pierwszy piksel ktory bedziesz potem 
> rysowal, to wsp X jest zwykle inna. 

Hmm, nadal wydaje mi się, że nie masz racji. Oczywiście powyższe jest
prawdą ("wsp. X jest zwykle inna"), ale to nie ma nic do rzeczy. Mając
daną jasność kolorów w trzech punktach, cały trójkąt jest wyznaczony
_jednoznacznie_. I skoro wartości na krawędziach są poprawne, to i
liniowo interpolowane wartości w liniach poziomych też będą. "Liniowość" 
interpolacji nie zależy od tego pod jakim kątem się ją robi - w
ekstremalnym przypadku (jeśli będziesz rysował linie pod kątem
prostopadłym do gradientu), będzie to rysowanie linii w jednolitym
kolorze :)

Narysuj sobie trójkąt równoboczny o takich jasnościach w wierzchołkach:

                     0
                    /\
                   /  \
                  /    \
               50/   .  \100
                /   75   \
               /          \
              /            \
          100/______________\200
                    150

Widać, że wektor gradientu będze szedł dokładnie po prawej krawędzi (bo
w jej połowie będzie jasność 100 (200+0)/2 a skoro ma być liniowo, to
odcinek (100-100) będzie cały jasności 100. A kąt (100-100-0) jest prosty :)
W połowie lewej krawędzi będzie 50 (100+0)/2. Teraz jeśli poprowadzić odcinek 
w połowie wysokości trójkąta, to na jego środku będzie 75. I będzie to 75 
niezależnie od tego, czy wyliczymy je z "linii poziomej" (100+50)/2, 
"pionowej" (150+0)/2, czy też dowolnej ukośnej, biorąc dowolną prostą 
przechodzącą przez ten punkt i jasności z punktów przecięcia z trójkątem.

> W rezultacie dostajesz niepoprawne wartosci (o jakis niewielki ulamek 
> ale przy z-buforze bardzo znaczace)

Eee, moment... Błędy precyzji obliczeń będą przy dowolnym algorytmie :)
Ale ja myślałem, że mowa jest o "ideologicznej" niepoprawności?


A co do artefaktów, to dobrze pamiętałem - nazywa się to "Mach bands",
po wpisaniu w google "gouraud mach", większośc wyników zawiera coś
w rodzaju "Mach band will appear even though _there is no
discontinuity of color_". Sama interpolacja jest poprawna, tyle że
po zgraniu tego w całość z innym trójkątem, w którym wektor gradientu
jest mocno różny, ten problem zaczyna wyłazić.

                                                                Daniel
-- 
\ Daniel Rychcik     INTEGRAL Science Data Centre, Versoix/Geneve, CH
 \--------------------------------------------------------------------
  \  GCM/CS/MU/M d- s++:+ a- C+++$ US+++$ P+>++ L+++$ E--- W++ N++ K-
   \ w- O- M PS+ PE Y+ PGP t+ 5 X- R tv b+ D++ G+ e+++ h--- r+++ y+++ 

to co mowisz moglo by byc prawda gdyby krawedzie przechodzily dokladnie
przez srodki pikseli, a tak prawie nigdy nie jest
       /
+-----/---------+
|    /          |
|   /           |
|  /            |
| x     o       |
|/              |
/               |
|               |
+---------------+

tak jak na tym obrazku , interpolacacja krawedzi obliczy kolor dla punktu x
a ty go wykorzystasz w punkcie o (chyba ze bedziesz dodawal poprawke co jest 
duzko kosztowniejsze od zrobienia po prostu interpolacji liniowej)
co wiecej w kazdej linii ta odleglosc jest inna i dostajesz inny blad

On 2005-02-14, biki <biki@viper.pl> wrote:
> to co mowisz moglo by byc prawda gdyby krawedzie przechodzily dokladnie
> przez srodki pikseli, a tak prawie nigdy nie jest

OK, czyli jednak mówisz po prostu o błędach obliczeń :) No dobra, nie
całkiem, bo tu się jednak tablicuje rzeczywiście taką pseudo-krawędź.
Ale mimo wszystko można to podpiąć pod błędy zaokrągleń.

> (chyba ze bedziesz dodawal poprawke co jest duzko kosztowniejsze od 
> zrobienia po prostu interpolacji liniowej)

Hmm, a mógłbyś w końcu napisać co rozumiesz pod pojęciem "po prostu
interpolacji liniowej"? Bo jeżeli Ax+By+C w każdym pikselu... to chyba
już pseudo-phong jest tańszy :) a nie ma wad, o których pisałem...

                                                                Daniel
-- 
\ Daniel Rychcik     INTEGRAL Science Data Centre, Versoix/Geneve, CH
 \--------------------------------------------------------------------
  \  GCM/CS/MU/M d- s++:+ a- C+++$ US+++$ P+>++ L+++$ E--- W++ N++ K-
   \ w- O- M PS+ PE Y+ PGP t+ 5 X- R tv b+ D++ G+ e+++ h--- r+++ y+++ 

>OK, czyli jednak mówisz po prostu o b??dach oblicze? :) No dobra, nie
>ca?kiem, bo tu si? jednak tablicuje rzeczywiście taką pseudo-kraw?d?.
>Ale mimo wszystko mo?na to podpią? pod b??dy zaokrągle?.

to nie sa bledy obliczen tylko bledy algorytmu, po porostu nie liczy tego
co trzeba

>Hmm, a móg?byś w ko?cu napisa? co rozumiesz pod poj?ciem "po prostu
>interpolacji liniowej"? Bo je?eli Ax+By+C w ka?dym pikselu... to chyba
>ju? pseudo-phong jest ta?szy :) a nie ma wad, o których pisa?em...

dokladnie ax+by+c w kazdym pikselu. a jak masz troche oleju w glowie
to liczysz Ax+By+C w pierwszym pikselu kazdej poziomej linii a potem tylko
dodajesz A

On 2005-02-14, biki <biki@viper.pl> wrote:
>> OK, czyli jednak mówisz po prostu o b??dach oblicze? :) No dobra, nie
>> ca?kiem, bo tu si? jednak tablicuje rzeczywiście taką pseudo-kraw?d?.
>> Ale mimo wszystko mo?na to podpią? pod b??dy zaokrągle?.
> to nie sa bledy obliczen tylko bledy algorytmu, po porostu nie liczy tego
> co trzeba

No dobra, to przyznaję: Gouraud rzeczywiście jest błędny, poszczególne
scanlines mogą byc przesunięte w granicach +/- 0.5 pixela w lewo/prawo,
bo na lewej krawędzi mamy wyliczone wartości nie-w-centrum pixela. 
Pasi? ;-)

> a jak masz troche oleju w glowie to liczysz Ax+By+C w pierwszym 
> pikselu kazdej poziomej linii a potem tylko dodajesz A

.. I (o ile nie robisz tego na floatach lub co najmniej 16.16 fixed 
point), to dostajesz na prawej krawędzi (akumulujący się!) błąd 
interpolacji podobnego rzędu jak ten powyżej :)

BTW. coś nie tak z moim kodowaniem?
                                                                Daniel
-- 
\ Daniel Rychcik     INTEGRAL Science Data Centre, Versoix/Geneve, CH
 \--------------------------------------------------------------------
  \  GCM/CS/MU/M d- s++:+ a- C+++$ US+++$ P+>++ L+++$ E--- W++ N++ K-
   \ w- O- M PS+ PE Y+ PGP t+ 5 X- R tv b+ D++ G+ e+++ h--- r+++ y+++ 

>.. I (o ile nie robisz tego na floatach lub co najmniej 16.16 fixed 
>point), to dostajesz na prawej krawedzi (akumulujący sie!) bląd 
>interpolacji podobnego rzedu jak ten powyzej :)

dlatego nikt zdrowy nie uzywa mniejszej precyzji,
tak na marginesie przy gouraudzie tez ci sie akumuluje blad
wiec akurat tutaj powaznej roznicy nie ma

> In pl.comp.demoscena, biki wrote:
> > bledy wynikaja z tego ze w momencie interpolowania krawedzi wielokata
> > kolejne interpolowane wartosci sa poprawne dla punktu NA KRAWEDZI ktory
> > choc wspolrzedna Y ma taka sama jak pierwszy piksel ktory bedziesz potem
> > rysowal, to wsp X jest zwykle inna.
>
> Hmm, nadal wydaje mi się, że nie masz racji. Oczywiście powyższe jest
> prawdą ("wsp. X jest zwykle inna"), ale to nie ma nic do rzeczy. Mając
> daną jasność kolorów w trzech punktach, cały trójkąt jest wyznaczony
> _jednoznacznie_. I skoro wartości na krawędziach są poprawne, to i
> liniowo interpolowane wartości w liniach poziomych też będą.

No wlasnie o to chodzi Bikiemu, ze ten blad zaczyna sie juz na
krawedziach... Ale to juz chyba tez zrozumiales...

Dzieki Biki za wyjasnienie.

Choc ciagle mam jakies przeczucie, ze daloby sie Gourada poprawic tak, zeby
te krawedzie wyliczal poprawnie i wcale nie bylby 3 razy drozszy niz to co
nazywasz "liniowa interpolacja" [swoja droga nie bardzo potrafilem znalezc
cos o tym w sieci].


Inna sprawa, ze ciagle mam wrazenie, ze powazniejszym problemem jest to, ze
rzeczywiscie na ogol nie interpolujemy tego co trzeba (tzn. olewamy
perpektywe). Ciekawi mnie jak to robia akceleratory... Orientuje sie ktos?


> A co do artefaktów, to dobrze pamiętałem - nazywa się to "Mach bands",
> po wpisaniu w google "gouraud mach", większośc wyników zawiera coś
> w rodzaju "Mach band will appear even though _there is no
> discontinuity of color_". Sama interpolacja jest poprawna, tyle że
> po zgraniu tego w całość z innym trójkątem, w którym wektor gradientu
> jest mocno różny, ten problem zaczyna wyłazić.

Faktycznie, swego czasu sie zastanawialem czemu mimo Gourada ta kaczka tak
dziwnie wyglada, tzn. wyraznie widac trojkaty...


pozdro
creed

>Choc ciagle mam jakies przeczucie, ze daloby sie Gourada poprawic tak,
>zeby te krawedzie wyliczal poprawnie i wcale nie bylby 3 razy drozszy
>niz to co nazywasz "liniowa interpolacja" [swoja droga nie bardzo
>potrafilem znalezc cos o tym w sieci].
oczywiscie ze mozna, ale zawsze bedzie to kosztowac wiecej niz interpolacja 
liniowa robiona z rozwiazania ukladu rownan.
bo musisz dodac do koloru na lewej krawedzi przyrost jaki nastapi przy 
przejsciu do centrum piksela.

>
>
>Inna sprawa, ze ciagle mam wrazenie, ze powazniejszym problemem jest to,
>ze rzeczywiscie na ogol nie interpolujemy tego co trzeba (tzn. olewamy
>perpektywe). Ciekawi mnie jak to robia akceleratory... Orientuje sie
>ktos? 

z reguly interpoluje sie wartosci ktore sa liniowe w przestrzeni ekranu
takie jak 1/Z czy w przypadku tekstury U/Z V/Z


a warto dodac tak przy okazji:
gouraud 1 dzielenie na krawedz na wspolrzedna + jedno dzielenie na pozioma 
linie wielokata

liniowa 1 dzielenia na caly trojkat + dwa mnozenia na linie.

no i jak robisz liniowo to mozna stosowac ciekawe tricki
na przyklad jak masz trojkat ktory jest obciety przez piramide widzenia
i laduje na ekranie jako wielokat. to mozliwe jest policzenie wsp. 
interpolacji A,B,C bezposrednio z wierzcholkow oryginalnego trojkata i poza 
zmniejszona iloscia obliczen przy samym trojkacie dostajesz zysk wynikajacy 
z tego ze nie musisz obcinac wspolrzednych tekstury/cieniowania co ci 
upraszcza geometrie.

On 2005-02-16, creed <mojaksywa@tarchomin.pl> wrote:
> Choc ciagle mam jakies przeczucie, ze daloby sie Gourada poprawic tak, zeby
> te krawedzie wyliczal poprawnie i wcale nie bylby 3 razy drozszy niz to co
> nazywasz "liniowa interpolacja" 

Pewnie że by się dało - wystarczy na krawędziach interpolować iksy i kolor z
pewną dokładnością (16.16?), a potem w każdej linii dodawać jakiś tam malutki
offset przed rozpoczęciem interpolacji - koszt na scanline to gdzieś w okolicy 
jednego dzielenia i kilku mniej istotnych operacji. (Pewnie zresztą dałoby się 
to zrobić w całości na offsetach, bez dzielenia, ale skoro to tylko jedna 
operacja na linię, to się w zasadzie nie opłaca...)

> Faktycznie, swego czasu sie zastanawialem czemu mimo Gourada ta kaczka tak
> dziwnie wyglada, tzn. wyraznie widac trojkaty...

Ano właśnie, i tu nawet "poprawny gouraud" nie pomoże, bo błąd jest
natury ideologicznej, a nie zaokrągleniowej :)

                                                                Daniel
-- 
\ Daniel Rychcik     INTEGRAL Science Data Centre, Versoix/Geneve, CH
 \--------------------------------------------------------------------
  \  GCM/CS/MU/M d- s++:+ a- C+++$ US+++$ P+>++ L+++$ E--- W++ N++ K-
   \ w- O- M PS+ PE Y+ PGP t+ 5 X- R tv b+ D++ G+ e+++ h--- r+++ y+++