Użytkownik "bartekltg" <b...@g...com> napisał w wiadomości
news:kn168f$u0i$1@node2.news.atman.pl...
> Na czym polega ta słaba dokładność?
> Czyżby nie używali tutułowego midpointa?

W standardowym algorytmie rysowania kól i elips przepełnienie może się
zdarzyć zwłaszcza dla elips, gdzie występują dwa razy dłuższe liczby niż
przy okręgach

do góry

Poniewaz midpoint to procedura itercyjna byc moze dochodzi do kumulowania sie bledow.
Jednak objawiaja sie one w polowie kata jaki obsluguje tzn. 45/2
Jesli oblicze punkty na okregu wg rownania okregu (uzywajac double) i je wyswietle
widze roznice ale tylko pewnych zakresach katow.

Roznice sa latwo widoczne gdy promien rysowanego okregu na ekranie jest duzy,
powiedzmy 1000 lub wiecej. Gdy promien wzrasta blad tez wzrasta ale w pewnych
zakresach katow jest najwiekszy w pewnych blad nie wystepuje.

W mojej alikacji zoom i scrool zaimplementowalem sam, nie robie zadnych transformacji
w grafice. Wszystko jest bardzo precyzyjne za wyjatkiem standartowych okregow.

do góry

W dniu 2013-05-16 16:44, Radoslaw Jocz pisze:
> On Thursday, 16 May 2013 00:37:50 UTC+1, bartekltg wrote:
>> W dniu 2013-05-15 19:04, Radoslaw Jocz pisze: > Witam ostatnio
>> stwierdzilem ze w Javie SDK oraz Androidzie drawCircle jest > dosc
>> kiepsko zaimplementowane, tzn przy duzych okregach jest slaba
>> dokladnosc. Na czym polega ta słaba dokładność? Czyżby nie używali
>> tutułowego midpointa? >
>
> Pewnie uzywaja cos w stylu midpoint ale pojawiaja sie przypadki
> szczegolne. Przy duzych promieniach zauwazylem ze pewne obszary
> okregu maja nieco inny promien. Zbadalem ten problem dokladniej i
> wiem ze okregi o duzym promieniu sa nieco zdeformowane. Przy katach
> 0, 45, 90, 135 wszystko sie zgadza ale przy np 22.5, 67.5 juz nie.
> Nie sadze ze wynika to z bledow moich obliczen i bibliotek. Poprostu
> wizualizacja okregow jest kiepska.

Ale dalej nie wyjaśniłeś, na czym ta niedokładność ma polegać?
Rysują to z 'cieniowaniem', czy dobierają jeden piksel?
Wtedy nie ma co się dziwić, sfragmenty b. dużego okręgu
będą wręcz linią prostą:)


> Mysle ze moze dochodzic do przepelnienia int-ow lub cos innego. W
> zarowno w Androidzie jak i na desktopie jest podobnie.



> Krzywych Beziera nie musze rysowac.

Nie masz ich rysować! Możesz uch użyć.
Zwłaszcza, że planowałeś rysować okrąg wielokątami,
krzywymi będzie znacznie lepiej.

pzdr
bartekltg

do góry

>Ale dalej nie wyjaśniłeś, na czym ta niedokładność ma polegać?

Wizualnie wyglada to jakby co staly jakis kat cyklicznie, stopniowo,
zmienia sie nieco promien okregu a pozniej powraca do nominalnego.
Wiec jesli np. wyliczyc punkty na okregu co 1 stopien i zrobic wizualizacje, tzn
narysuje sie okrag i pukty w duzym powiekszeniu to widac ze przy pewnych katach
zmienia sie promien. Zakladam ze punkty sa wyliczone dokladnie.
Im wiekszy promien rysowanego okregu tym wieksze rozbieznosi.

do góry

On Thursday, May 16, 2013 5:15:05 PM UTC+2, bartekltg wrote:
> Nie masz ich rysować! Możesz uch użyć.
> Zwłaszcza, że planowałeś rysować okrąg wielokątami,
> krzywymi będzie znacznie lepiej.

Rasteryzacja krzywych beziera/przybliżanie ich łamanymi jest
ciut trudniejsze niż rysowanie okręgu - obawiam się, że javowcy
mogli sobie z tym poradzić równie elegancko jak z okręgami. ;)

w.

do góry

