witam,
jakiś czas temu zaimplementowałem okienkowanie i rysowanie okręgu o dużym promieniu,
którego nie obsługuje poprawnie standardowe API,
conajmniej Java SDK oraz API Javy w Androidzie, sadzę że w przypadku wielu innych API
w innych językach jest podobnie.

Przypomnę interesują mnie przypadki rysowania wycinku łuku i jego okienkowania.
Opracowałem sprawny algorytm ustalania które ćwiartki należy rysować, które z nich w
pelni a które tylko częściowo. Samo rysowanie odbywa się juz w oktetach,
(ćwiarki są dzielona na pół).

Czasami pojawiają się drobne problemy ze zgraniem pikseli, czyli w pewnych
przypadkach wystepuje maksymalnie blad o 1 piksel. Widoczne to jest przy kacie 45
stopni.

Błąd wynika z pozycjonowania oktetu a nie ze sposobu jego rysowania.
Z racji tego że punkty startowe sa wyliczane jako double a orginalny midpoint jest
int więc w tym musiał bym szukać problemu. Sama juz procedura rysowania jest bardzo
podobna do midpoint.

Moim zdaniem najlepszym doraźnym rozwiazaniem problem było by rysowanie
okretów w przeciwnym kierunku niż to ma miejsce w orginalnym midpoincie.
Obliczenie punktu przy kącie 45 stopni polegało by na przemnozeniu raduisa
przez stałą. Oktety korzystały by z tych samych danych początkowych więc musiały by
być idealnie dopasowane i symetryczne.

Ponadto takie podejście jest bardziej korzystne jeśli chcemy rysować to co widoczne
jest wewnątrz okna, bo okno obcina gore-dol-lewo-prawi zostawiając
fragment koła pomiędzy, więc często obszary przy kącie 45 stopni są widoczne.

Macie jakieś pomysły jak odwrócić prodecure midpoint,
aby działała w przeciwnym kierunku?

Nie jestem pewien czy ze punktem wyjścia do opracowania mojej prodecury była by
orginalna procedura midpoint czy ta zoptymalizowana.

do góry

> Macie jakieś pomysły jak odwrócić prodecure midpoint,
> aby działała w przeciwnym kierunku?
>
> Nie jestem pewien czy ze punktem wyjścia do opracowania mojej prodecury była by
orginalna procedura midpoint czy ta zoptymalizowana.

Chyba będę musiał dokładnie przeanalizować procedure midpoint 0-45 stopni
I opracuję swoją działającą na 45-0, zobaczę wtedy jakie bedą rezultaty.

Patrząc na mój kod dla dwóch klas rysujących koło i wycinek koła w oknie,
to mam 8 metod do midpoint, czyli na każdy oktet z osobna, bo tak chyba najszybciej i
najprościej w przypadku wycinków koła o dużym promieniu. Pozostaje mi tylko opracować
8 nowych metod które rysują w przeciwnym kierunku tzn od wartosci 45 do wartosci
granicznych.

Wydaje mi się to proste, podstawowa różnica polega na innej inicjalizacji zmiennej
decyzyjnej d oraz inkrementowaniu zmiennych decyzyjnych
z przeciwnym znakiem jak to jest w orginalnej procedurze.

do góry

W dniu piątek, 9 października 2015 13:16:55 UTC+2 użytkownik Radoslaw Jocz napisał:
> > Macie jakieś pomysły jak odwrócić prodecure midpoint,
> > aby działała w przeciwnym kierunku?
> >
> > Nie jestem pewien czy ze punktem wyjścia do opracowania mojej prodecury była by
orginalna procedura midpoint czy ta zoptymalizowana.
>
> Chyba będę musiał dokładnie przeanalizować procedure midpoint 0-45 stopni
> I opracuję swoją działającą na 45-0, zobaczę wtedy jakie bedą rezultaty.
>
to jest akurat dobry pomysl, sam to odkladalem a w koncu trzaba to zrobic.. zwłaszcza
ze akurat nie ma nic do roboty

do góry

On Friday, October 9, 2015 at 6:40:45 PM UTC+1, firr wrote:
> W dniu piątek, 9 października 2015 13:16:55 UTC+2 użytkownik Radoslaw Jocz napisał:
> > > Macie jakieś pomysły jak odwrócić prodecure midpoint,
> > > aby działała w przeciwnym kierunku?
> > >
> > > Nie jestem pewien czy ze punktem wyjścia do opracowania mojej prodecury była by
orginalna procedura midpoint czy ta zoptymalizowana.
> >
> > Chyba będę musiał dokładnie przeanalizować procedure midpoint 0-45 stopni
> > I opracuję swoją działającą na 45-0, zobaczę wtedy jakie bedą rezultaty.
> >
> to jest akurat dobry pomysl, sam to odkladalem a w koncu trzaba to zrobic..
zwłaszcza ze akurat nie ma nic do roboty

pomysł w tym zły w tym sensie że startujesz od punktu obliczonego jako liczba
rzeczywista

x i y inicjalizuje tak:
x = 0.70710678118654752440084436210485D * r;
y = 0.70710678118654752440084436210485D * r;

d inicjalizuje tak:
double d = x*x+y*y-r*r;

inkrementacje w petli

if (d>=0) {
x--; d-= 2*x+3;
} else {
x--; y++; d-= 2*(x-y)+5;
}

ale sa mniej stabilne niz te
ktore napisalem wczeniej tzn na podstawie orginalnego midpoint 0-45

przy katach 45 stopni dzialaja dobrze ale przy 0,90,180,270 juz gorzej,
poki co zostane przy starym rozwiazaniu, a przy malych raduisach r<1000 bede uzywal
te z API bo wtedy sa wystarczająco lub bardzo dokładne.

W Javie SDK i Androidzie te funkcje sa kiepsko zrobione,
sadzę że to nie wyjątek. Same już parametry to tych procedur w API
sa bezsensowne co świadczy że nie są dopracowane.

Java SDK:
drawOval(int x, int y, int width, int height) - bezsens
drawArc(int x, int y, int width, int height, int startAngle, int arcAngle) - jeszcze
większy bezsens

Android Java:
drawCircle(float cx, float cy, float radius, Paint paint) - bezsens na potęgę
public void drawArc (RectF oval, float startAngle, float sweepAngle, boolean
useCenter, Paint paint) - bezsens
public void drawArc (float left, float top, float right, float bottom, float
startAngle, float sweepAngle, boolean useCenter, Paint paint) - bezsens

do góry

> W Javie SDK i Androidzie te funkcje sa kiepsko zrobione,
> sadzę że to nie wyjątek. Same już parametry to tych procedur w API
> sa bezsensowne co świadczy że nie są dopracowane.
>
> Java SDK:
> drawOval(int x, int y, int width, int height) - bezsens
> drawArc(int x, int y, int width, int height, int startAngle, int arcAngle) -
jeszcze większy bezsens
>
> Android Java:
> drawCircle(float cx, float cy, float radius, Paint paint) - bezsens na potęgę
> public void drawArc (RectF oval, float startAngle, float sweepAngle, boolean
useCenter, Paint paint) - bezsens
> public void drawArc (float left, float top, float right, float bottom, float
startAngle, float sweepAngle, boolean useCenter, Paint paint) - bezsens

dlaczego sa błędnie zaprojektowane,
w Javie SDK parametry to inty, ponadto wewnatrz też sa inty,
stwarza to niemożność użycie przy dużym promieniu i pozycji środka daleko po za
ekranem
ponadto od razu za jednym zamachem chciali obsluzyć elipsę ale nawet okrąg spaprali.
wycinek koła podobnie ale dodatkowo kąty sa jako inty, co jest też sporym
ograniczeniem

Android podobnie, dodatkowo floaty jako współrzędne to bezsens,
mam wrażenie że wewnetrznie i tak działa na intach, przynajmniej co do pozycjonowania
środka okręgu.

Dodatkowo przeważnie nie ma w argumentach środka okręgu i promienia bezpośredno, co
wymaga dodatkowych drobnych obliczeń ale to już najmniejszy problem.

do góry

zajrzalemikipedii i ten midpoint jest bardzo prosty, powiedzmy ze kolo ma promien 100

[ultraszybki tutorial]

r = 100
zaczynamy od punktu

pierwszy punkt:

1) y= 0, x=100

drugi punkt :

zawsze robimy y++,
x zwiekszamy albo o zero albo o minus jeden

2) y = 1, x = 100 lub x = 99

to ktora opcje wybrac liczymy w ifie z
rownania okregu x*x > r*r - y*y

i tyle, nie wiem co prawda ktore sciezki sie wybiera czy te x*x ktore sa wieksze czy
te ktore mniejsze czy tez ew liczy sie roznice
delta = x*x - (r*r - y*y) i bierze punkt w zaleznosci od tego po ktorej stronie ta
roznica jest mniejsza ale to sa detale

voila

w twoim wypadku tych wielkich lukow mozna postawic ten poczatkowy punkt midpointem
po czym jechac po kolei (uwazajac oczywiscie czy to jedna cwiartka czy dwie i jak
pre-ustawic x i y).. taki midopint jak ja wyzej pisze wydaje mi sie po prostu regułą
bez stanu, (bez jakiejs tam pamieci algorytmu jak mi sie ew wczesniej wydawalo) tak
ze
wszystko jest super proste, po prostu jest to regula na na x dla danego y oraz r,
cale przyspieszenie wynika z tego ze nie trzeba liczyc pierwiastka wystarczy porownac
kwadraty (i ew z rozwiniecia tych paru mnozonek i dodawan by zaoszczedzic z jedno lub
ze dwa, juz w to nie che mi sie wczytywac)

do góry

> wszystko jest super proste, po prostu jest to regula na na x dla danego y oraz r,
> cale przyspieszenie wynika z tego ze nie trzeba liczyc pierwiastka wystarczy
porownac
> kwadraty (i ew z rozwiniecia tych paru mnozonek i dodawan by zaoszczedzic z jedno
lub ze dwa, juz w to nie che mi sie wczytywac)