W dniu 2013-05-16 19:29, Wojciech Muła pisze:
> On Thursday, May 16, 2013 5:15:05 PM UTC+2, bartekltg wrote:
>> Nie masz ich rysować! Możesz uch użyć.
>> Zwłaszcza, że planowałeś rysować okrąg wielokątami,
>> krzywymi będzie znacznie lepiej.
>
> Rasteryzacja krzywych beziera/przybliżanie ich łamanymi jest
> ciut trudniejsze niż rysowanie okręgu - obawiam się, że javowcy
> mogli sobie z tym poradzić równie elegancko jak z okręgami. ;)

Problem miał powstać dla okręgów bardzo dużych, np
większych niż ekran. Tutaj rysujemy tylko potrzebny
fragment. Łuk będący na ekranie rozkładany na kilka
(skoro boimy się jednej) krzywych i błędy może nie zdążą
się stworzyć:)

IMHO jest to znacznie lepsza wersja niż wielokąt.

pzdr
bartekltg

do góry

Wielokat dziala bardzo dobrze pod warunkiem ze jego boki sa dosc krotkie i promien
okregu w ktory jest wpisany jest duzy. Promien jest duzy w porownaniu do
rozdzielczosci okna w ktorym jest wyswietlany fragment okregu.
Wtedy widac tylko lekko zakrzywiona krzywa albo juz nawet prosta,
wiec mozna to narysowac dokladnie i szybko za pomoca krotkich odcinkow
a o to mi chodzi. Problemem jest tylko odowiednia parametryzacja
aby bylo rysowane wystarczajaco dokladnie i w miare szybko.
Trzeba dynamicznie zmieniac ilosc bokow wielokata a dlugosc bokow moze nieznacznie
wzrastac ze wzrostem promienia.

Oczywiscie sprawne okienkowanie przy duzym promieniu jest potrzebne bo wtedy bedzie
duzo bokow.
Przy malych okregach uzywam drawCircle, bo jest dokladne i szybkie.

do góry

Nie probowalem uzywac drawArc ale sadze ze jest obarczone takim samym bledem jak
drawCircle.

do góry

ostatnio po urlopie wrócilem do problemu,
duże okregi (R>1000) będą rysowane w taki sposób:

1. wyznaczyć zakresy (dziedziny) dla kazdej z cwiartek jesli
w danej ćwiartce jest coś do rysowania to podzielic ja na 2 obszary
aby rysowac 1/8 okregu

2. majac wyliczone punkty startowe i koncowe dla kazdych 1/8 okregu
narysowac kazdy fragment z osobna. (zakladam ze fragenty 1 lub 2 oktetow beda
widoczne w danym momencie wiec nie mam zamiaru tego dodatkowo optymalizowac)

teraz pytanie korzystajac z alorytmu midpoint moze zainicjowac x,y od ktorych moge
startowac wiec ale zastanawiam sie nad zmienna decyzyjna d w jaki sposob ja
zainicjowac.

x = 0
y = -R
d = 5/4 - R
putPixel(x, y)
while (-y > x) {
if (d > 0) {
d += 2*x + 3
x++
} else {
d += 2*(x+y) + 5
x++ y++
}
putPixel(x, y)

}

do góry

On Saturday, June 22, 2013 5:32:49 PM UTC+2, Radoslaw Jocz wrote:
> teraz pytanie korzystajac z alorytmu midpoint moze zainicjowac x,y od ktorych moge
startowac wiec ale zastanawiam sie nad zmienna decyzyjna d w jaki sposob ja
zainicjowac.

Pisałeś zdaje się, że nie możesz używać putpixel. Co się zmieniło?

> x = 0
>
> y = -R
>
> d = 5/4 - R
>
> putPixel(x, y)
>
> while (-y > x) {
>
> if (d > 0) {
>
> d += 2*x + 3
>
> x++
>
> } else {
>
> d += 2*(x+y) + 5
>
> x++ y++
>
> }
>
> putPixel(x, y)
>
>
>
> }


Co do zasadniczego pytania: przemnóż d przez 4, żeby nie było ułamka.
Przez 4 też musisz przemnożyć czynniki wpływające na d.

Pozwolę sobie dać linka do mojego art., gdzie ten temat już przerabiałem:
http://0x80.pl/articles/bresenham.html#rasteryzacja-
okregu

w.

do góry