wiem to doskonale,
problem z orginalnym midpointem jest taki ze jest dobry dla pelnych kół,
w całości lub w większości wyswietlanych, przec co mają mały promień.

wyobraź sobie promien 1,000,000 pikseli w oknie 640x480 czy chcesz iterowac te
miliony niewidocznych punktów ???

mia mam zamiaru obliczać sqrt, dla porownan potegi dlugosci wystarcza,
I na tym polega midpoint,
ponadto zakłada dzialania na intach wiec jest przenosny w 100%
problem polega na tym ze ja chce okienkowac koła lub wycinki koła o dużym promieniu,
z maksymalnym błędem +- 1 piksel na całym obwodzie co już dawno mi się udało,

teraz tylko się zastanawiałem czy mogłbym idealnie to rysować co do piksela,
oczywiście orginalny midpoint odpada

do góry

On Saturday, October 10, 2015 at 5:48:51 PM UTC+2, Radoslaw Jocz wrote:
> > wszystko jest super proste, po prostu jest to regula na na x dla danego y oraz r,
> > cale przyspieszenie wynika z tego ze nie trzeba liczyc pierwiastka wystarczy
porownac
> > kwadraty (i ew z rozwiniecia tych paru mnozonek i dodawan by zaoszczedzic z jedno
lub ze dwa, juz w to nie che mi sie wczytywac)
>
> wiem to doskonale,
> problem z orginalnym midpointem jest taki ze jest dobry dla pelnych kół,
> w całości lub w większości wyswietlanych, przec co mają mały promień.
>
> wyobraź sobie promien 1,000,000 pikseli w oknie 640x480 czy chcesz iterowac te
miliony niewidocznych punktów ???
> [...]

Przeskalować przed rysowaniem?


Pozdrawiam

do góry

W dniu sobota, 10 października 2015 17:48:51 UTC+2 użytkownik Radoslaw Jocz napisał:
> > wszystko jest super proste, po prostu jest to regula na na x dla danego y oraz r,
> > cale przyspieszenie wynika z tego ze nie trzeba liczyc pierwiastka wystarczy
porownac
> > kwadraty (i ew z rozwiniecia tych paru mnozonek i dodawan by zaoszczedzic z jedno
lub ze dwa, juz w to nie che mi sie wczytywac)
>
> wiem to doskonale,
> problem z orginalnym midpointem jest taki ze jest dobry dla pelnych kół,
> w całości lub w większości wyswietlanych, przec co mają mały promień.
>
> wyobraź sobie promien 1,000,000 pikseli w oknie 640x480 czy chcesz iterowac te
miliony niewidocznych punktów ???
>
> mia mam zamiaru obliczać sqrt, dla porownan potegi dlugosci wystarcza,
> I na tym polega midpoint,
> ponadto zakłada dzialania na intach wiec jest przenosny w 100%
> problem polega na tym ze ja chce okienkowac koła lub wycinki koła o dużym
promieniu, z maksymalnym błędem +- 1 piksel na całym obwodzie co już dawno mi się
udało,
>
> teraz tylko się zastanawiałem czy mogłbym idealnie to rysować co do piksela,
> oczywiście orginalny midpoint odpada

moze spróbuj napisac midpoint ktory bedzie
rysowac łuk od punktu A do punktu B, chyba
nie powinno byc takie trudne - pozniej zostanie wyznaczyc A i B

do góry

> moze spróbuj napisac midpoint ktory bedzie
> rysowac łuk od punktu A do punktu B, chyba
> nie powinno byc takie trudne - pozniej zostanie wyznaczyc A i B

tak wlasnie jakis czas temu zrobilem,
same procedury midpoint sa proste,
natomiast odpowiednie i optymalne wyznaczenie punktow przeciecia z oknem
oraz wyznaczenie oktetow itd to juz bardzie skaplikowane,
ale to juz mam za soba,

bede musiał kiedys później napisac odpowiedniego testcase za pomoca ktorego
dowiem się dokładnie jak wyeliminowac błąd +-1 piksel który mnie denerwuje,

być może ide poprostu złą ścieżką,
moze powinienem w niektórych przypadkach reprezentować liczby rzeczywiste za pomocą
całkowitych long to by wyelminowało problemy z zaokrągleniem, rzutowaniem itp.
jednak do obliczeń double u mnie jest standardowe podobniej jak klasam Math w Javie a
zależy mi na dokładności obliczeń.

Bedę jeszcze próbował w ogóle wyeliminowanić obliczenia sqrt przy okienkowaniu,
w moim kodzie maksymalnie 4 trzeba liczyć dla każdgo okregu lub jego wycinku.

Kąty wycinku koła lub przecięcia okręgu z oknem można wyznaczyć za pomocą
2 liczb całkowitych dx / dy.
Ja też tak robię, robię nawet w pewnym miejscu w kodzie porownywanie kata za pomocą
takich par liczb, działa do dla każdego zakresu kąta,

do góry